Tôi, đối với một, chỉ thêm mã gỡ lỗi (chẳng hạn như báo cáo in) khi tôi đang cố gắng xác định vị trí lỗi. Và một khi tôi đã tìm thấy nó, tôi xóa mã gỡ lỗi (và thêm một trường hợp kiểm tra để kiểm tra cụ thể lỗi đó). Tôi cảm thấy rằng nó làm lộn xộn mã thực và do đó không có chỗ nào trừ khi tôi gỡ lỗi.
Bạn làm nó như thế nào? Bạn có để lại mã gỡ lỗi tại chỗ không, hoặc xóa nó khi lỗi thời (điều này có thể khó đánh giá khi đó)?
Câu trả lời:
Báo cáo in gỡ lỗi nên được đưa ra; tuy nhiên, nếu bạn cần thêm chúng để gỡ lỗi một vấn đề sản xuất thì có thể đáng cân nhắc nếu bạn có đủ thông tin được đưa vào khung đăng nhập của mình. Thông tin về các tham số, điều kiện lỗi và vv có thể hữu ích sau này khi lỗi tiếp theo xuất hiện. Sử dụng một khung ghi nhật ký tốt có thể được gỡ lỗi hoặc theo dõi các thông điệp nhật ký được bật một cách linh hoạt có thể rất hữu ích trong tự nhiên.
Mã được thêm vào để gỡ lỗi nên được gỡ bỏ khỏi phần mềm sản xuất.
Cho dù điều này là loại bỏ hoàn toàn hoặc được đưa vào các phần biên dịch có điều kiện (như trong C / C ++ / C #) là tùy thuộc vào bạn và tiêu chuẩn mã hóa của bạn.
Có một số lý do cho việc này:
Cả ChrisF và Alaric đều có điểm hợp lệ; +1 cho họ. Tôi có thể xác định ít nhất 5 loại mã gỡ lỗi khác nhau mà tôi sử dụng.
Sử dụng nhật ký để kết xuất trạng thái hệ thống tại một thời điểm cụ thể.
void function(...)
{
...dump everything i know about.
}
Sử dụng nhật ký cho các điểm kiểm tra thực hiện.
void function(...)
{
...got here 1
...got here 2
}
Mã thực sự buộc một điều kiện nhất định là đúng, nhưng phá vỡ hành vi bình thường. Thí dụ:
Ghi nhật ký xác minh - Tôi sẽ phân loại đây là ghi nhật ký chi tiết có thể được sử dụng để xác thực tính chính xác của phần mềm không được đưa vào sản xuất, ví dụ như xác thực các bước riêng lẻ của thuật toán.
Hoạt động đăng nhập - tham khảo bài viết của Alaric . Đó là khá nhiều những gì tôi có nghĩa là "hoạt động đăng nhập".
1, 2 và 3 nên được đưa ra hoàn toàn. Một cái gì đó giống như 4 Tôi có thể sẽ biên dịch có điều kiện ra khỏi mã. Trong 5, Alaric đã có một điểm tuyệt vời về khả năng tự động tắt các bản ghi. Điều đó có thể giải quyết quan điểm của ChrisF trong viên đạn thứ hai của anh ta trong hầu hết các trường hợp.
1)... với 1.... (sao cho Markdown định dạng chọn nó lên như một danh sách) và thụt mã ví dụ 8 chỗ (một lần nữa, để Markdown nhặt nó lên làm ví dụ mã trong một danh sách).
Nó phụ thuộc vào những gì mã đang làm. Một số mã được sử dụng để gỡ lỗi có thể được để nguyên như vậy và một số mã cần được loại bỏ.
Mã xác minh độ chính xác của các tham số trong một phương thức không phải lúc nào cũng hữu ích một khi mã hoạt động đúng, nhưng nó thường được giữ để đảm bảo rằng mã đang tiếp tục hoạt động đúng.
Đôi khi bạn viết mã khác nhau để dễ gỡ lỗi mã hơn, ví dụ tính toán một giá trị và đặt nó vào một biến cục bộ, sau đó sử dụng biến trong dòng tiếp theo, giúp dễ dàng kiểm tra kết quả tính toán khi bước đơn thông qua mã. Bạn có thể viết lại mã để sử dụng trực tiếp giá trị được tính toán, nhưng chi phí sử dụng biến cục bộ quá nhỏ (nếu có) mà có rất ít lý do để viết lại mã. Ngoài ra, có một điểm khiến mã không thay đổi một khi bạn đã kiểm tra nó, luôn có một rủi ro nhỏ là bạn đưa ra một lỗi khi thay đổi nó.
Mã mà bạn thêm chỉ để theo dõi một lỗi cụ thể thường có thể bị xóa sau khi bạn tìm thấy lỗi.
Ngày xưa tôi thường sử dụng rất nhiều mã gỡ lỗi. Tôi gần như hoàn toàn nhắm mục tiêu vào Windows, vì vậy có rất nhiều hàm đầu ra chuỗi gỡ lỗi này mà tôi không nhớ cách đánh vần nữa, vì vậy tôi có thể ghi lại dấu vết bằng một chương trình cụ thể.
Một số mã gỡ lỗi được giữ nguyên vị trí, những thứ cụ thể được dự định để cung cấp cho các cuộc gọi lồng nhau. Tuy nhiên, mặc dù điều chuỗi gỡ lỗi hầu như không thể nhìn thấy trên một hệ thống sản xuất, nhưng tất cả vẫn được thực hiện trong quá trình biên dịch có điều kiện.
Mặc dù vậy, thực tế là tất cả các mã gỡ lỗi đó là rất nhiều nỗ lực cho một thứ được xử lý lý tưởng theo một cách khác - tất nhiên, sử dụng một trình gỡ lỗi. Vào thời điểm đó, tôi không ấn tượng lắm với trình gỡ lỗi Borland C ++. Các công cụ có ở đó, nhưng chúng thường đưa ra kết quả sai lệch và sử dụng trình gỡ lỗi không phải IDE (thường là cần thiết) có nghĩa là ghi nhớ các phím tắt, có nghĩa là mất tập trung trong công việc.
Trải nghiệm gỡ lỗi duy nhất tôi thấy tệ hơn là GDB dòng lệnh.
Tất nhiên, trở thành một chuyên gia với các công cụ bạn sử dụng là điều quan trọng - nhưng việc gỡ lỗi thực sự không nên là việc bạn làm mỗi ngày. Nếu bạn sử dụng trình gỡ lỗi thường xuyên, bạn sẽ ổn khi học hàng tá lệnh và / hoặc phím tắt, điều đó có vẻ hơi cờ đỏ đối với tôi.
Tuy nhiên, khi tôi làm việc trong Visual Studio 7, rõ ràng việc gỡ lỗi có thể rất thiết thực và hiệu quả. Nếu bạn có thể thực hiện việc sửa lỗi của mình trong Visual Studio (bao gồm các phiên bản thể hiện), việc gỡ lỗi rất dễ dàng. Không có nghi ngờ gì nếu bạn có thể tìm thấy giao diện người dùng GUI / IDE phù hợp, GDB cũng dễ dàng và hiệu quả, mặc dù tôi chưa thực hiện tìm kiếm đó.
Ngoài ra còn có điều gì đó để nói về thử nghiệm đơn vị, với phân tích bảo hiểm bằng cách sử dụng gcov. Bạn càng tin tưởng vào hành vi của các thư viện của mình, thì việc gỡ lỗi của bạn càng ít sâu sắc - và bạn càng ít cần trình gỡ lỗi ở nơi đầu tiên. Và viết bài kiểm tra đơn vị là khá hợp lý một cái gì đó bạn nên làm hầu hết các ngày.
Công cụ quan trọng bất ngờ = cmake, một công cụ xây dựng cho phép tôi dễ dàng chuyển đổi giữa xây dựng cho GCC và cho VC ++, trong số những thứ khác. Vì vậy, tôi có thể thực hiện kiểm tra đơn vị của mình và bảo hiểm dựa trên gcov bằng GCC, nhưng dễ dàng chuyển sang VC ++ để sử dụng trình gỡ lỗi.
Tôi chấp nhận điều đó: Mã gỡ lỗi được sử dụng để tiêu diệt một lỗi trong mã được đề cập mà tôi thường loại bỏ hoàn toàn. Mã gỡ lỗi được sử dụng để tiêu diệt một lỗi phát sinh từ các lực lượng bên ngoài, tôi thường chỉ đơn giản là nhận xét.
Sử dụng TDD , vì vậy mã kiểm tra của bạn luôn có một nơi thậm chí được duy trì.