Gỡ lỗi như thám tử: cách tìm chỗ sai từng bước khi làm không chạy

Gỡ lỗi là tìm ra vì sao một việc không chạy như mong muốn, rồi sửa đúng chỗ đó. Người lập trình làm việc này giống một thám tử: thu thập manh mối, đặt giả thuyết, thử từng giả thuyết, loại dần cho tới khi tìm ra thủ phạm. Kỹ năng này dùng được cả khi chiếc máy bay giấy cứ chúi đầu, cái bánh không nở hay bài toán ra đáp số lạ.

Vì sao lỗi trong máy tính gọi là "con bọ"

Trong tiếng Anh, lỗi phần mềm gọi là bug, nghĩa đen là con bọ, và gỡ lỗi là debug, bắt bọ. Có một câu chuyện nổi tiếng gắn với chữ này. Ngày 9 tháng 9 năm 1947, nhóm vận hành chiếc máy tính Harvard Mark II ở Mỹ thấy máy chạy sai. Họ mở máy ra kiểm tra và tìm thấy một con bướm đêm kẹt trong một chiếc rơ-le, loại công tắc đóng mở bằng nam châm điện. Họ dán con bướm vào sổ nhật ký vận hành, ghi chú rằng đây là "trường hợp đầu tiên thật sự tìm thấy con bọ". Trang sổ ấy nay được lưu ở Bảo tàng Quốc gia Lịch sử Hoa Kỳ.

Câu ghi chú ấy buồn cười chính vì chữ "bug" đã được kỹ sư dùng để chỉ trục trặc máy móc từ trước đó, ít nhất từ thời Thomas Edison ở thế kỷ 19. Nhà khoa học máy tính Grace Hopper, người làm việc với chiếc máy này, rất hay kể lại chuyện con bướm, nên nhiều người tưởng bà đặt ra chữ "bug". Thật ra bà chỉ làm câu chuyện nổi tiếng.

Lỗi nhỏ, hậu quả lớn

Lỗi phần mềm có khi chỉ là một con số đặt sai chỗ, nhưng hậu quả có thể rất lớn. Năm 1999, tàu thăm dò Mars Climate Orbiter của Cơ quan Hàng không và Vũ trụ Hoa Kỳ (NASA) bị mất khi tới gần sao Hỏa. Cuộc điều tra sau đó kết luận: một nhóm kỹ sư tính lực đẩy theo đơn vị đo lường Anh, nhóm khác lại hiểu con số đó theo đơn vị hệ mét. Hai phần mềm, mỗi phần tự nó đều chạy, nhưng chỗ nối giữa chúng sai. Con tàu bay theo một quỹ đạo thấp hơn dự tính rất nhiều và không bao giờ liên lạc lại được.

Bài học của các kỹ sư: phần lớn lỗi không nằm ở chỗ khó nhất, mà ở chỗ ai cũng tưởng là hiển nhiên, nên không ai kiểm tra.

Sáu bước gỡ lỗi kiểu thám tử

Không có công thức nào tìm ra mọi lỗi, nhưng người gỡ lỗi giỏi thường đi theo một trình tự giống nhau:

1. Làm cho lỗi xảy ra lại. Thám tử cần hiện trường. Nếu lỗi lúc có lúc không, hãy tìm xem nó xảy ra trong hoàn cảnh nào: lúc nào, làm gì trước đó.
2. Mô tả chính xác. Viết ra hai câu: "Mình mong đợi điều gì?" và "Thật ra điều gì xảy ra?". Câu "nó hỏng rồi" không giúp được ai. Câu "máy bay bay được khoảng một mét thì chúi mũi xuống đất" là một manh mối.
3. Đặt giả thuyết. Liệt kê những nguyên nhân có thể. Đừng vội tin cái đầu tiên nghĩ ra.
4. Thử từng giả thuyết, mỗi lần đổi một thứ. Đây là luật quan trọng nhất. Nếu đổi ba thứ cùng lúc mà lỗi biến mất, bạn không biết thứ nào đã sửa được nó.
5. Sửa, rồi kiểm tra lại. Chạy lại đúng tình huống ở bước 1. Đồng thời xem lại những thứ trước đó đang chạy tốt: đôi khi sửa chỗ này lại làm hỏng chỗ khác.
6. Ghi lại. Lỗi gì, vì sao, sửa thế nào. Lần sau gặp lại sẽ nhanh hơn, và người khác cũng học được.

Ví dụ không cần máy tính: chiếc máy bay giấy chúi đầu

Bạn gấp một chiếc máy bay giấy, ném ra, nó bay được một đoạn ngắn rồi cắm thẳng xuống đất. Áp dụng các bước trên:

Giả thuyết	Cách thử (chỉ đổi một thứ)	Nếu đúng thì thấy gì
Mũi quá nặng	Gấp lại y như cũ nhưng bớt một lớp giấy ở mũi	Máy bay lướt xa hơn
Đuôi cánh cụp xuống	Bẻ nhẹ mép sau của hai cánh hơi vểnh lên	Mũi ngóc lên, bay bằng hơn
Hai cánh lệch nhau	Mở ra, so hai cánh, gấp lại cho đều	Hết bay xiên sang một bên
Ném quá mạnh, chúc xuống	Giữ nguyên máy bay, chỉ ném nhẹ và thẳng hơn	Bay đều hơn với cùng chiếc máy bay

Để ý cột giữa: mỗi lần chỉ đổi đúng một thứ. Sau mỗi lần thử, ném ba lần chứ không phải một, vì một lần ném có thể may hay rủi. Đó cũng là cách các nhà khoa học làm thí nghiệm.

Những mẹo của người gỡ lỗi lâu năm

Khoanh vùng bằng cách chia đôi

Nếu một bản hướng dẫn 20 bước cho ra kết quả sai, đừng soi từ bước 1. Hãy dừng ở bước 10 và kiểm tra: kết quả tới đây đã đúng chưa? Nếu đúng, lỗi nằm ở nửa sau; nếu sai, lỗi nằm ở nửa đầu. Làm tiếp như vậy, sau năm lần kiểm là khoanh được tới đúng một bước. Đây là cách tìm kiếm chia đôi, được giải thích kỹ trong một bài riêng của danh mục này.

Nhìn vào giữa chừng

Người nấu ăn giỏi nếm canh nhiều lần trong lúc nấu, không đợi tới khi múc ra bát. Người lập trình cũng thế: họ cho chương trình in ra giá trị ở những chặng giữa, để biết từ chỗ nào con số bắt đầu sai.

Giải thích to cho người khác, hoặc cho một con vịt

Nhiều lập trình viên đặt một chú vịt nhựa trên bàn và giải thích từng dòng cho nó nghe. Nghe thì buồn cười, nhưng khi phải nói thành lời từng bước, ta hay tự phát hiện ra chỗ mình đã nghĩ vội. Một người bạn, một người em, hay con mèo cũng được.

So với bản từng chạy đúng

Nếu hôm qua mọi thứ còn chạy mà hôm nay hỏng, hãy hỏi: từ hôm qua tới giờ mình đã đổi gì? Câu trả lời thường chỉ ra thủ phạm nhanh hơn mọi cách khác.

Đứng dậy đi một vòng

Nhìn mãi vào một chỗ, mắt sẽ "đọc" cái mình muốn thấy thay vì cái thật sự có. Nghỉ mười phút rồi quay lại, nhiều khi lỗi hiện ra ngay.

Lỗi là chuyện bình thường

Người mới học lập trình hay nghĩ người giỏi viết ra là chạy ngay. Không phải vậy. Lập trình viên nhiều năm kinh nghiệm vẫn gặp lỗi mỗi ngày, và một phần rất lớn thời gian làm việc của họ là đọc, thử, tìm lỗi. Điều khác biệt là họ không hoảng, không tự trách. Họ coi mỗi lỗi là một câu đố có lời giải.

Với phụ huynh và thầy cô: khi trẻ gặp lỗi, câu "con thử kể xem con mong nó làm gì, còn nó thật ra làm gì" có ích hơn nhiều so với tự tay sửa giúp. Mục đích là để trẻ tự đi hết sáu bước, chứ không phải để bài làm nhanh xong.

Thử làm: tìm ba lỗi trong hướng dẫn đánh răng

Dưới đây là một "chương trình" đánh răng có cài sẵn ba lỗi. Đọc từng bước, tưởng tượng một robot làm đúng y như vậy, và tìm xem lỗi nằm ở đâu.

1. Cầm bàn chải.
2. Lặp lại 3 lần: bóp kem đánh răng lên bàn chải.
3. Súc miệng bằng nước sạch rồi nhổ ra.
4. Chải mặt ngoài các răng.
5. Chải mặt trong các răng.
6. Nếu còn thời gian thì chải mặt nhai.
7. Rửa bàn chải, cất vào cốc.

Gợi ý: tìm một vòng lặp đặt sai chỗ, một bước sai thứ tự, và một điều kiện khiến một việc cần làm có thể bị bỏ qua. Làm xong, viết lại bản đã sửa và nhờ một người làm "robot" thử theo.

Lời giải

• Bước 2: vòng lặp làm bóp kem ba lần, robot sẽ có ba lớp kem. Chỉ cần bóp một lần, lượng vừa đủ.
• Bước 3: súc miệng nằm trước khi chải, đáng lẽ phải sau. Lỗi thứ tự.
• Bước 6: mặt nhai cũng cần chải mỗi lần, không phải "nếu còn thời gian". Điều kiện thừa làm một việc quan trọng có thể bị bỏ qua.

Có bạn sẽ tìm thêm: thiếu bước làm ướt bàn chải, chưa nói chải bao lâu. Đó đều là những phát hiện tốt. Cách đánh răng đúng nên hỏi thêm nha sĩ.

Câu hỏi thường gặp

Debug là gì?

Debug, tiếng Việt gọi là gỡ lỗi, là việc tìm ra nguyên nhân khiến chương trình chạy sai rồi sửa nó. Quy trình thường gồm làm cho lỗi xảy ra lại, mô tả chính xác, đặt giả thuyết, thử từng giả thuyết, sửa và kiểm tra lại.

Vì sao lỗi phần mềm được gọi là bug?

Chữ bug, nghĩa là con bọ, đã được kỹ sư dùng để chỉ trục trặc máy móc từ thế kỷ 19. Năm 1947, nhóm vận hành máy Harvard Mark II tìm thấy một con bướm đêm kẹt trong máy và dán vào sổ nhật ký, làm cho chữ này gắn chặt với máy tính.

Grace Hopper có phải người đặt ra chữ bug không?

Không. Chữ bug đã có từ trước. Grace Hopper làm việc với máy Harvard Mark II và rất hay kể lại chuyện con bướm đêm, nên câu chuyện gắn với tên bà. Bà nổi tiếng thật sự vì những đóng góp cho ngôn ngữ lập trình.

Làm sao giúp trẻ không nản khi gặp lỗi?

Cho trẻ thấy lỗi là chuyện bình thường, ngay cả người làm nghề lâu năm cũng gặp hằng ngày. Thay vì sửa giúp, hãy hỏi trẻ đã mong điều gì và điều gì đã xảy ra, rồi cùng nghĩ xem nên thử thay đổi một thứ nào trước.

Vì sao khi gỡ lỗi chỉ nên đổi một thứ mỗi lần?

Nếu đổi nhiều thứ cùng lúc mà lỗi biến mất, bạn không biết thay đổi nào thật sự có tác dụng. Có khi một thay đổi sửa được lỗi còn thay đổi khác lại gây lỗi mới. Đổi từng thứ một giúp biết chắc nguyên nhân.