Khi không biết lỗi nằm ở đâu, điều đầu tiên là đừng sửa bừa. Hãy làm cho lỗi xảy ra lại được theo ý mình, viết ra thật chính xác mình mong đợi điều gì và điều gì thật sự xảy ra, rồi thu hẹp dần vùng nghi ngờ bằng quan sát thay vì bằng đoán. Mỗi bước chỉ thay đổi một thứ.
Chào bạn, đây là Nhà Lập Trình. Gỡ lỗi chiếm phần lớn thời gian của người làm nghề, nhiều hơn cả viết mã mới, vậy mà hiếm trường nào dạy nó như một kỹ năng riêng. Người ta học gỡ lỗi bằng cách vấp. Tập này mình muốn rút ngắn quãng vấp đó cho bạn bằng một quy trình đơn giản.
Cái bẫy của việc sửa bừa
Khi gặp lỗi, phản xạ tự nhiên là đoán. Chắc do dòng này. Sửa thử. Không được. Chắc do dòng kia. Sửa thử. Vẫn không được. Sau một giờ, bạn đã sửa mười chỗ, lỗi vẫn còn, và giờ bạn không nhớ mình đã đổi những gì.
Tệ hơn, có khi lỗi biến mất sau lần sửa thứ bảy, và bạn không biết lần nào thật sự sửa được nó. Sáu thay đổi kia vẫn nằm trong mã, có thể chính chúng gây ra lỗi mới.
Sửa bừa có vẻ nhanh, vì bạn luôn đang làm gì đó. Nhưng nó giống như tìm chìa khoá bị mất bằng cách chạy lung tung khắp nhà. Đôi khi may mắn tìm thấy. Thường thì mất cả buổi.
Người gỡ lỗi giỏi trông có vẻ chậm lúc đầu. Họ ngồi quan sát, ghi chép, hỏi những câu có vẻ hiển nhiên. Nhưng họ tìm ra lỗi nhanh hơn hẳn, vì mỗi bước của họ đều loại bỏ được một phần không gian tìm kiếm.
Bước một: làm cho lỗi xảy ra lại được
Bạn không thể sửa một lỗi mà bạn không thấy. Việc đầu tiên là tìm cách làm lỗi xuất hiện, theo ý mình, bao nhiêu lần cũng được. Người trong nghề gọi đó là tái hiện lỗi.
Hãy hỏi kỹ người báo lỗi: họ làm những bước nào, dùng thiết bị gì, trình duyệt gì, tài khoản nào, lúc mấy giờ. Những chi tiết tưởng không liên quan thường lại là chìa khoá. Lỗi chỉ xảy ra với tài khoản có tên dài, chỉ xảy ra trên điện thoại cũ, chỉ xảy ra sau mười hai giờ đêm.
Khi đã tái hiện được, hãy cố rút gọn. Mười bước để ra lỗi, thử bỏ từng bước xem có còn lỗi không. Dữ liệu một nghìn dòng gây lỗi, thử với một trăm, mười, một dòng. Cách tái hiện càng ngắn, vùng nghi ngờ càng hẹp.
Có những lỗi rất khó tái hiện, lúc có lúc không. Mình sẽ dành một tập riêng cho chúng. Nhưng với phần lớn lỗi, dành thời gian tái hiện cho chắc là khoản đầu tư sinh lời nhất.
Bước hai: viết ra mong đợi và thực tế
Nghe thì hiển nhiên, nhưng hãy viết ra thành chữ: mình mong đợi điều gì, và thực tế điều gì xảy ra. Không phải chương trình bị lỗi, mà là khi khách thêm hai sản phẩm vào giỏ, mình mong tổng tiền là tổng giá hai món, thực tế tổng tiền chỉ tính món thứ hai.
Việc viết ra buộc bạn phải cụ thể. Và khi đã cụ thể, bạn thường thấy ngay hướng tìm. Tổng chỉ tính món thứ hai, nghĩa là có chỗ nào đó ghi đè thay vì cộng dồn.
Đôi khi, lúc viết ra, bạn nhận ra mong đợi của mình mới là cái sai. Chương trình chạy đúng theo thiết kế, chỉ là bạn hiểu thiết kế khác. Phát hiện này tiết kiệm cả buổi sửa một thứ không hỏng.
Một mô tả tốt cũng là thứ bạn đưa cho đồng nghiệp khi cần nhờ giúp. Họ sẽ vào việc ngay, không phải hỏi lại mười câu.
Bước ba: quan sát, đừng đoán
Giờ là lúc tìm. Nguyên tắc vàng là quan sát trạng thái thật của chương trình thay vì đoán nó. Dữ liệu ở bước này thực sự là gì? Biến này thực sự mang giá trị nào? Hàm này thực sự có được gọi không?
Công cụ gỡ lỗi chạy từng bước cho phép bạn dừng chương trình ở một dòng và nhìn vào mọi thứ. Nếu không có, in ra vài dòng nhật ký tạm cũng được. Quan trọng là bạn thấy tận mắt, không suy ra từ việc đọc mã.
Rất nhiều lần, mình chắc chắn một biến phải có giá trị này, nhìn vào thì nó là giá trị khác hẳn. Chỗ khác biệt giữa điều mình chắc chắn và điều thật sự xảy ra chính là chỗ lỗi đang trốn.
Hãy nghi ngờ cả những thứ bạn nghĩ là đúng. Tệp cấu hình có thật sự được đọc không? Mình có đang sửa đúng tệp, chạy đúng phiên bản không? Một nửa số lần mình mắc kẹt lâu là do đang sửa một chỗ mà chương trình không hề chạy qua.
Bước bốn: mỗi lần một thay đổi, và ghi lại
Khi đã có giả thuyết về nguyên nhân, hãy thử bằng một thay đổi duy nhất. Nếu lỗi hết, bạn biết chắc nguyên nhân. Nếu không hết, hoàn tác thay đổi đó trước khi thử cái khác. Đừng để các thay đổi thử nghiệm chồng lên nhau.
Ghi lại những gì bạn đã thử và kết quả. Một cuốn sổ hay một tệp văn bản là đủ. Nghe có vẻ thừa, nhưng sau hai giờ gỡ lỗi, trí nhớ bắt đầu lừa bạn. Bạn thử lại thứ đã thử, bỏ qua thứ chưa thử.
Khi đã tìm ra và sửa, hãy hỏi thêm: vì sao lỗi này lọt qua được? Có thể thêm một bài thử nghiệm để nó không quay lại không? Có chỗ nào khác trong mã có cùng kiểu lỗi không?
Gỡ lỗi không phải là việc của thiên tài. Nó là việc của người kiên nhẫn có phương pháp. Và cảm giác khi cuối cùng tìm ra lỗi sau một buổi chiều truy đuổi, người làm nghề nào cũng biết, là một trong những niềm vui thật nhất của nghề này.
Câu hỏi thường gặp
Gỡ lỗi là gì?
Là quá trình tìm ra nguyên nhân khiến chương trình chạy khác với mong đợi và sửa nó. Phần khó nhất thường là tìm ra nguyên nhân, còn sửa khi đã biết nguyên nhân thường nhanh.
Công cụ gỡ lỗi chạy từng bước có cần thiết không?
Rất hữu ích vì cho phép dừng chương trình và xem mọi giá trị tại một thời điểm. Nhưng in nhật ký tạm cũng là cách gỡ lỗi hợp lệ, nhiều người giỏi vẫn dùng cả hai tuỳ tình huống.
Bao lâu thì nên nhờ người khác giúp gỡ lỗi?
Khi bạn đã tái hiện được lỗi, đã thử có phương pháp mà không tiến triển trong một khoảng thời gian hợp lý, thường là một đến hai giờ. Chuẩn bị sẵn mô tả mong đợi, thực tế và những gì đã thử trước khi hỏi.
Vì sao sửa xong lỗi này lại sinh lỗi khác?
Thường do sửa vào triệu chứng thay vì nguyên nhân, hoặc do nhiều thay đổi thử nghiệm còn sót lại trong mã. Hiểu rõ nguyên nhân và thêm bài thử nghiệm giúp giảm tình trạng này.
Người mới gỡ lỗi hay mắc sai lầm gì nhất?
Đoán và sửa bừa nhiều chỗ cùng lúc, không tái hiện lỗi trước khi sửa, và tin chắc vào những điều chưa kiểm tra như đang chạy đúng tệp hay đúng phiên bản.
