Debug thường là phần ngốn thời gian nhất trong một ngày làm việc của lập trình viên .NET. Bên mình từng theo dõi một dev mất gần hai tiếng chỉ để tìm một lỗi null nằm sâu trong chuỗi gọi hàm. Sau buổi review hôm đó, cả nhóm thống nhất gom lại vài thủ thuật nhỏ, dùng đều tay mỗi ngày. Bài này chia sẻ những gì đội ngũ đã thử và thấy hiệu quả.
Breakpoint có điều kiện: đừng dừng ở mọi lần lặp
Một vòng lặp chạy 10.000 lần mà lỗi chỉ xảy ra ở phần tử thứ 4.237 thì việc bấm F5 từng lần là vô ích. Thay vào đó, bạn chuột phải vào breakpoint, chọn Conditions và nhập biểu thức, ví dụ item.Id == 4237.
Cách này hiệu quả vì Visual Studio chỉ tạm dừng khi điều kiện đúng. Bạn không phải chèn thêm if vào code rồi quên xoá sau khi sửa xong, điều mà chính đội ngũ mình từng mắc không ít lần.
Dùng Immediate Window để thử nhanh
Khi đang dừng ở breakpoint, cửa sổ Immediate cho phép gọi hàm, đọc property hoặc gán lại giá trị ngay lập tức. Ví dụ bạn nghi ngờ một chuỗi bị thừa khoảng trắng, chỉ cần gõ ?user.Email.Trim().Length để kiểm tra.
Thủ thuật này tiết kiệm nhiều hơn bạn nghĩ. Thay vì sửa code, build lại, chạy lại chỉ để in một biến, bạn có câu trả lời trong vài giây.
Watch và đặt tên biểu thức rõ ràng
Cửa sổ Watch không chỉ dành cho biến đơn. Bạn có thể thêm biểu thức LINQ như orders.Where(o => o.Status == "Pending").Count() để theo dõi số lượng theo thời gian thực. Khi tên biến khó đọc, hãy thêm alias bằng cách viết lại biểu thức ngắn hơn trong Watch.
Đội ngũ mình khuyên dev mới dùng Watch thay cho việc viết Console.WriteLine rải rác. Code sạch hơn, và bạn không cần nhớ xoá log sau khi xong.
Một ví dụ thực tế
Có một trường hợp bên mình gặp khi xử lý đơn hàng: NullReferenceException xuất hiện không đều. Dev đặt breakpoint có điều kiện order.Customer == null, sau đó dùng Immediate Window để xem order.CustomerId. Kết quả cho thấy dữ liệu cũ thiếu khoá ngoại. Cả quá trình mất chưa đến 15 phút, trong khi lần trước cùng lỗi đó mất gần nửa ngày.
Lưu ý khi debug ứng dụng ASP.NET
Với ASP.NET Core, hãy nhớ rằng nhiều lỗi nằm ở middleware hoặc dependency injection, không phải ở controller. Bạn nên đặt breakpoint ở pipeline và kiểm tra thứ tự đăng ký service trong Program.cs. Nếu nghi ngờ vòng đời của service, bạn có thể xem thêm bài Top 7 lưu ý về debug và tối ưu mã cho dev .NET để có checklist đầy đủ hơn.
Khi làm việc với truy vấn dữ liệu, nhiều lỗi hiệu năng lại bắt nguồn từ việc gọi database quá nhiều lần. Trong trường hợp đó, bạn nên đọc thêm Cache kết quả truy vấn: mẹo giảm tải database .NET để hiểu cách hạn chế các lượt gọi thừa.
Kết hợp thói quen để debug nhanh hơn
Các thủ thuật trên chỉ phát huy khi bạn dùng đều đặn. Đội ngũ mình khuyên bạn chọn ra hai thủ thuật, ví dụ breakpoint có điều kiện và Immediate Window, rồi dùng chúng trong một tuần trước khi thêm cái mới. Đừng cố nhớ hết cùng lúc.
Nếu bạn muốn đào sâu hơn về cách viết code dễ debug từ đầu, hãy tham khảo Top 7 kinh nghiệm thực tế về LINQ trong C# và .NET, vì LINQ viết gọn nhưng đôi khi khó theo dõi nếu không biết cách đặt điểm dừng hợp lý.
Tóm lại, thời gian debug giảm mạnh khi bạn biết dừng đúng chỗ và hỏi đúng câu hỏi với công cụ có sẵn. Hãy bắt đầu từ một thủ thuật hôm nay, và bạn sẽ thấy khác biệt rõ rệt sau vài ngày.
