Debugging Strategies: A Systematic Approach to Finding Bugs — txt1.ai

Ba giờ. Đó là thời gian tôi đã dành vào thứ Ba tuần trước để tìm kiếm một lỗi mà hóa ra chỉ là một dấu chấm phân cách sai vị trí trong một mã nguồn gồm 47.000 dòng. Là một kiến trúc sư phần mềm cao cấp với 14 năm kinh nghiệm gỡ lỗi mọi thứ từ các hệ thống nhúng đến các dịch vụ vi phân phối, tôi đã học được rằng sự khác biệt giữa một cơn ác mộng kéo dài ba giờ và một cách sửa chữa ba phút không phải là may mắn—đó là phương pháp. Tôi là Marcus Chen, và tôi đã gỡ lỗi các sự cố sản xuất vào lúc 3 giờ sáng nhiều hơn tôi muốn đếm, đã hướng dẫn hàng chục lập trình viên junior vượt qua những lỗi nghiêm trọng đầu tiên, và phát triển một cách tiếp cận có hệ thống đã giảm thời gian giải quyết lỗi trung bình của đội ngũ chúng tôi xuống 68% trong hai năm qua.

Sự thật là, hầu hết lập trình viên tiếp cận việc gỡ rối như thể họ đang tìm kiếm một cái kim trong đống rơm trong khi bị bịt mắt. Họ thay đổi các biến ngẫu nhiên, thêm các câu lệnh in mọi nơi, và hy vọng điều gì đó sẽ xảy ra. Nhưng gỡ rối không phải là về hy vọng—đó là về việc loại trừ có hệ thống, nhận diện mô hình, và hiểu hành vi cơ bản của các hệ thống của bạn. Tôi sẽ chia sẻ khung chính xác mà tôi sử dụng để gỡ rối các vấn đề phức tạp, các mô hình tư duy đã cứu tôi hàng giờ đồng hồ, và các kỹ thuật thực tiễn tách biệt những người gỡ rối hiệu quả với những người gặp khó khăn.

Tâm Lý Học Gỡ Rối: Tại Sao Não Bạn Chống Lại Bạn

Trước khi đi vào các kỹ thuật, chúng ta cần nói về trở ngại lớn nhất đối với việc gỡ rối hiệu quả: chính bộ não của bạn. Tôi đã chứng kiến những kỹ sư xuất sắc với bằng tiến sĩ trong ngành khoa học máy tính dành hàng giờ để truy đuổi các lỗi vì họ đã rơi vào những bẫy nhận thức mà tôi đã học để nhận ra từ sớm trong sự nghiệp của mình. Hiểu những cạm bẫy tâm lý này là bước đầu tiên để trở thành một người gỡ rối có hệ thống.

Bẫy nguy hiểm nhất là thiên vị xác nhận. Khi bạn có một lý thuyết về nguyên nhân gây ra lỗi, não bạn sẽ chủ động lọc thông tin để hỗ trợ lý thuyết đó. Tôi đã từng dành cả một buổi chiều thuyết phục rằng một điều kiện đua trong hàng đợi tin nhắn của chúng tôi đang gây ra các lỗi ngắt quãng, chỉ để phát hiện ra vấn đề thực sự là giá trị thời gian chờ được cấu hình sai trong một dịch vụ hoàn toàn khác. Tôi đã bỏ qua ba chỉ báo rõ ràng chỉ ra thời gian chờ vì chúng không khớp với mô hình tư duy của tôi. Các nghiên cứu trong nghiên cứu kỹ thuật phần mềm cho thấy lập trình viên dành khoảng 35-50% thời gian gỡ rối của họ theo đuổi các giả thuyết không chính xác, và thiên vị xác nhận là thủ phạm chính.

Một bẫy nhận thức khác là ảo tưởng chi phí chìm. Sau khi đầu tư hai giờ để gỡ lỗi dựa trên một giả thuyết, việc từ bỏ cách tiếp cận đó và bắt đầu lại trở nên khó khăn về mặt tâm lý. Tôi đã phát triển một quy tắc cá nhân: nếu tôi không tiến bộ đáng kể trong 45 phút, tôi sẽ tạm rời khỏi, lấy cà phê, và quay lại với một tâm trạng hoàn toàn mới. Thực hành đơn giản này có thể đã giúp tôi tiết kiệm hàng trăm giờ trong sự nghiệp của mình.

Bẫy thứ ba là cái mà tôi gọi là "chủ nghĩa phức tạp"—giả định rằng những vấn đề phức tạp phải có nguyên nhân phức tạp. Thực tế, tôi đã thấy rằng khoảng 70% lỗi trong các hệ thống sản xuất có nguyên nhân gốc đơn giản đến xấu hổ: lỗi chính tả, lỗi lệch một, giả định sai về hành vi API, hoặc lỗi cấu hình. Lỗi đã khiến tôi tốn ba giờ vào thứ Ba tuần trước? Một dấu chấm phân cách thay vì dấu phẩy trong một tệp cấu hình JSON. Hệ thống đã phân tích nó như cú pháp hợp lệ nhưng diễn giải hoàn toàn sai.

Để chống lại những thiên lệch này, tôi đã tập luyện để tiếp cận mọi lỗi với cái mà các nhà Phật giáo Zen gọi là "tâm trí người mới"—giả định rằng tôi không biết gì và để cho chứng cứ dẫn đường cho tôi. Chỉ việc thay đổi tư duy này đã giúp tôi ít nhất gấp đôi hiệu quả trong việc gỡ rối so với những ngày đầu của sự nghiệp khi tôi nghĩ rằng mình có thể trực giác tìm ra giải pháp dựa vào kinh nghiệm mà thôi.

Phương Pháp Khoa Học Ứng Dụng Vào Mã

Khung gỡ rối hiệu quả nhất mà tôi tìm thấy đơn giản là phương pháp khoa học được áp dụng một cách nghiêm ngặt vào phần mềm. Đây không phải là phép ẩn dụ—tôi thực sự tuân theo cùng một quy trình mà tôi đã học trong lớp khoa học cấp ba, và nó hoạt động một cách đáng ngạc nhiên để tìm ra lỗi trong các hệ thống phức tạp.

Gỡ rối không phải là về hy vọng—đó là về việc loại trừ có hệ thống, nhận diện mô hình, và hiểu hành vi cơ bản của các hệ thống của bạn.

Bước đầu tiên là quan sát. Trước khi chạm vào bất kỳ đoạn mã nào, tôi dành thời gian để tài liệu một cách cẩn thận những gì đang xảy ra. Triệu chứng là gì? Khi nào chúng bắt đầu? Điều gì thay đổi gần đây? Tôi duy trì một cuốn nhật ký gỡ rối nơi tôi ghi lại mọi quan sát, bất kể nó có vẻ tầm thường đến đâu. Đối với lỗi dấu chấm phân cách, nhật ký của tôi có các mục như "lỗi chỉ xảy ra trong môi trường sản xuất," "bắt đầu sau khi triển khai lúc 14:23 UTC," "ảnh hưởng đến khoảng 12% yêu cầu," và "thông báo lỗi đề cập đến 'kí tự không mong muốn'." Những quan sát này đã trở thành những manh mối quan trọng.

Bước hai là hình thành một giả thuyết. Dựa trên những quan sát của tôi, tôi tạo ra một lý thuyết có thể kiểm tra về nguyên nhân gây ra lỗi. Từ khóa chính ở đây là "có thể kiểm tra"—các lý thuyết mơ hồ như "có điều gì đó không đúng với cơ sở dữ liệu" không hữu ích. Một giả thuyết tốt là cụ thể: "Hồ bơi kết nối cơ sở dữ liệu đang bị cạn kiệt dưới tải vì giá trị thời gian chờ quá thấp." Tôi thường tạo ra ba đến năm giả thuyết cạnh tranh và xếp hạng chúng theo tính khả thi dựa trên chứng cứ.

Bước ba là thiết kế một thí nghiệm để kiểm tra giả thuyết. Đây là nơi mà nhiều lập trình viên sai lầm—họ nhảy thẳng vào việc thay đổi mã mà không nghĩ qua cách họ sẽ biết liệu sự thay đổi của họ thực sự đã sửa chữa vấn đề hay chưa. Đối với mỗi giả thuyết, tôi thiết kế một bài kiểm tra cụ thể sẽ xác nhận hoặc bác bỏ nó. Nếu tôi nghĩ đó là vấn đề của hồ bơi kết nối, tôi có thể giám sát các chỉ số hồ bơi dưới tải, hoặc tạm thời tăng kích thước hồ bơi và quan sát kết quả.

Bước bốn là tiến hành thí nghiệm và thu thập dữ liệu. Tôi thực hiện một thay đổi một lần—không bao giờ nhiều thay đổi cùng một lúc—và cẩn thận quan sát kết quả. Tôi đã thấy các lập trình viên thực hiện ba thay đổi cùng một lúc, thấy lỗi biến mất, và rồi không có ý tưởng nào về thay đổi nào thực sự đã sửa chữa nó. Đó không phải là gỡ rối; đó là đánh bạc.

Bước năm là phân tích kết quả và lặp lại. Nếu giả thuyết được xác nhận, tốt—tôi đã tìm thấy lỗi. Nếu không, tôi công nhận giả thuyết đó là sai, tài liệu lý do tại sao nó sai, và chuyển sang giả thuyết tiếp theo. Việc loại trừ có hệ thống này cực kỳ mạnh mẽ. Ngay cả khi tôi sai, tôi vẫn đang tiến bộ bằng cách thu hẹp không gian tìm kiếm.

Tôi đã sử dụng khung này để gỡ rối từ các lỗi rò rỉ bộ nhớ trong các ứng dụng C++ đến các vấn đề thời gian tinh tế trong các hệ thống phân phối. Nó hoạt động bởi vì nó buộc bạn phải có phương pháp và dựa trên chứng cứ thay vì tin tưởng vào trực giác hoặc đoán mò. Theo kinh nghiệm của tôi, các lập trình viên áp dụng cách tiếp cận khoa học này giảm thời gian gỡ rối của họ xuống 40-60% chỉ trong vài tháng thực hành.

Xây Dựng Một Trường Hợp Kiểm Tra Có Thể Tái Sản Xuất: Nền Tảng Của Gỡ Rối Hiệu Quả

Nếu tôi chỉ có thể đưa ra một lời khuyên về gỡ rối, đó sẽ là: đầu tư mạnh mẽ vào việc tạo ra một trường hợp kiểm tra tối thiểu, có thể tái sản xuất trước khi bạn làm bất kỳ điều gì khác. Tôi đã thấy các lập trình viên lãng phí cả ngày cố gắng gỡ rối vấn đề trong môi trường sản xuất khi họ có thể đã giải quyết vấn đề trong vòng một giờ với một trường hợp tái sản xuất hợp lý. Đây là kỹ năng quan trọng nhất mà tôi dạy cho các lập trình viên junior trong đội ngũ của mình.

Một trường hợp kiểm tra có thể tái sản xuất là một phiên bản đơn giản hóa của hệ thống của bạn mà nhất quán cho thấy lỗi. Những đặc điểm chính là: nó tối thiểu (chỉ chứa mã cần thiết để kích hoạt lỗi), nó được tách biệt (không phụ thuộc vào dịch vụ hoặc trạng thái bên ngoài khi có thể), và nó nhất quán (sản xuất cùng một kết quả mỗi khi bạn chạy nó). Việc tạo ra điều này đòi hỏi kỷ luật vì nó yêu cầu loại bỏ độ phức tạp, nhưng lợi ích thu được là rất lớn.

Đây là quy trình của tôi để xây dựng một trường hợp tái sản xuất. Đầu tiên, tôi bắt đầu với hệ thống đầy đủ nơi xảy ra lỗi và bắt đầu loại bỏ các thành phần một cách lần lượt. Liệu tôi có thể tái sản xuất nó mà không cần cơ sở dữ liệu không? Không cần hàng đợi tin nhắn? Không cần lớp xác thực? Mỗi thành phần mà tôi loại bỏ thành công đơn giản hóa quá trình...