💡 Key Takeaways
- Stop Guessing and Start Hypothesizing
- Master Your Debugging Tools (Not Just Console.Log)
- Binary Search Your Way to the Bug
- Reproduce First, Debug Second
Ba năm trước, tôi đã chứng kiến một lập trình viên junior mất sáu giờ để gỡ lỗi một vấn đề sản xuất mà lẽ ra chỉ mất khoảng hai mươi phút. Vấn đề? Một biến môi trường được cấu hình sai. Vấn đề thực sự? Anh ta sử dụng các câu lệnh printf và triển khai lại lên môi trường staging sau mỗi thay đổi. Tôi đã làm Kỹ sư Cao cấp tại một công ty khởi nghiệp fintech Series C được tám năm và tôi đã thấy mẫu hình này lặp lại hàng trăm lần. Các lập trình viên mất trung bình 13,4 giờ mỗi tuần cho các thực hành gỡ lỗi kém hiệu quả, theo số liệu nội bộ của chúng tôi trên một nhóm 47 kỹ sư. Điều đó gần giống như hai ngày làm việc đầy đủ bị biến mất vào khoảng trống của các câu lệnh console.log và các thay đổi mã ngẫu nhiên.
💡 Những Ghi Nhớ Quan Trọng
- Ngừng Đoán và Bắt Đầu Đưa Ra Giả Thuyết
- Thành Thạo Các Công Cụ Gỡ Lỗi (Không Chỉ Là Console.Log)
- Tìm Bug Bằng Tìm Kiếm Nhị Phân
- Tái Tạo Trước, Gỡ Lỗi Sau
Sự thật là, hầu hết các lập trình viên không bao giờ học được cách gỡ lỗi một cách có hệ thống. Chúng tôi lang thang qua sự nghiệp của mình bằng cách sử dụng những kỹ thuật giống như những gì chúng tôi đã học trong tháng đầu tiên viết mã. Nhưng gỡ lỗi không chỉ là tìm kiếm lỗi—nó còn liên quan đến việc hiểu các hệ thống, hình thành giả thuyết và loại bỏ các khả năng với độ chính xác như phẫu thuật. Sau khi gỡ lỗi mọi thứ từ tình trạng race trong các hệ thống phân tán đến rò rỉ bộ nhớ trong các ứng dụng React, tôi đã phát triển một khuôn khổ mà liên tục cắt giảm thời gian gỡ lỗi từ 60-70%. Đây là những gì thực sự hiệu quả.
Ngừng Đoán và Bắt Đầu Đưa Ra Giả Thuyết
Sai lầm lớn nhất mà tôi thấy các lập trình viên mắc phải là coi gỡ lỗi như một trò chơi đoán. Họ thay đổi các biến ngẫu nhiên, bình luận ra các khối mã và hy vọng điều gì đó đúng. Cách tiếp cận này đôi khi có thể ngẫu nhiên tìm thấy giải pháp, nhưng nó vô cùng kém hiệu quả và không dạy bạn gì về vấn đề cơ bản.
Thay vào đó, hãy coi gỡ lỗi như một thí nghiệm khoa học. Trước khi bạn chạm vào một dòng mã, hãy viết xuống giả thuyết của bạn. Bạn nghĩ điều gì đang gây ra lỗi? Bằng chứng gì hỗ trợ lý thuyết này? Điều gì sẽ bác bỏ nó? Tôi giữ một cuốn nhật ký gỡ lỗi—thực sự là một tập tin văn bản—trong đó tôi ghi lại mọi giả thuyết trước khi tôi thử nghiệm. Thực hành đơn giản này đã biến đổi tốc độ gỡ lỗi của tôi vì nó buộc tôi phải suy nghĩ trước khi hành động.
Dưới đây là quy trình của tôi: Đầu tiên, tôi tái tạo lỗi một cách đáng tin cậy. Nếu tôi không thể tái tạo nó một cách nhất quán, tôi chưa sẵn sàng để gỡ lỗi. Tôi cần hiểu các điều kiện chính xác dẫn đến sự thất bại. Thứ hai, tôi quan sát kỹ các triệu chứng. Thông điệp lỗi thực sự là gì? Hành vi mong đợi so với hành vi thực tế là gì? Thứ ba, tôi hình thành một giả thuyết về nguyên nhân gốc rễ. Đây không phải là một dự đoán ngẫu nhiên—đó là một lý thuyết có học dựa trên hiểu biết của tôi về hệ thống.
Ví dụ, tháng trước chúng tôi gặp một vấn đề mà các yêu cầu API bị timeout không cố định. Giả thuyết đầu tiên của tôi: hiệu suất truy vấn cơ sở dữ liệu bị suy giảm khi có tải. Bằng chứng hỗ trợ điều này: các timeout chỉ xảy ra trong giờ cao điểm. Bằng chứng phản bác: các số liệu cơ sở dữ liệu cho thấy thời gian truy vấn nhất quán. Tôi đã thử nghiệm giả thuyết này bằng cách thêm các ghi log thời gian chi tiết xung quanh các cuộc gọi cơ sở dữ liệu. Kết quả: các truy vấn cơ sở dữ liệu rất nhanh. Giả thuyết đã bị bác bỏ trong 15 phút. Giả thuyết tiếp theo: cạn kiệt pool kết nối. Cái này là đúng, và chúng tôi đã sửa nó bằng cách điều chỉnh cấu hình pool kết nối của mình.
Điểm chính trong đây là một giả thuyết bị bác bỏ không phải là thời gian lãng phí—nó là không gian khả năng đã bị loại bỏ. Mỗi giả thuyết không thành công thu hẹp tìm kiếm của bạn. Khi bạn chỉ thay đổi ngẫu nhiên mọi thứ, bạn không học được gì từ những thất bại của mình. Khi bạn đang thử nghiệm các giả thuyết, mỗi thất bại dạy bạn điều gì đó về hệ thống.
Thành Thạo Các Công Cụ Gỡ Lỗi (Không Chỉ Là Console.Log)
Tôi không nói với bạn rằng hãy ngừng sử dụng console.log—tôi cũng sử dụng nó. Nhưng nếu đó là công cụ gỡ lỗi duy nhất của bạn, bạn đang hoạt động với một tay bị trói sau lưng. Gỡ lỗi chuyên nghiệp đòi hỏi các công cụ chuyên nghiệp, và việc học chúng mang lại lợi ích cho toàn bộ sự nghiệp của bạn.
"Gỡ lỗi không chỉ là tìm kiếm lỗi—nó còn liên quan đến việc hiểu các hệ thống, hình thành giả thuyết và loại bỏ các khả năng với độ chính xác như phẫu thuật."
Đối với JavaScript và TypeScript, Chrome DevTools cực kỳ mạnh mẽ, nhưng hầu hết các lập trình viên chỉ sử dụng khoảng 10% tính năng của nó. Các điểm dừng điều kiện một mình đã giúp tôi tiết kiệm hàng trăm giờ. Thay vì thêm các câu lệnh console.log bên trong một vòng lặp chạy 10.000 lần, tôi đặt một điểm dừng điều kiện chỉ kích hoạt khi một điều kiện cụ thể được đáp ứng. Nhấp chuột phải vào bất kỳ số dòng nào, chọn "Thêm điểm dừng điều kiện" và nhập điều kiện của bạn. Trình gỡ lỗi chỉ tạm dừng khi điều kiện đó đúng.
Logpoints là một tính năng khác chưa được sử dụng nhiều. Chúng cho phép bạn chèn ghi log mà không làm thay đổi mã nguồn của bạn. Nhấp chuột phải vào số dòng, chọn "Thêm logpoint," và nhập thông điệp bạn muốn ghi. Tin nhắn xuất hiện trong console mà không cần thay đổi mã, biên dịch lại hoặc triển khai lại. Điều này đặc biệt giá trị khi gỡ lỗi các vấn đề sản xuất mà bạn không thể dễ dàng thay đổi mã.
Đối với gỡ lỗi phía backend, tôi phụ thuộc nhiều vào các trình gỡ lỗi tương tác. Trong Node.js, tôi sử dụng trình kiểm tra tích hợp với Chrome DevTools. Đối với Python, tôi sử dụng pdb hoặc ipdb. Đối với Go, tôi sử dụng Delve. Các công cụ này cho phép bạn tạm dừng thực hiện, kiểm tra biến, đi từng dòng mã và đánh giá các biểu thức trong ngữ cảnh hiện tại. Thời gian đầu tư để học các công cụ này có thể tốn từ 2-3 giờ. Thời gian tiết kiệm qua sự nghiệp được đo bằng tuần hoặc tháng.
Dưới đây là một ví dụ cụ thể: Tôi đã gỡ lỗi một rò rỉ bộ nhớ trong một dịch vụ Node.js. Sử dụng console.log gần như sẽ vô dụng—tôi cần hiểu được mô hình giữ đối tượng. Thay vào đó, tôi đã sử dụng tính năng chụp heap của Chrome DevTools. Tôi chụp một ảnh, thực hiện thao tác rò rỉ, chụp một ảnh khác và so sánh chúng. Chế độ xem so sánh cho tôi thấy chính xác những đối tượng nào đang được giữ lại và tại sao. Tôi đã xác định được rò rỉ—các người lắng nghe sự kiện không được dọn dẹp—trong khoảng 30 phút. Nếu không có công cụ phù hợp, điều này có thể đã mất hàng ngày.
Quy tắc của tôi: nếu bạn thêm hơn ba câu lệnh console.log để gỡ lỗi điều gì đó, bạn nên sử dụng một trình gỡ lỗi thích hợp hơn. Trình gỡ lỗi cung cấp cho bạn nhiều thông tin hơn, nhiều kiểm soát hơn và không cần phải thay đổi mã của bạn.
Tìm Bug Bằng Tìm Kiếm Nhị Phân
Khi bạn có một cơ sở mã lớn và bạn biết điều gì đó đã bị hỏng giữa phiên bản A và phiên bản B, tìm kiếm nhị phân là người bạn tốt nhất của bạn. Kỹ thuật này, được mượn từ các thuật toán khoa học máy tính, có thể giảm không gian tìm kiếm của bạn theo cấp số mũ.
| Cách Tiếp Cận Gỡ Lỗi | Thời Gian Đầu Tư | Giá Trị Học Tập | Tỷ Lệ Thành Công |
|---|---|---|---|
| Thay Đổi Mã Ngẫu Nhiên | 6+ giờ | Tối thiểu | 20-30% |
| Gỡ Lỗi Console.log | 3-4 giờ | Thấp | 40-50% |
| Các Công Cụ Gỡ Lỗi | 1-2 giờ | Trung bình | 60-70% |
| Gỡ Lỗi Dựa Trên Giả Thuyết | 20-45 phút | Cao | 80-90% |
| Khuôn Khổ Có Hệ Thống | 15-30 phút | Rất Cao | 85-95% |
Git bisect là công cụ gỡ lỗi mạnh mẽ nhất mà không ai sử dụng. Nó tự động hóa tìm kiếm nhị phân qua lịch sử commit của bạn để tìm ra commit chính xác đã giới thiệu một lỗi. Cách nó hoạt động như thế này: bạn nói cho Git biết commit nào được biết là tốt và commit nào được biết là xấu. Git sẽ kiểm tra một commit ở giữa chúng. Bạn kiểm tra xem lỗi có tồn tại không. Nếu có, commit đó trở thành commit "xấu" mới. Nếu không, nó trở thành commit "tốt" mới. Git lặp lại quá trình này, giảm một nửa không gian tìm kiếm mỗi lần, cho đến khi nó xác định commit chính xác đã giới thiệu lỗi.
Tôi đã sử dụng kỹ thuật này trong quý trước khi một lỗi hiển thị tinh vi xuất hiện trong bảng điều khiển của chúng tôi. Chúng tôi biết nó đã hoạt động hai tuần trước, nhưng chúng tôi đã hợp nhất 47 commit kể từ đó. Kiểm tra thủ công từng commit sẽ mất hàng giờ. Thay vào đó, tôi đã chạy git bisect, đánh dấu commit hiện tại là xấu, đánh dấu một commit từ hai tuần trước là tốt, và để Git thực hiện phép màu của nó. Sau khi kiểm tra chỉ 6 commit—log₂(47) làm tròn lên—Git đã xác định commit chính xác đã giới thiệu lỗi. Tổng thời gian: 18 phút.
Tìm kiếm nhị phân không chỉ dành cho lịch sử Git. Bạn có thể áp dụng cùng một nguyên tắc cho mã của bạn. Nếu một hàm có 200 dòng đang tạo ra đầu ra sai, hãy bình luận ra nửa sau và kiểm tra. Nếu lỗi vẫn tồn tại, nó nằm ở nửa đầu. Nếu nó biến mất, nó nằm ở nửa sau. Tiếp tục giảm một nửa cho đến khi bạn xác định được các dòng gặp vấn đề. Điều này nhanh hơn rất nhiều so với việc đọc qua mã từng dòng một.
Nguyên tắc tương tự cũng áp dụng cho cấu hình. Nếu ứng dụng của bạn hoạt động trong môi trường phát triển nhưng thất bại trong môi trường sản xuất, hãy bắt đầu bằng cách làm cho cấu hình sản xuất giống hệt như cấu hình phát triển. Sau đó lần lượt tái giới thiệu các cài đặt sản xuất từng cái một (hoặc theo nhóm, sử dụng tìm kiếm nhị phân) cho đến khi lỗi xuất hiện lại. Điều này nhanh chóng xác định sự khác biệt trong cấu hình nào đang gây ra vấn đề.
Tìm kiếm nhị phân hoạt động vì nó có tính logarit. Tìm kiếm qua 1.000 mục một cách tuyến tính mất tối đa 1.000 kiểm tra. Tìm kiếm nhị phân chỉ mất tối đa 10 kiểm tra. Không gian tìm kiếm càng lớn, thời gian tiết kiệm càng đáng kể. Tôi đã thấy các lập trình viên dành cả ngày để kiểm tra các khả năng mà tìm kiếm nhị phân có thể đã thu hẹp trong vài phút.
Tái Tạo Trước, Gỡ Lỗi Sau
Tôi có một quy tắc nghiêm ngặt: Tôi không bắt đầu gỡ lỗi cho đến khi tôi có thể tái tạo lỗi một cách đáng tin cậy. Điều này có thể có vẻ rõ ràng, nhưng tôi thường xuyên thấy các lập trình viên lao vào mã trước khi họ thực sự hiểu cách tr