App điểm danh báo Minh vắng học, dù Minh đang ngồi ngay hàng đầu. Cả trăm dòng lệnh, một chỗ sai. Cuốn này kể cách CLB Tin học tìm ra đúng chỗ đó — không đoán mò, mà thu hẹp dần như một thám tử loại nghi phạm.
Sau vụ điểm danh nhầm, Minh xin thầy Huy cho xem CLB Tin học sửa lỗi thế nào.
Minh còn nhớ rõ: hôm trước, app điểm danh của trường báo Minh "vắng học" dù Minh đang ngồi ngay hàng đầu, giơ tay phát biểu liên tục. Cả lớp cười ồ, thầy Huy chỉ cười trừ: "Chắc app có lỗi (bug) gì đó, để thầy xem lại."
Chiều đó, Minh với Bống mò xuống phòng Tin, thấy thầy Huy cùng hai anh chị CLB Tin học đang ngồi trước màn hình — không phải một dòng lệnh, mà là hàng trăm dòng chữ xếp chồng lên nhau, dài ngoằng.
Bống thì thầm: "Chữ nhiều thế này, tìm một chỗ sai kiểu gì đây?"
Ở bài trước, mình đã học: một chỗ trong lệnh không khớp với ý người viết muốn thì gọi là bug — hạt sạn làm hỏng cả mẻ bánh. Bài này là chuyện tìm ra đúng hạt sạn đó.
Đây mới là vấn đề thật.
Một anh CLB Tin học giải thích: đoạn chương trình điểm danh có hơn 200 dòng lệnh. Lỗi chỉ nằm ở đúng một hoặc vài dòng trong số đó — nhưng đọc hết 200 dòng từ trên xuống dưới, cố hình dung máy chạy ra sao ở từng dòng, thì cả buổi chiều cũng chưa chắc xong.
Minh hỏi: "Vậy sao không thử sửa đại chỗ nào nhìn có vẻ khả nghi trước?"
Chị lớp 9 lắc đầu: "Bọn chị từng làm thế rồi — sửa một chỗ, chạy lại, lỗi vẫn còn y nguyên. Sửa tiếp chỗ khác, lỗi vẫn còn. Tốn cả tiếng đồng hồ mà chẳng tới đâu."
Nếu thử sửa đại không ăn thua, phải làm sao?
Minh ngồi nhìn màn hình, nghĩ bụng: "Nếu là mình đi tìm một món đồ bị giấu trong nhà, mình có lục hết từng ngăn kéo của cả căn nhà cùng lúc không? Hay mình sẽ kiểm tra từng phòng một, loại dần phòng nào chắc chắn không có?"
Bống gật gù: "Ừ, kiểu như — kiểm tra phòng khách trước, không có, bỏ qua. Kiểm tra bếp, không có, bỏ qua. Cứ thế thu hẹp dần."
Cả hai cùng quay sang hỏi: "Vậy làm cách đó với 200 dòng lệnh được không ạ?"
Đúng chóc — đó chính xác là cách CLB Tin học đang làm.
Anh CLB Tin học tạm tắt (comment) đi một nửa chương trình, chỉ giữ lại phần đầu, rồi chạy thử lại. Lỗi vẫn còn y nguyên.
"Vậy lỗi không nằm ở nửa sau" — anh nói, rồi tắt tiếp một nửa của phần còn lại, chạy lại lần nữa. Lần này lỗi biến mất.
"À, tức là lỗi nằm ở đúng phần vừa tắt lần này!" Bống reo lên. Chỉ sau ba, bốn lần thu hẹp như vậy, từ 200 dòng, khu vực nghi ngờ co lại còn đúng 5 dòng.
Không phải chuyện chỉ CLB Tin học trường Ánh Dương mới làm.
Trong máy tính, việc tìm và sửa lỗi (bug) một cách có hệ thống như vậy — không đoán mò, mà thu hẹp dần — được gọi là DEBUG (gỡ lỗi).
"Debug" đến từ chính chữ "bug" (con bọ) mà mình đã học ở bài trước — de-bug nghĩa đen là "bắt con bọ ra khỏi máy".
Bất cứ ai cố tìm nguyên nhân một vấn đề bằng cách thu hẹp dần khả năng — thợ điện, bác sĩ, hay chính em khi tìm xem bài tập sai ở phép tính nào — đều đang debug, dù chẳng ai gọi tên nó như vậy.
Đây là chặng quan trọng nhất — đọc kỹ nhé.
Debug hiệu quả dựa trên một nguyên tắc rất rõ ràng: chia nhỏ phạm vi nghi ngờ, kiểm tra từng phần xem lỗi còn xảy ra không, rồi khoanh vùng dần — thay vì cố đọc/sửa toàn bộ cùng một lúc.
Ẩn dụ "thám tử loại nghi phạm" đúng ở chỗ: cả hai đều dùng bằng chứng (lỗi còn hay hết) để loại dần khả năng, không dựa vào "linh cảm ai đó là thủ phạm". Nhưng khác thám tử ở một điểm: thám tử phải suy luận từ manh mối gián tiếp, còn debug có thể chủ động tạo ra bằng chứng — cứ tắt thử một phần, chạy lại, là biết ngay lỗi còn hay hết, không cần đoán.
Một điều quan trọng khác: sửa mà chưa xác định đúng nguyên nhân thường chỉ "che" triệu chứng. Ví dụ nếu Minh chỉ sửa cho app "không hiện chữ vắng học" mà không tìm ra vì sao nó tính sai, lỗi gốc vẫn còn đó — có thể lại hiện ra ở một chỗ khác, kiểu khác, vào một ngày khác.
Cách nghĩ này không chỉ dùng cho máy tính.
Tối đó về nhà, đèn phòng Minh bỗng không sáng. Theo phản xạ, Minh định chạy đi mua bóng đèn mới ngay — nhưng sực nhớ bài học chiều nay.
Bố Minh, vốn hay sửa đồ điện trong nhà, làm đúng như CLB Tin học: kiểm tra cầu dao trước (vẫn bật) → kiểm tra ổ cắm bằng một thiết bị khác (vẫn có điện) → kiểm tra dây điện (không đứt) → cuối cùng mới tới bóng đèn — và đúng là bóng đèn cháy thật.
Thử hình dung nếu ai cũng sửa lỗi theo kiểu đoán bừa.
Không có cách debug có hệ thống, sửa lỗi phần mềm sẽ tốn rất nhiều thời gian đoán mò — tệ hơn, người sửa dễ "sửa nhầm chỗ", vô tình tạo ra lỗi mới trong khi lỗi gốc vẫn còn nguyên, chỉ là trốn kỹ hơn.
Với một chương trình nhỏ như app điểm danh 200 dòng, đoán mò có khi vẫn ra được đáp án sau vài tiếng. Nhưng phần mềm thật (mạng xã hội, ngân hàng, game...) có thể có hàng triệu dòng lệnh — không có cách thu hẹp dần có phương pháp, gần như không ai sửa nổi.
Nhiều hơn em nghĩ đấy.
Khi điện thoại/máy tính "đơ", cách thử tắt bớt từng app đang chạy để tìm ra app nào gây lag chính là một dạng debug đơn giản ai cũng làm được — tắt app này, hết đơ chưa? Chưa thì bật lại, tắt app khác thử tiếp.
Giờ đến lượt em thử sức — tự-kiểm-tra bên dưới, và viết ra một câu hỏi của riêng em nếu còn thắc mắc điều gì.
Bấm vào câu trả lời em nghĩ là đúng — không chấm điểm, chỉ để em tự soát lại.
1. Debug đúng nghĩa nhất là gì?
2. Nếu tắt một phần chương trình mà lỗi vẫn còn, điều đó có nghĩa là gì?
3. Sửa lỗi mà chưa xác định đúng nguyên nhân thường dẫn tới điều gì?
Còn điều gì về debug/sửa lỗi mà em vẫn thắc mắc? Viết ra đây — không cần đúng, chỉ cần thật.
Câu hỏi của em sẽ hiện ở đây, chỉ lưu trên máy này thôi.
Cuộn nốt xuống dưới nhé — sắp xong trang này rồi!
Chặng cuối — nếu chỉ nhớ một câu, hãy nhớ câu này.
Lần sau bạn thân của em than "bài này sai rồi mà tìm mãi không ra chỗ sai", em có thể gợi ý: "Thử che một nửa bài đi, tính lại xem đoạn nào ra đúng, đoạn nào ra sai — thu hẹp dần như debug ấy."