Bug là gì? Lập trình viên cần học những gì từ bug? Đó là một câu hỏi không mấy vui vẻ, bởi có lẽ hầu hết lập trình viên đều muốn làm tính năng mới, chứ chả mấy ai thích phải bảo trì sản phẩm có sẵn hay là fix bug.
Hướng dẫn cách ghi lại bug cho lập trình viên
1. Bug là gì?
Bug là những lỗi phần mềm trong chương trình hoặc hệ thống máy tính làm cho kết quả không chính xác hoặc không hoạt động như mong muốn. (Theo wikipedia)
Debug là quá trình tìm kiếm và phát hiện lỗi trong phần mềm trước khi launching, đưa sản phẩm đến tay người dùng. Debug diễn ra ngay sau khi những dòng code đầu tiên được viết và tiếp tục được thực hiện cho đến khi kết hợp với những unit khác của lập trình tạo thành một sản phầm phần mềm hoàn chỉnh.
Fixbug (sửa lỗi) là quá trình triển khai ngay sau debug, nhằm duy trì hoặc nâng cao chất lượng sản phẩm.
2. Cách ghi lại Bug
Làm thế nào để học hỏi hiệu quả nhất từ những bug chúng ta đã fix? Phương pháp mà tôi dùng là luôn dành ra vài phút để ghi chú lại các thông tin: mô tả bug, cách fix, bài học kinh nghiệm.
Tóm Tắt
Nguyên tắc:
Chỉ ghi chú những bug khó nhằn hoặc thực sự thú vị. Đây không phải là bug tracker.
Ghi chú những bug do chính mình gây ra. (Trừ trường hợp bug của người khác nhưng đủ thú vị).
Ghi lại bug ngay sau khi fix xong. Tránh nhớ nhầm, nhớ không chi tiết.
Cách ghi lại bug:
Tôi thường dùng form dưới đây để ghi lại bug dưới dạng file text (bugs.txt).
Ví dụ:
- Ngày: 2004-08-17
- Triệu chứng: Vòng lặp vô tận khi giải mã tín hiệu Q.931.
- Nguyên nhân: Khi tìm thấy id của một thành phần chưa biết trong tín hiệu Q.931, ta tìm cách bỏ qua nó bằng cách lấy chiều dài, và di chuyển con trỏ pos tương ứng với độ dài tìm được. Tuy nhiên, với trường hợp độ dài bằng 0 làm ta liên tục bỏ qua cùng 1 id.
- Cách tìm ra: Nhờ vào phân tích tín hiệu SETUP lấy từ trace của Ethereal ở Nortel. Tín hiệu của họ có độ dài 1016 bytes, nhưng MSX_MAX_LEN chỉ có 1000. Bình thường ta sẽ nhận một tín hiệu bị cắt từ common/Communication.cxx, nhưng ở đây khi cung cấp dữ liệu trực tiếp để phân tích, khoảng bộ nhớ vượt quá array bị truy cập, và vô tình nó bằng 0, làm xuất hiện lỗi. Để sửa lỗi, tôi đã thêm vào vài lệnh print trong phần code phân tích Q.931. Nhưng may mắn là dữ liệu lại bằng 0.
- Sửa: Nếu chiều dài tìm thấy bằng 0, đặt nó lại bằng 1. Như vậy chúng ta sẽ luôn đi tiếp được.
- Sửa trong file(s): callh/q931_msg.cxx
- Thủ phạm là tôi: Đúng vậy.
- Thời gian sửa bug: 1 giờ.
- Bài học: Đặt “niềm tin lầm chỗ” vào dữ liệu của tín hiệu gửi tới. Giá trị dữ liệu có thể quá lớn làm chương trình chạy sai. Ngoài ra khi chiều dài bằng 0 cũng có thể là một dấu hiệu xấu.
Tại sao lại xảy ra bug trong quá trình phát triển phần mềm?
Có rất nhiều lý do gây ra lỗi (bug). Lý do phổ biến nhất là do con người tạo nên – trong quá trình design và coding. Sản phẩm càng có yêu cầu phức tạp thì khả năng tồn tại nhiều bug càng cao. Và không thể tự tin để nói rằng sản phẩm của mình là Bug Free.Vậy câu hỏi đặt ra là: Những yếu tố nào dẫn đến bug trong sản phẩm?
1. Yếu tố con người
Con người góp phần tạo nên sản phẩm, mà đã là con người thì không thể hoàn hảo.Con người sẽ tạo ra sai lầm và không thể khẳng định chắc chắn rằng sản phẩm phần mềm mình làm ra không có bất kì lỗi nào. Và rằng chúng ta chưa tìm ra bất kì công cụ – trí tuệ nhân tạo nào có thể tạo nên sản phẩm phần mềm tốt hơn con người. Đó là lý do vì sao bug xuất hiện.
2. Thất bại trong việc trao đổi thông tin
Một lý do thường gặp khác là về việc thất bại trong quá trình trao đổi thông tin: hiểu sai, thiếu giao tiếp,… Sự thất bại này có thể xảy ra tại nhiều phases trong quá trình phát triển phần mềm: Thu thập yêu cầu, tổng hợp – giải thích yêu cầu, hiểu yêu cầu để thực hiện implement,… Nếu trong trường hợp yêu cầu mơ hồ, không rõ ràng, developer sẽ implement mà không thật sự hiểu rõ yêu cầu, vì vậy dẫn đến bug. VÀ một trường hợp khác, khi 1 developer cố gắng sửa một đoạn code của một người khác và thiếu đi sự trao đổi giữa hai bên.
3. Khung thời gian phát triển không thực tế
Sản phẩm thường được phát triển theo lịch trình gấp gáp, dồn dập, với nguồn lực hạn chế. Vì vậy, để đáp ứng kịp thời hạn release, đôi khi sẽ không có đủ thời gian để thiết kế, code và kiểm thử một cách cẩn thận. Một sự thay đổi yêu cầu nhỏ vào thời gian cuối sẽ dẫn đến sự thay đổi của code và có khả năng gây ra bug.
4. Logic design kém
Trong thời đại phát triển phức tạp của hệ thống phần mềm, đôi khi phần mềm phức tạp đến mức nó đòi hỏi rất nhiều sự nghiên cứu, phát triển và động não để đạt được một giải pháp đáng tin cậy. Sự thiếu kiên nhẫn và mong muốn hoàn thành nó càng nhanh càng tốt có thể dẫn đến sai sót. Áp dụng sai công nghệ (linh kiện, sản phẩm, kỹ thuật), mong muốn/khao khát sử dụng cách dễ nhất để thực hiện giải pháp, thiếu hiểu biết đúng đắn về tính khả thi của kỹ thuật trước khi thiết kế kiến trúc đều có thể gây ra lỗi. Thật không may, không phải là do chúng ta không thông minh; chỉ là chúng ta thường không-có-thời-gian/không-được-phép-nghĩ!
5. Thực hiện code kém hiệu quả
Bug thường xuất hiện bởi code yếu kém. Code yếu kém thể hiện qua việc quên xử lý lỗi/ exception hoặc xử lý không hiệu quả, thiếu validate dữ liệu ( kiểu dữ liệu, phạm vi, điều kiện biên,…). Thêm vào đó, developers có thể phải làm việc với những tool, compilers, debuggers,…kém hiệu quả.
6. Thiếu sự kiểm soát các build version
Nếu một function đã được test ở bản build trước và sau một vài lần build, bug hồi quy xảy ra thì rất khó để có thể phát hiện ra chúng. Vì vậy việc kiểm soát các bản build là rất quan trọng
7. Thiếu sót về kĩ năng kiểm thử
Ở một vài công ty, quy trình kiểm thử thường bị xem nhẹ hoặc không xảy ra. Thêm vào đó, tester thiếu hiểu biết và kinh nghiệm về kiểm thử sẽ dẫn đến việc bỏ sót bug trong sản phẩm. Ngoài ra, nếu tester không cẩn thận, không chú ý trong quá trình thực hiện test, kết quả sẽ là sản phẩm với chất lượng yếu kém và tồn tại nhiều bug nghiêm trọng.
8. Tự tin thái quá
Một số người thường thích nói những câu như “ Quá đơn giản”, “Dễ như ăn bánh”, “ Xong ngay trong một nốt nhạc”. Những sự quá tự tin như thế này thường dẫn đến việc bỏ lỡ những điểm quan trọng.
9. Sử dụng tool của bên thứ ba
Trong quá trình phát triển phần mềm, chúng ta thường sử dụng ít nhất một tool của bên thứ ba, và chính trong các tool này có thể chứa lỗi. Các tool này có thể là công cụ hố trợ lập trình (class libraries, shared DLLs, compilers, HTML editors, debuggers etc.) Nhưng lỗi trong tool này sẽ dẫn đến lỗi trong phần mềm đang được phát triển.
10.Thay đổi trong phút chót
Những thay đổi có thể xảy ra với requirement, cơ sở hạ tầng, tools, platform có thể rất nguy hiểm, nhất là khi sản phẩm chuẩn bị được release. Những thao tác như thay đổi cấu trúc cơ sở dữ liệu, làm cho sản phẩm có thể tương thích với nhiều hệ điều hành/trình duyệt khá phức tạp và nếu được làm trong thời gian ngắn sẽ dẫn đến việc xảy ra bug.
Vậy khi nào một bug không phải là bug?
Một bug 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 định được chính xác và rõ ràng là bug hay không? Hãy cùng thử trả lời mỗi câu hỏi dưới đây cho mỗi vấn đề đang gặp, có thể bạn sẽ biết được có nên đưa nó vào danh sách bugs không hay là feedback nó:
- Nó có khó hiểu, khó sử dụng hay cản trở khả năng của người dùng sử dụng ứng dụng không?
- Bạ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 kết quả tiêu cực đá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 mâu thuẫn 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?
Hãy thử áp dụng với một số tình huống lỗi
- VD1: Trong ứng dụng Calculator có những nút có kích thước quá nhỏ. Hoặc có thể sự sắp xếp của các nút đã làm cho nó khó sử dụng. Hoặc sự bố trí màu sắc làm cho nó rất khó nhìn… Tất cả những điều này đều có câu trả lời là có cho câu hỏi số 1. Nên nó được xác định là bug.
- 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’.
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.
Bản đặc tả đã không yêu cầu về tính năng reload lại trang trong trường hợp này, nó có thể không ảnh hưởng đến việc sử dụng phần mềm của người dùng. Tuy nhiên người dùng không mong đợi như thế, nó được coi là một lỗi UX.
5 loại Bug lập trình viên sẽ gặp ít nhất 1 lần trong đời
Là một lập trình viên thì việc làm quen với bug là một điều tất yếu. Nói một cách đơn giản hơn, một bug có thể được định nghĩa là một lỗi trong một chương trình. Trong quá trình viết code, các lập trình viên không thể tránh khỏi việc mắc phải sai lầm. Các sai lầm này thường được thể hiện dưới dạng bug trong code. Viết code là phần dễ dàng. Bước khó khăn là debug (tức là tìm error hoặc bug trong chương trình).
Quá trình này khiến các dev điên đầu vì lại tạo thêm n bug khác thay vì sửa bug hiện tại.
Dưới đây là 5 loại bug điển hình mà bất kỳ dev nào cũng gặp phải ít nhất một lần trong đời.
1. Bug tí hon
Bug này là một loại ‘bọ’ có ‘kích thước’ nhỏ hơn nhiều so với đồng bạn, nhưng để đối phó với loại bug này không phải là một nhiệm vụ dễ dàng. Bạn sẽ nhận được các loại compile error và sau đó có thể tiêu tốn hàng giờ đồng hồ hoặc thâm chí cả ngày trời chỉ để tìm ra đoạn code có vấn đề. Các lỗi như vậy bao gồm việc quên dấu chấm phẩy ‘;’ hoặc các loại dấu ngoặc ‘()’.
Trong một vài ngôn ngữ lập trình, ví dụ như Python, bạn có thể gặp các vấn đề như khi thụt lề sai. Các lỗi nhỏ có thể được phát hiện khi sử dụng các IDE phù hợp. Bug tí hon là loại lỗi gây khó chịu nhất trong tất cả các loại vì bạn biết chúng có thể dễ dàng sửa chữa nhưng phải dành cả tuổi thanh xuân chỉ để xác định vị trí của chúng
2. Bug không tồn tại
Loại bug này thậm chí còn không tồn tại. Vấn đề ở đây là compile error cứ thế mà nhảy ra liên tục dù bạn đã review code lại như thế nào đi chăng nữa. Việc này có thể xảy ra khi trình biên dịch bị lỗi hoặc dùng sai. Bạn có thể bị báo lỗi khi hoàn toàn không có lỗi nào.
Các trình biên dịch cũ có thể không hỗ trợ các tính năng mới hiện hành. Bạn cũng nên cập nhật trình biên dịch càng thường xuyên càng tốt. Lời khuyên là: Cần phải chọn trình biên dịch cẩn thận hơn cả khi chọn vợ. Thỉnh thoảng, code của bạn có thể chạy trơn chu nhưng bạn lại được báo lỗi sau khi cập nhật trình biên dịch. Điều này có nghĩa là trình viên dịch chỉ đơn giản hiển thị cho bạn các lỗi đang tồn tại mà trước đó không thể phát hiện được
3. Bug khủng
Bạn sẽ gặp các bug này khi code có lỗi cú pháp hoặc là sai chính tả. Các bug như vậy bắt nguồn từ các lỗi thuật toán, logic hoặc lỗi tài nguyên. Lỗi tài nguyên có thể bao gồm việc sử dụng sai loại dữ liệu và vi phạm truy cập. Mỗi ngôn ngữ lập trình sẽ đều có cú pháp riêng và cần được theo dõi tỉ mỉ. Chỉ cần một sai lệch nhẹ có thể làm hỏng mọi thứ. May mắn thay, một trình biên dịch tốt có thể phát hiện ra các lỗi như vậy và cho phép bạn sửa chữa chúng.
4. Bug ẩn thân
Các lỗi như vậy không bao giờ hiển thị trong trình biên dịch. Chỉ sau khi phần mềm được cài đặt và sử dụng, bạn sẽ bắt đầu thấy các biểu hiện của chúng. Sẽ xảy ra các sự cố và các hoạt động không mong muốn. Trong hầu hết các trường hợp, các bug ẩn nằm ở dạng lỗ hổng khiến cho phần mềm không an toàn và dễ dàng bị hack.
5. Bug bất ngờ
Là khi bug bất ngờ xuất hiện từ hư không. Code của bạn có thể chạy hoàn hảo ngay hôm nay. Nhưng bằng cách nào đó, nó sẽ không hoạt động tốt vào ngày hôm sau. Nó sẽ khiến cho bạn đặt ra câu hỏi liệu có ai đó đã nghịch code của mình trong khi mình đang ngủ?
Code càng nhiều, bạn lại càng dễ dàng debug. Một số lỗi bạn chỉ cần mất khoảng 5 giây. Nhưng cũng có những lỗi khiến bạn phải tối thời gian là 5 ngày. Hoặc thậm chí có những bug mà có thể cả đời bạn cũng không bao giờ sửa được, buồn thay…Hãy nhớ rằng bạn có thể tạo thêm 5 lỗi trong khi cố sửa 2 bug. Nếu code của bạn hoạt động, có thể bạn đừng đụng gì tới nó nữa thì hơn.
Các tìm kiếm liên quan:
- visual bug là gì
- bug code là gì
- bug là gì trong pubg
- debug là gì
- bug report là gì
- plant a bug là gì
- lỗi (fault) trong phần mềm là gì
Nội dung liên quan:
