1. Bug là gì
Hiểu một cách đơn giản thì bug sẽ là một lỗi trong một chương trình nào đó trên máy tính, trên phần mềm. Xuyên suốt trong cả một quá trình viết source code, cho dù bạn là một lập trình viên progmmer hay là nhà phát triển phần mềm developer thì cũng khó tránh khỏi việc mắc sai lầm. Và dường như những sai lầm như thế này thường sẽ được thể hiện ở dưới dạng dưới dạng của bug trong code. Viết code là một phần khá là dễ dàng, nhưng bước khó khăn tiếp theo là debug, tức là tìm error hoặc bug trong chương trình. Tất cả các quá trình được diễn ra như thế này sẽ khiến cho các dev điện đầu vì chúng sẽ phải tạo thêm ra một n bug khác để mà thay thế và sửa cho bug hiện tại. Có đến 5 loại bug và được coi là khá điển hình mà bất cứ 1 dev nào cũng chắc chắn sẽ phải gặp qua nó.
Nội dung chính
- 1. Bug là gì
- 1.1. Bug tí hon
- 1.2. Bug không tồn tại
- 1.3. Bug khủng
- 1.4. Bug ẩn thân
- 1.5. Bug bất ngờ
- 2. Có nên chày cối fix bug ngay không
- 3. Một số quy tắc dùng để xác định bug
1.1. Bug tí hon
Cũng có thể coi, bug này là một loại bọ, vì sao lại gọi là một loại bọ, vì hầu hết chúng có kích thước vô cùng nhỏ, nhỏ hơn so với đồng loại của chúng. Nhưng mà để có thể đối phó và tiêu diệt được loại bug như thế này không phải là điều dễ dàng gì. Như vậy khi tiêu diệt bug tí hơn này, bạn chắc chắn nhận được các loại compile error, không dừng lại ở đó, tiếp sau đó bạn sẽ phải tốn rất rất nhiều thời gian, thậm chí là nguyên một ngày chỉ để tìm ra cho bằng được đoạn code có vấn đề. Tất cả các lỗi như vậy hầu hết sẽ đến từ việc bạn quên dấu chấm phẩy, hoặc có thể là dấu 2 ngoặc,… Ở trong một vài ngôn ngữ kiểu lập trình như là Python, Java, PHP, Nodejs hay Node red, thì chắc hẳn bạn có thể sẽ gặp các vấn đề mà bạn không ngờ tới như khi bạn thụt lề sai… Có một may mắn đó chính là, hầu hết các lỗi nhỏ mắc phải sẽ được phát hiện ra khi mà có sử dụng đến các IDE phù hợp. Đây được liệt kê vào danh sách là một trong những loại bug gây ra khó chịu nhất trong các loại khác cùng giống loài với chúng. Vì như dân công nghệ thông tin chuyên nghiệp có thể biết được rằng bug tí hơn chúng có thể dễ dàng sửa chữa nhưng có lẽ phải dành ra cả thanh xuân chỉ để xác định được vị trí của chúng.
1.2. Bug không tồn tại
Theo như đúng cái tên gọi của chúng thì loại bug như thế này thật sự hay thậm chí chúng còn không tồn tại. Nhưng vấn đề mắc phải ở đây đó là compile error chúng cứ nhảy lung tung, nhảy ra liên tục, mặc kệ và cho dù bạn đã review code thế nào đi nữa. Những việc tương tự như vậy hoàn toàn có thể xảy ra khi mà lập trình biên dịch bị lỗi hoặc do bạn dùng sai. Bực mình mình ở chỗ, bạn sẽ bị báo lỗi, trong khi đó bạn hoàn toàn không có bất cứ một lỗi nào xảy ra. Lúc này, các trình biên dịch cũ ở đây sẽ rất có thể không hỗ trợ các tính năng mới mang tính hiện thành. Bạn cũng nên cho mình cập nhật một trình biên biên dich càng thường xuyên thì lại càng tốt. Có một lời khuyên dành cho bạn ở đây đó là: Về phần trình biên dịch, bạn phải chọn nó sao cho thật phù hợp và cẩn thận hơn cả chọn vợ, chọn chồng để cưới. Nhưng thỉnh thoảng, đến một lúc nào đó thì code của bạn sẽ có thể chạy cực kỳ chơn tru nhưng rồi lại bị báo lỗi sau khi đã cập nhật trình biên dịch. Điều như thế này thì nó có nghĩa là trình viên dịch đó chỉ đơn giản là đang hiển thị lên cho bạn thấy các lỗi đang tồn tại mà trước đó không thể nào phát hiện được ra.
1.3. Bug khủng
Về phần bug khủng thì khi mà bạn gặp những bung như thế này khi những dòng chữ code bạn đánh mắc những lỗi về cú pháp hoặc là gõ sai những lỗi chính tả. Và tất yếu, những bug như vậy thường nó sẽ được bắt nguồn từ những lỗi đến từ thuật toán, logic hoặc sẽ là lỗi tài nguyên … Trong cái lỗi tài nguyên ấy sẽ gồm có cả việc mà bạn sử dụng sai cách những laoij tài liệu của nó, cùng với đó là sai luôn cả khoanh vùng phạm vi truy vấn. Một cú pháp riêng không liên quan gì đến nhau sẽ được dành riêng cho những ngôn từ lập trình khác nhau, không ngôn từ lập trình nào sẽ được giống cái nào, và hơn hết là phải cần theo dõi nó thật tỉ mỉ. Chỉ cần có tín hiệu xô lệch nhẹ đi một chút ít thôi sẽ chắc như đinh làm hỏng đi mọi thứ còn lại. Nhưng có một điều suôn sẻ ở đây đó chính là một trình biên dịch mà tốt thì hoàn toàn có thể có năng lực phát hiện được ra lỗi như vậy và được cho phép bạn được thay thế sửa chữa lại chúng .
1.4. Bug ẩn thân
Ở trong bug ẩn thân này thì so với việc mắc những lỗi tựa như như vậy sé không khi nào được hiển thị lên trong quy trình đang biên dịch. Nó chỉ làm được sau khi mà ứng dụng đã được setup hoàn tất và đang trong quy trình sử dụng, và tất yếu khi đang trong quy trình sử dụng bạn sẽ chắc tháy được những bộc lộ của chúng ra sao, như thế nào ? Cùng đó chúng sẽ xảy ra những sự cố và một số ít những hoạt động giải trí ngoài mong ước. Và có vẻ như, trong hầu hết những trường hợp như vậy thì những bug ẩn danh nằm trên dạng là một lỗ hổng khiến cho những ứng dụng tương tự như như vậy sẽ trở nên không bảo đảm an toàn và dẽ dàng bị hack .
1.5. Bug bất ngờ
Lại một lần nữa đúng với tên gọi của nó, chính là khi bug Open một cách thật giật mình từ hư không. Code của bạn sẽ hoàn toàn có thể đang chạy một cách cực kỳ hoàn hỏa trong ngày ngày hôm nay. Nhưng rồi bằng một cách nào đó, nó sẽ tự dưng trở nên không tuyệt vời nữa chỉ trong ngày hôm sau. Chỉ vì nó mà bạn sẽ phải tự đặt ra cho mình hàng tá câu hỏi như là : liệu đã có ai đó nghịch được dòng code của mình trong khi mình vắng mặt ? Số lượng code càng nhiều thì bạn lại càng thuận tiện hơn trong việc debug. Có một số ít lỗi mà bạn chỉ cần mất khoảng chừng 5 giây, nhưng ngược lại cũng sẽ Open ra một sỗ lỗi khiến cho bạn mất đến 5 ngày chứ không phải 5 giây sđể kiểm soát và điều chỉnh, sửa chữa thay thế lại nó. Thậm chí có cả trường hợp, có những bug mà đến cả cuộc sống thanh xuân của bạn cũng không hề kiểm soát và điều chỉnh và thay thế sửa chữa lại nó. Hãy luôn nhớ một điều như thế này, trong quy trình sửa lỗi của bạn, bạn cũng hoàn toàn có thể sẽ lại thêm 5 lỗi nữa khi mà bạn đang cố sửa 2 bug. Và nếu như mà những dòng code bạn gõ đang hoạt động giải trí tốt, thì đừng để bị lừa, điều bạn cần làm là đừng nên đụng gì tới nó nữa thì hơn .
2. Có nên chày cối fix bug ngay không
Vậy fix bug là: Các bạn có thể hiểu đơn giản fix bug mình đang nói ở đây là sửa lỗi, giải quyết vấn đề đang vướng mắc trong lĩnh vực chuyên ngành công nghệ thông tin như lỗi trong khi lập trình, lỗi khi sử dụng phần mềm mà không được như ý muốn của các bạn.
Câu vấn đáp là không. Các bạn không nên nhất thiết phải giải quyết và xử lý yếu tố ngay. Vì bug còn đến nhiều và đến hằng ngày. Mình cũng liên tục phải gặp những yếu tố trong khi lập trình, trong khi sử dụng những ứng dụng kiểm thử bảo mật thông tin. Qua nhiều lần thức đêm sấp mặt để fix bug mình thấy không có chút hiệu suất cao nào. Có những lỗi mình mất hàng tuần liền mà không xử lý được. Một ngày đẹp trời, mình lôi máy tính ra, chạy mấy dòng lệnh, fix nhẹ và làm theo hướng dẫn ( tiếng anh nha ), như một giật mình và không báo trước, chương trình, ứng dụng hết bug. ( Hehe cũng chỉ là như mong muốn thôi nha ). Ý mình muốn nói tới ở đây là những bạn nên có thói quen giờ giấc kỉ luật, ăn ngủ chơi hài hòa và hợp lý. Nếu chỉ vì fix bug mà phá vỡ kĩ luật đó thì đó là bug lớn nhất mà bạn không khi nào fix được .
StackOverFlow
DaynhauhocBí mật fix bug. Chả có gì bí hiểm lắm, những bạn chỉ cần giỏi tiếng anh. Tiếng anh rất quan trọng với lập trình viên ( nói câu hơi thừa ). Khi gặp lỗi, những bạn nên search bằng tiếng anh, kể cả khi tìm kiếm tài liệu học lập trình. Nếu bạn không giỏi tiếng anh, bạn đã bỏ lỡ đi khối lượng kiến thức và kỹ năng gấp trăm lần bạn đang có chỉ với tiếng việt .
3. Một số quy tắc dùng để xác định bug
Một trong số những lỗi phần mềm mà xuất hiện khi 1 hoặc sẽ có thể là nhiều hơn trong 4 quy tắc dưới đây là đúng: Nó không được thực hiện giống như mô tả trong bản đặc tả phần mềm Áp dụng quy tắc này, qa tester kiểm thử chỉ cần luôn nắm được yêu cầu phần mềm thì việc xác định bug cũng sẽ đơn giản hơn.
VD 1 : Thử vận dụng quy tắc trên để nghiên cứu và phân tích lỗi trong ứng dụng Calculator, với nhu yếu nói rõ rằng : ‘ nó phải thực thi phép cộng, phép trừ, phép nhân, phép chia đúng ‘ .Bạn hãy thử tự mình để kiểm tra, nếu như bạn ấn vào nút dấu cộng + trên bàn phím mà lúc ấy nó không hề có chuyện gì cảy ra, thì lúc đó là do bug này đã theo đúng quy tắc, và do là nó không thực thi giống như ở diễn đạt. Tưng tự như trường hợp vậy, nếu như câu vấn đáp mà bạn nhận được là sai, thì nên nhớ cũng đừng có vội nghĩ rằng đó là một bug .VD2 : Kiểm tra công dụng của nút Back ở trang hiệu quả tìm kiếm của một website : VD1_Image1_noback. jpg Ở VD này nút ‘ Back ‘ không được thao tác theo phong cách thiết kế ( Not Working as Designed ). Vì nó không làm đúng công dụng nhu yếu nên nó rõ ràng là một bug .- Khi nào thì không phải là một bug : Một bug hoàn toàn có thể đúng với 1 hoặc nhiều hơn trong 4 quy tắc trên. Vậy ngược lại khi nó không đúng với bất kể nguyên tắc nào trên đó nhưng vẫn chưa xác lập được đúng chuẩn và rõ ràng là bug hay không ? Hãy cùng thử vấn đáp mỗi câu hỏi dưới đây cho mỗi yếu tố đang gặp, hoàn toàn có thể bạn sẽ biết được có nên đưa nó vào list bugs không hay là feedback nó :Nó có khó hiểu, khó sử dụng hay cản trở năng lực của người dùng sử dụng ứng dụng không ? Bạn hoàn toàn có thể làm nó xảy ra từ hai lần trở lên không ? Nếu chỉ xảy ra 1 lần, nó có tạo ra hiệu quả xấu đi đáng kể không ? Nó có làm mất hứng thú của người dùng sử dụng không ? Nó có gì trái ngược hay xích míc không ? Nó có phải là cách tối ưu nhất không ? Bạn có mong đợi nó xảy ra theo một cách khác ?
VD2: Đối với những lỗi mà nó không thể được tái hiện ở lần thứ hai (và không chỉ ra được kết quả ảnh hưởng) thì nó sẽ bị ưu tiên thấp và có khả năng sẽ bị từ chối. Lỗi này được gọi tên là ‘Once Upon a Time Bug’. VD4_Image7_header.jpg VD4_Image8_badcache.jpg Có thể ban đầu chúng ta bắt gặp nó là lỗi nhưng thật ra lại chỉ bị với trình duyệt của bạn, đó có thể là những lỗi như: hình ảnh bị hỏng, các nút không click được, lỗi đồng bộ video, … Cách thông minh nhất để bug đó không bị từ chối là xóa bộ nhớ cache, khởi động lại trình duyệt và re-test lại để xác nhận lỗi.
VD3 : Không nhập gì vào ô tìm kiếm, khi nhấn Search thì load lại một trang trắng. VD3_Image3_Search. jpg Bản đặc tả đã không nhu yếu về tính năng reload lại trang trong trường hợp này, nó hoàn toàn có thể không tác động ảnh hưởng đến việc sử dụng ứng dụng của người dùng. Tuy nhiên người dùng không mong đợi như vậy, nó được coi là một lỗi UX .Dựa theo những quy tắc, bạn hãy vận dụng linh động với ứng dụng mà mình sử dụng hàng ngày. Khi bám chặt theo quy tắc trên, bạn sẽ thuận tiện tìm ra được cho mình câu vấn đáp cho mỗi yếu tố mình gặp phải. Do đó số bugs được gật đầu sẽ nhiều hơn, giảm số bugs phải reject. Và hơn hết, khi một yếu tố không rõ ràng hoặc bạn không chắc về nó, bạn cho là không phải bug và cần feedback, thì tốt nhất nên tạo Q&A cho BA, PM hay người mua. Trong trường hợp bị phủ nhận, chỉ cần nhớ rằng người mua không phải nói bạn sai ! Chỉ là phát hiện của bạn không cung ứng được nhu yếu trong ứng dụng của họ trong quá trình này mà thôi .
Bài viết trên của timviec365.vn hi vọng đã giải đáp phần nào thắc mắc của các bạn về các vấn đề có liên quan đến Bug là gì. Từ đó giúp các bạn trẻ xác định được rõ hơn về những công việc hay gặp trong tương lai khi ứng tuyển it việc tại công ty công nghệ nào đó. Ngoài ra, website timviec365.vn còn là một trang web hàng đầu chuyên về đăng tin tuyển dụng, giúp các bạn dễ dàng hơn trong việc tìm được công việc ưng ý cho mình. Chúc các bạn thành công với timviec365.vn.
