Là một đánh giá mã chỉ sử dụng nhận xét mã là một ý tưởng tốt?

Điều kiện tiên quyết

• Nhóm sử dụng DVCS
• IDE hỗ trợ phân tích ý kiến ​​(như TODO và v.v.)
• Các công cụ như CodeCollaborator rất tốn kém cho ngân sách
• Các công cụ như gerrit quá phức tạp để cài đặt hoặc không sử dụng được

Quy trình làm việc

• Tác giả xuất bản ở đâu đó trên nhánh tính năng repo trung tâm
• Người đánh giá lấy nó và bắt đầu đánh giá

• Trong trường hợp một số người xem xét câu hỏi / vấn đề tạo bình luận với nhãn đặc biệt, như "REV". Nhãn đó PHẢI không có trong mã sản xuất - chỉ trong giai đoạn xem xét:

  $somevar = 123;
  // REV Why do echo this here?
  echo $somevar;
  

• Khi người đánh giá kết thúc bài bình luận - nó chỉ cam kết với thông điệp "bình luận" ngu ngốc và đẩy lùi

• Tác giả kéo nhánh tính năng trở lại và trả lời các bình luận theo cách tương tự hoặc cải thiện mã và đẩy nó trở lại
• Khi bình luận "REV" biến mất, chúng tôi có thể nghĩ rằng đánh giá đó đã kết thúc thành công.
• Tác giả tương tác khởi động lại nhánh tính năng, xóa nó để xóa các cam kết "bình luận" đó và giờ đã sẵn sàng hợp nhất tính năng để phát triển hoặc thực hiện bất kỳ hành động nào có thể xảy ra sau khi đánh giá nội bộ thành công

Hỗ trợ IDE

Tôi biết rằng các thẻ nhận xét tùy chỉnh có thể có trong nhật thực & netbeans. Chắc chắn nó cũng nên trong gia đình blablaStorm.

Câu hỏi

1. Bạn có nghĩ rằng phương pháp này là khả thi?
2. Bạn có biết một cái gì đó tương tự?
3. Những gì có thể được cải thiện trong nó?

Ý tưởng thực sự rất hay. Trái với quy trình công việc thông thường, bạn giữ đánh giá trực tiếp bằng mã, vì vậy về mặt kỹ thuật, bạn không cần bất cứ điều gì ngoài trình soạn thảo văn bản để sử dụng quy trình công việc này. Sự hỗ trợ trong IDE cũng rất tốt, đặc biệt là khả năng hiển thị danh sách các đánh giá ở phía dưới.

Vẫn còn một vài nhược điểm:

• Nó hoạt động tốt cho các nhóm rất nhỏ, nhưng các đội lớn hơn sẽ yêu cầu theo dõi những gì đã được xem xét, khi nào, bởi ai và với kết quả nào. Mặc dù bạn thực sự có loại theo dõi này (kiểm soát phiên bản cho phép biết tất cả những điều đó), nhưng việc sử dụng và tìm kiếm cực kỳ khó khăn và thường sẽ yêu cầu tìm kiếm thủ công hoặc bán thủ công thông qua các phiên bản.

• Tôi không tin rằng người đánh giá có đủ phản hồi từ người đánh giá để biết các điểm đánh giá đã thực sự được áp dụng như thế nào .

  Hãy tưởng tượng tình huống sau đây. Alice đang xem xét lần đầu tiên mã của Eric. Cô nhận thấy rằng Eric, một nhà phát triển trẻ tuổi, đã sử dụng cú pháp không phải là mô tả nhất trong ngôn ngữ lập trình thực sự được sử dụng.

  Alice đề xuất một cú pháp thay thế và gửi lại mã cho Eric. Anh ta viết lại mã bằng cú pháp thay thế này mà anh ta tin là hiểu chính xác và xóa // BLAbình luận tương ứng .

  Tuần sau, cô nhận được mã cho lần đánh giá thứ hai. Liệu cô ấy có thể thực sự nhớ rằng cô ấy đã đưa ra nhận xét này trong lần đánh giá đầu tiên của mình, để xem Eric đã giải quyết nó như thế nào không?

  Trong một quy trình đánh giá chính thức hơn, Alice có thể thấy ngay rằng cô ấy đã nhận xét và xem sự khác biệt của mã liên quan, để nhận thấy rằng Eric đã hiểu sai cú pháp mà cô ấy nói với anh ta.

• Mọi người vẫn là người. Tôi khá chắc chắn rằng một số ý kiến ​​đó sẽ kết thúc bằng mã sản xuất và một số sẽ vẫn là rác trong khi đã hoàn toàn lỗi thời .

  Tất nhiên, cùng một vấn đề tồn tại với bất kỳ bình luận nào khác; ví dụ, có rất nhiều bình luận TODO trong sản xuất (bao gồm cả bình luận hữu ích nhất: "TODO: Nhận xét mã bên dưới.") và rất nhiều bình luận không được cập nhật khi có mã tương ứng.

  Ví dụ: tác giả ban đầu của mã hoặc người đánh giá có thể rời đi và nhà phát triển mới sẽ không hiểu đánh giá nói gì, vì vậy bình luận sẽ tồn tại mãi mãi, chờ đợi rằng ai đó sẽ quá can đảm để xóa sạch nó hoặc thực sự hiểu những gì nó nói rằng.

• Điều này không thay thế đánh giá trực tiếp (nhưng vấn đề tương tự cũng được áp dụng cho bất kỳ đánh giá chính thức nào khác không được thực hiện trực tiếp).

  Đặc biệt, nếu đánh giá ban đầu yêu cầu giải thích, người đánh giá và người đánh giá sẽ bắt đầu một cuộc thảo luận . Không chỉ bạn sẽ thấy mình có các bình luận BLA lớn, mà các cuộc thảo luận đó cũng sẽ làm ô nhiễm nhật ký của kiểm soát phiên bản .

• Bạn cũng có thể gặp phải các vấn đề nhỏ với cú pháp (cũng tồn tại đối với các nhận xét TODO). Ví dụ: nếu một bình luận "// BLA" dài xuất hiện trên một số dòng và ai đó quyết định viết nó theo cách này:

  // BLA This is a very long comment which is way beyond 80 characters, so it actually
  // fills more then one line. Since the next lines start with slashes, but not "BLA"
  // keyword, the IDE may not be able to show those lines, and display only the first one.
  

• Và cuối cùng là một lưu ý nhỏ và rất riêng tư: không chọn "BLA" làm từ khóa. Nghe có vẻ xấu xí. ;)

Tôi sẽ bổ sung các ý kiến ​​trong mã bằng một tài liệu đồng hành. Điều này sẽ tóm tắt những phát hiện và tiếp tục tồn tại sau khi các bình luận bị xóa. Những lợi thế của điều này sẽ là:

• nhỏ gọn. Nếu người đó thường xuyên không kiểm tra xem con trỏ được truyền vào không phải là null (hoặc một số lỗi người mới bắt đầu phổ biến khác trong ngôn ngữ bạn đang sử dụng), người đánh giá có thể để lại hàng tá nhận xét REV cho hiệu ứng đó và trong tài liệu có thể nói " Tôi đã tìm thấy 37 địa điểm mà con trỏ không được kiểm tra trước "mà không liệt kê tất cả
• nơi để ca ngợi. Một nhận xét giống như REV this is a nice designcó vẻ kỳ quặc, nhưng đánh giá mã của tôi thường bao gồm phê duyệt cũng như sửa chữa
• tính tương tác. Nhận xét mẫu của bạn là "tại sao bạn làm điều này?" và đó là một trong những rất điển hình. Một cách tiếp cận chỉ bình luận không hỗ trợ một cuộc trò chuyện. Người đó có thể thay đổi mã của họ và xóa bình luận, hoặc xóa bình luận. Nhưng "tại sao bạn làm điều này?" và "làm ơn thay đổi cái này, nó sai" không giống nhau.
• lưu giữ hồ sơ. Một người đánh giá sau này có thể kiểm tra xem mã đã thực sự thay đổi hay các bình luận đã bị xóa. Họ cũng có thể kiểm tra xem các bình luận đã được "đưa lên máy bay" và nhà phát triển không còn mắc lỗi tương tự trong lần đánh giá tiếp theo.

Tôi cũng sẽ sử dụng một mục công việc để thực hiện đánh giá và trả lời đánh giá, và liên kết các đăng ký với nó. Điều đó giúp bạn dễ dàng tìm thấy các bình luận trong một tập thay đổi cũ và để xem cách mỗi bình luận được xử lý trong một tập thay đổi khác.

Những người khác đã nói về những hạn chế của phương pháp này. Bạn đã đề cập rằng các công cụ như gerrit rất khó cài đặt - Tôi khuyên bạn nên xem qua photypeator (http://www.photypeator.com). Đây là hệ thống đánh giá mã mà Facebook đã sử dụng trong nhiều năm và gần đây đã được mở nguồn. Không khó để cài đặt, có quy trình công việc tuyệt vời và giải quyết tất cả các vấn đề được đề cập trong các bình luận khác.