Lập Trình Viên Cần Học Những Gì Từ Bug

Cập nhật ngày: 25/01/2022 - Đã có 721 lượt xem bài viết này!
Lập Trình Viên Cần Học Những Gì Từ Bug
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.

Lập Trình Viên Cần Học Những Gì Từ Bug

Việc tìm và fix bug đem lại rất nhiều niềm vui cũng như cơ hội học hỏi, phát triển nghề nghiệp. Sau đây là một số tổng kết của tôi về:

-  4 lợi ích của việc fix bug.
-  Cách ghi lại bug hiệu quả.
-  3 bài học lớn và 18 kinh nghiệm xương máu về fix bug.

I. LẬP TRÌNH VIÊN CẦN HỌC NHỮNG GÌ – LỢI ÍCH CỦA FIX BUG

Trong mỗi trường hợp, bạn đều có thể học đôi điều về phong cách lập trình, sản phẩm, hoặc về lĩnh vực mà phần mềm đang hoạt động.

Trên hết, có 4 lí do chính, cũng là 4 niềm vui quan trọng nhất mà việc fix bug có thể đem lại cho lập trình viên như sau:

1. Mỗi bug luôn dạy bạn điều gì đó.

Feedback luôn là chìa khóa của phát triển sản phẩm, đồng thời cũng là triết lý cốt lõi của mô hình agile.

Cả unit testing và iterative development đều nhằm đưa ra feedback nhanh hơn. Với unit testing, bạn nhận được feedback về việc code có chạy hay không, và với mỗi release bạn có thể lắng nghe feedback của khách hàng về các tính năng mới.

Báo cáo bug cũng là hình thức feedback khác về code của bạn.

Có thể có rất nhiều nguyên nhân gây ra một bug. Ví dụ:

-  Bạn có các câu lệnh if lồng nhau và vô tình lại đặt lệnh else ở sai nhánh.
-  Giả định không chính xác (chẳng hạn: truy xuất một thuộc tính không tồn tại, thế là dính NullPointerException).
-  Không bao quát hết các trường hợp (chẳng hạn, bạn phải trả về một giá trị khác đi nếu hàm được gọi với tham số X)
-  Hoặc, khách hàng sử dụng phần mềm theo cách mà bạn không ngờ tới (nhưng vẫn hợp lệ), và thế là bùm! Dính bug!

Đào sâu tìm hiểu nguyên nhân gây ra bug, bạn sẽ đúc rút được nhiều bài học quý giá.

2. Code của bạn sẽ dễ debug hơn.

Một khi đã phải bỏ công sức, thời gian ra để tìm và fix bug, tự khắc bạn sẽ muốn viết code càng dễ debug càng tốt. Bởi vì sẽ rất khốn khổ nếu không có mọi dữ liệu cần thiết.

Một vấn đề cực kì dễ gặp là các Exceptions (biệt lệ) không chứa dữ liệu hữu ích. Ví dụ như, có một đoạn code yêu cầu giá trị từ 0 – 20. Bao nhiêu lần bạn dính exception chỉ vỏn vẹn “Illegal value”? Nó hoàn toàn không giúp gì nếu bạn phải sửa lỗi. Chẳng hạn, nếu như giá trị 21 được nhập vào, exception nên nói là “Illegal value: 21, not in range 0 – 20”.

Việc hiển thị giá trị được nhập vào cùng với khoảng giá trị mong muốn, rõ ràng vô cùng hữu ích. Giá trị hiện tại có thể là 21, -128 hay 65535. Chúng đều giúp bạn có manh mối để tìm ra lỗi, hơn là dòng “Illegal value” ngắn gọn.

Ngay cả Steve McConnell thi thoảng cũng phá luật này trong cuốn sách tuyệt vời Code Complete. Chẳng hạn, trong chương 15, McConnell nêu ra tình huống phát hiện một kiểu ký tự không mong muốn, nhưng thông báo lỗi lại không hiển thị ký tự đó.

Như vậy, mỗi khi tìm và fix bug, bạn cần tự hỏi: liệu có thể thay đổi điều gì trong code để sau này không gặp phải những bug dạng này không? Liệu có cách nào hoặc điều gì mình nên làm, để sau này tìm ra những bug dạng này dễ dàng hơn không?

3. Fix bug đem lại niềm vui cho cả bạn và khách hàng.

Một trong những niềm vui mà công việc lập trình mang lại, theo tôi, đó là làm điều có ích cho người khác. Fix bug cũng đem đến niềm vui tương tự, và thậm chí còn nhanh chóng hơn.

Bởi lẽ, để tạo ra một tính năng mới cần tốn khá nhiều thời gian, trong khi việc fix một bug có thể chỉ cần một giờ đồng hồ. Mỗi bug được fix xong sẽ đem đến khoái cảm đã hoàn thành/đạt được điều gì. Và đó là một cảm giác tuyệt vời!

Fix bug cũng đem lại niềm vui cho khách hàng (dù nghe có vẻ oái oăm: nếu ngay từ đầu không có bug, không phải fix bug, thì chẳng phải khách hàng sẽ vui hơn sao?) Nhưng, từ kinh nghiệm hơn 20 năm lập trình và “chiến đấu” với bug, tôi dám khẳng định: khách hàng thực sự hài lòng mỗi khi nhận được bug được fix xong nhanh chóng.

Vấn đề là vậy: tất cả mọi người đều biết SẼ LUÔN CÓ BUG! Cho nên, miễn là có người sẵn sàng fix thật nhanh ngay khi bug được khui ra.

4. Niềm vui của việc giải câu đố.

Rất nhiều lập trình viên thích giải câu đố, như chơi trò Sudoku, giải ô chữ, giải đố vui toán học, hay tham gia các thử thách lập trình. Thậm chí, đọc truyện trinh thám giết người cũng đem lại rất nhiều hứng khởi: bạn lần theo các manh mối để tìm hiểu mọi chuyện đã diễn ra như thế nào.

Debug và fix bug cũng vậy. Mỗi bug là một bí ẩn cần khám phá.

Thông thường, phản ứng đầu tiên của bạn khi trông thấy một báo cáo bug sẽ là: Không thể nào! Tại sao có thể xảy ra bug này được?!?

Và cũng từ đó, bạn bắt đầu hành trình khám phá bí ẩn. Bạn lần theo các manh mối. Logs nói gì? Có báo cáo lỗi nào từ hệ thống không? Tại thời điểm đó, hệ thống có xảy ra vấn đề gì khác hay không? Gần đây có cái gì bị thay đổi không – phần mềm mới, thay đổi cấu hình, lưu lượng truy cập ảnh hưởng?


BTV.Trần Thị Thu Huyền
Phòng Truyền Thông IMicroSoft Việt Nam
Hotline: 0916 878 224
Email: huyenttt@imicrosoft.edu.vn

Xem khóa đào tạo nhân sự theo danh mục!

Xem các khóa đào tạo nhân sự