Có tốt để giữ bình luận sửa lỗi trong mã không?

Nhóm của tôi đang sử dụng trường hợp rõ ràng làm điều khiển phiên bản. Dự án mà tôi đang làm việc không bắt đầu từ 7-8 năm trước. Trong toàn bộ thời gian thực hiện dự án, chúng tôi đã phát hành một số gói dịch vụ sửa lỗi, vv Các vấn đề được theo dõi bằng hệ thống theo dõi lỗi và hầu hết những người làm việc với các bản sửa lỗi đều tuân theo thói quen kèm theo nhận xét trong START / Khối END với ngày, tác giả, id-id, v.v.

Tôi cảm thấy điều này khá không liên quan và làm cho mã trở nên lộn xộn và không thoải mái để duy trì và đây là những điều phải là một phần của nhận xét / nhãn đăng ký, v.v., nơi chúng tôi có thể giữ thêm thông tin vòng đời của sản phẩm công việc.

Thực hành tốt nhất để làm theo là gì?

Một số người đánh giá mã đã nhấn mạnh vào các bình luận về lỗi và sửa lỗi để giảm bớt cuộc sống của họ. Theo hiểu biết của tôi, họ phải xem lại các tệp bằng cách ánh xạ nó tới dạng xem và lấy nhật ký thay đổi của chi nhánh và xem xét nó. Sẽ rất hữu ích nếu tôi có thể nhận được một số thực tiễn tốt nhất về việc gửi mã cập nhật để xem xét.

Vấn đề với việc thêm lỗi dưới dạng nhận xét vào mã là, bạn không có được câu chuyện đầy đủ. Nếu tôi thấy một đoạn mã hoàn toàn tốt được gắn thẻ "đây là bản sửa lỗi cho lỗi blah ", phản ứng đầu tiên của tôi sẽ là nói "vậy thì sao?". Mã ở đó, nó hoạt động. Điều duy nhất tôi cần biết để duy trì mã là một bình luận cho tôi biết nó làm gì.

Một cách thực hành tốt hơn là thêm các tham chiếu sửa lỗi trong nhật ký cam kết SCM. Bằng cách đó, bạn sẽ thấy lỗi là gì, nơi nó được giới thiệu và cách khắc phục. Ngoài ra, khi đến thời điểm phát hành, bạn chỉ cần trích xuất nhật ký SCM và thêm một dấu đầu dòng cho biết có lỗi và đã được sửa. Nếu một chi nhánh hoặc phiên bản khác giới thiệu cùng một lỗi, bạn có thể dễ dàng xác định vị trí sửa lỗi và áp dụng lại nếu đó thực sự là điều tương tự.

Nói xong, tôi cũng đồng ý với câu trả lời của Charles. Nếu lý do cho một đoạn mã không rõ ràng, bằng mọi cách, hãy nói với người bảo trì rằng mã ở đó vì một lý do và nên được xử lý cẩn thận.

Chủ yếu là thực hành xấu. Tôi sẽ không nói nó không bao giờ nên được thực hiện. Đôi khi bạn gặp phải một cái gì đó giống như lỗi trong API bên ngoài mà bạn phải xử lý. Công việc xung quanh có thể trông hoàn toàn chết não nếu bạn không biết về lỗi tiềm ẩn. Trong trường hợp đó, có thể là một ý tưởng tốt để ghi lại lỗi trong mã để đồng nghiệp hoặc bản thân bạn sau này không cố gắng "sửa" mã chết não rõ ràng.

Thực hành xấu. Nhận xét sẽ hết hạn và làm lộn xộn mã. Thông tin vẫn có sẵn trong lịch sử phiên bản của hệ thống SCC của bạn nếu cần.

Âm thanh như một thực hành xấu. Điều gì xảy ra nếu tổ chức của bạn quyết định chuyển sang hệ thống theo dõi lỗi khác? Đừng buộc sản phẩm của bạn quá chặt với các công cụ bạn hiện đang sử dụng. Thay vì tham khảo ID lỗi cụ thể và lý do tại sao mã trông không rõ ràng, hãy thúc đẩy quyết định thiết kế của bạn bằng các nhận xét trong mã.

Phản ứng đầu tiên của tôi là không lặp lại chính mình để lấy nó ra khỏi mã và vào nhật ký SCM. Chúng tôi đã có một cuộc thảo luận tương tự ở đây về nhận xét sửa đổi cho các chức năng, tên tác giả và ngày tạo cho các tệp và chức năng. Trước đây (trước khi SCM được sử dụng), tất cả thông tin này được lưu trong các tệp để có thể tái tạo lại quá trình phát triển của tệp.

Khoảng một nửa số nhà phát triển muốn thông tin này có thể có tất cả thông tin ở một nơi (điều này kích hoạt họ tìm kiếm các thay đổi trong SCM). Nửa còn lại của các nhà phát triển không bắt đầu tìm kiếm manh mối về những gì đã thay đổi trong coe, nhưng từ SCM để họ không cần thông tin trong mã. Chúng tôi vẫn chưa đưa ra quyết định phải làm gì với những bình luận đó. Nó phụ thuộc rất nhiều vào cách mọi người làm việc và một số người rất bướng bỉnh trong việc rời bỏ các phương pháp đã biết của họ. Điều tương tự về nhận xét khối mã và để chúng trong mã mãi mãi.

Chỉ để thêm vào những gì Dyaster et al. đã nói, mặc dù JIRA có các khả năng thực sự tốt để hiển thị các thay đổi liên quan đến lỗi, nhưng nơi tốt nhất tuyệt đối để ghi lại lỗi là trong trường hợp thử nghiệm. Nếu mã không rõ ràng mà không có nhận xét cho biết lỗi nào đã được sửa, đó là "mùi mã". Điều đó nói rằng, nếu bạn không có thời gian để làm sạch mùi, bình luận nên tham khảo trường hợp thử nghiệm, nơi rõ ràng hơn nhiều tại sao mã đang làm những gì nó đang làm. Nếu bạn không có thời gian để viết một trường hợp thử nghiệm giải thích về sửa lỗi, thì lỗi vẫn chưa thực sự được sửa, nó đã bị hoãn lại.

Tôi đồng ý với việc thêm id idfix trong thông điệp cam kết, và không phải trong chính mã. Trình theo dõi lỗi tự động quét các thông báo cam kết cho id lỗi rất hữu ích.

Ngoài ra, bạn có thể sử dụng lệnh đổ lỗi / chú thích / khen ngợi của hệ thống kiểm soát phiên bản của mình để giúp thay thế các nhận xét này. Sau đó, khi bạn chạy một cái gì đó như:

vcs blame file.ext

bạn có thể thấy thông tin hữu ích, thường bao gồm cả những người đã thay đổi từng dòng, khi họ thay đổi nó và id xác nhận. Từ id xác nhận, bạn có thể nhận được thông báo đầy đủ, bao gồm id lỗi.

Các hệ thống VCS tốt sẽ cho phép bạn bỏ qua khoảng trắng khi tính toán ai đã sửa đổi một dòng.

Tôi không biết Clear Case có gì cho tính năng này.