Đánh giá ngang hàng / thất vọng

Tôi sẽ không gọi mình là một siêu sao, nhưng là một người tương đối có kinh nghiệm. Tôi cố gắng giữ chất lượng mã ở mức cao và luôn tìm cách cải thiện phong cách mã hóa của mình, cố gắng làm cho mã hiệu quả, dễ đọc và nhất quán cũng như khuyến khích nhóm làm theo mô hình & phương pháp để đảm bảo tính nhất quán. Tôi cũng hiểu sự cần thiết của sự cân bằng giữa cả chất lượng và tốc độ.

Để đạt được điều này, tôi đã giới thiệu cho nhóm của mình khái niệm về đánh giá ngang hàng. Hai ngón tay cái lên trong github pull-request để hợp nhất. Tuyệt vời - nhưng không phải theo ý kiến ​​của tôi mà không có tiếng nấc.

Tôi thường thấy các bình luận đánh giá ngang hàng từ các đồng nghiệp giống như -

• Sẽ là tốt để thêm một không gian sau <INSERT SOMETHING HERE>
• Dòng bổ sung không mong muốn giữa các phương thức
• Dừng hoàn toàn nên được sử dụng ở cuối các bình luận trong docblocks.

Bây giờ theo quan điểm của tôi - người đánh giá nhìn bề ngoài về tính thẩm mỹ của mã - và không thực sự thực hiện đánh giá mã. Đánh giá mã mỹ phẩm đến với tôi như tâm lý kiêu ngạo / tinh hoa. Nó thiếu chất, nhưng bạn thực sự không thể tranh luận quá nhiều với nó bởi vì người đánh giá là đúng về mặt kỹ thuật . Tôi muốn nhìn thấy ít hơn các loại đánh giá ở trên, và nhiều đánh giá như sau:

• Bạn có thể giảm độ phức tạp theo chu kỳ bằng cách ...
• Thoát sớm và tránh nếu / khác
• Tóm tắt truy vấn DB của bạn vào một kho lưu trữ
• Logic này không thực sự thuộc về nơi này
• Đừng lặp lại chính mình - trừu tượng và tái sử dụng
• Điều gì sẽ xảy ra nếu Xđược thông qua như là một đối số cho phương thức Y?
• Đâu là bài kiểm tra đơn vị cho việc này?

Tôi thấy rằng luôn luôn có cùng loại người đưa ra các loại đánh giá mỹ phẩm, và cùng loại người mà theo tôi đưa ra đánh giá ngang hàng "Chất lượng & Logic".

Điều gì (nếu có) là cách tiếp cận chính xác để đánh giá ngang hàng. Và tôi có đúng không khi thất vọng với cùng một người về cơ bản lướt qua mã tìm lỗi chính tả & lỗi thẩm mỹ hơn là lỗi mã thực tế?

Nếu tôi đúng - làm thế nào tôi có thể khuyến khích các đồng nghiệp thực sự tìm kiếm các lỗi trong mã một cách cân bằng với gợi ý chạm vào mỹ phẩm?

Nếu tôi không chính xác - xin hãy khai sáng cho tôi. Có bất kỳ quy tắc nào cho những gì thực sự cấu thành một đánh giá mã tốt không? Tôi đã bỏ lỡ quan điểm của các đánh giá mã là gì?

Từ quan điểm của tôi - xem xét mã là về trách nhiệm chung cho mã. Tôi sẽ không cảm thấy thoải mái khi đưa ngón tay cái lên mã mà không giải quyết / kiểm tra logic, khả năng đọc và chức năng. Tôi cũng sẽ không bận tâm đến việc hợp nhất một đoạn mã vững chắc nếu tôi nhận thấy ai đó đã bỏ qua một điểm dừng hoàn toàn trong khối tài liệu.

Khi tôi xem lại mã, tôi có thể chi tiêu trong khoảng 15-45 phút trên 500 Loc. Tôi không thể tưởng tượng những đánh giá nông cạn này mất hơn 10 phút bao giờ nếu đó là độ sâu của đánh giá mà họ đang thực hiện. Hơn nữa, bao nhiêu giá trị là ngón tay cái từ người đánh giá nông? Chắc chắn điều này có nghĩa là tất cả các ngón tay cái không có trọng lượng bằng nhau và có thể cần phải có quá trình xem xét 2 lần. Một ngón tay cái để đánh giá sâu và ngón tay cái thứ 2 cho "đánh bóng"?

Các loại đánh giá

Không có một cách thực sự để đánh giá ngang hàng. Có nhiều cách để đánh giá xem mã có đủ chất lượng cao hay không. Rõ ràng có một câu hỏi là liệu nó có lỗi hay không, hay liệu nó có giải pháp nào không mở rộng được hay không. Các vấn đề về sự phù hợp với các tiêu chuẩn và hướng dẫn địa phương, trong khi có lẽ không quan trọng như một số vấn đề khác, cũng là một phần của những gì đóng góp cho mã chất lượng cao.

Các loại người đánh giá

Giống như chúng ta có các tiêu chí khác nhau để đánh giá phần mềm, những người thực hiện đánh giá cũng khác nhau. Tất cả chúng ta đều có những kỹ năng và cơ duyên riêng. Một số người có thể nghĩ rằng việc tuân thủ các tiêu chuẩn địa phương là rất quan trọng, giống như những người khác có thể quan tâm hơn đến việc sử dụng bộ nhớ hoặc bảo hiểm mã của các bài kiểm tra của bạn, v.v. Bạn muốn tất cả các loại đánh giá này, bởi vì nói chung chúng sẽ giúp bạn viết mã tốt hơn.

Một đánh giá ngang hàng là sự hợp tác, không phải là một trò chơi thẻ

Tôi không chắc bạn có quyền nói với họ cách thực hiện công việc của họ. Trừ khi bạn biết khác một cách chắc chắn, giả sử rằng người này đang cố gắng đóng góp theo cách mà người đó thấy phù hợp. Tuy nhiên, nếu bạn thấy có chỗ để cải thiện hoặc nghi ngờ có thể họ không hiểu những gì được mong đợi trong đánh giá ngang hàng, hãy nói chuyện với họ .

Quan điểm của một đánh giá ngang hàng là liên quan đến các đồng nghiệp của bạn . Sự tham gia không ném mã lên tường và chờ phản hồi được ném lại. Sự tham gia đang làm việc cùng nhau để tạo ra mã tốt hơn. Tham gia vào một cuộc trò chuyện với họ.

Lời khuyên

Đến cuối câu hỏi bạn đã viết:

Làm thế nào tôi có thể khuyến khích các đồng nghiệp thực sự tìm kiếm các lỗi trong mã một cách cân bằng với các lỗi thẩm mỹ rõ ràng?

Một lần nữa, câu trả lời là giao tiếp. Có lẽ bạn có thể hỏi họ "này, tôi đánh giá cao việc bạn mắc phải những sai lầm này. Nó sẽ giúp tôi rất nhiều nếu bạn cũng có thể tập trung vào một số vấn đề sâu hơn như liệu tôi có cấu trúc mã của mình đúng không. Tôi biết nó cần thời gian, nhưng nó thực sự sẽ Cứu giúp."

Trên một ghi chú thực tế hơn, cá nhân tôi chia các nhận xét đánh giá mã thành hai phe và cụm từ chúng một cách thích hợp: những thứ phải được sửa chữa, và những thứ có tính thẩm mỹ hơn. Tôi sẽ không bao giờ ngăn chặn mã rắn, mã làm việc được kiểm tra nếu có quá nhiều dòng trống ở cuối tệp. Tuy nhiên, tôi sẽ chỉ ra điều đó, nhưng tôi sẽ làm như vậy với một cái gì đó như "hướng dẫn của chúng tôi nói rằng có một dòng trống duy nhất ở cuối và bạn có 20. Nó không phải là một điểm dừng hiển thị, nhưng nếu bạn có cơ hội thì bạn có thể muốn sửa nó ".

Đây là một cái gì đó khác để xem xét: nó có thể là một tiểu thú cưng của bạn mà họ thực hiện đánh giá nông cạn về mã của bạn. Rất có thể một người thú cưng của họ là bạn (hoặc một số đồng đội khác nhận được đánh giá tương tự) rất cẩu thả đối với các tiêu chuẩn mã hóa của tổ chức của bạn và đây là cách họ đã chọn để giao tiếp với bạn.

Làm gì sau khi xem xét

Và cuối cùng, một lời khuyên sau khi xem xét: Khi cam kết mã sau khi xem xét, bạn có thể muốn xem xét việc chăm sóc tất cả những thứ mỹ phẩm trong một cam kết và thay đổi chức năng trong một cam kết khác. Trộn lẫn cả hai có thể làm cho khó phân biệt những thay đổi đáng kể từ những thay đổi không đáng kể. Thực hiện tất cả các thay đổi mỹ phẩm và sau đó cam kết với một thông điệp như "mỹ phẩm; không thay đổi chức năng".

Mọi người nhận xét về định dạng mã và lỗi chính tả vì chúng dễ phát hiện và không đòi hỏi nhiều nỗ lực từ chúng.

Phần này rất dễ sửa - hầu như bất kỳ ngôn ngữ nào cũng có công cụ kiểm tra kiểu hoặc kẻ nói dối. Plugin nó trong quá trình xây dựng của bạn, do đó nó sẽ thất bại trong quá trình xây dựng nếu có một không gian dư thừa. Kết quả là sẽ không có vấn đề phong cách để bình luận.

Bắt họ tìm ra những vấn đề thực sự có thể là một thách thức khá lớn. Điều này không chỉ đòi hỏi một tư duy đặc biệt tò mò và định hướng chi tiết, mà còn là một động lực đáng kể.

Và động lực này đến từ kinh nghiệm. Kinh nghiệm cố gắng làm việc với mã crappy được viết bởi các nhà phát triển trước đó. Kỹ sư cao cấp có rất nhiều điều đó. Bơi trong đại dương cứt cho bạn một khát khao không được đến đó một lần nữa.

Nếu tôi cần chọn một điều chính để kiểm tra trong quá trình xem xét mã, đó sẽ là khả năng duy trì mã. Tại mọi thời điểm, nhà phát triển xem xét mã này nên hiểu nó và sẵn sàng nâng cao và sửa đổi nó. Nếu anh ta không có manh mối về những gì đang diễn ra ở đây, anh ta cần phải nói ngay lập tức và mã cần phải được viết lại.

Đây là câu trả lời thiết thực:

Kịch bản 1 : Bạn là thành viên cấp cao và là người có thể quyết định thực hành

Gọi một cuộc họp và đưa ra các quy tắc và hướng dẫn Đánh giá mã. Tin tôi đi, hướng dẫn rõ ràng hoạt động tốt hơn bất kỳ hệ thống hoặc đào tạo 'danh dự' nào. Làm rõ rằng các vấn đề định dạng mã không phải được nêu ra ở tất cả. Một số thành viên sẽ phản đối. Lắng nghe họ và sau đó yêu cầu họ làm theo hướng dẫn trong vài tháng đầu như một thử nghiệm. Thể hiện sự sẵn sàng thay đổi nếu các hướng dẫn hiện tại không hoạt động.

Kịch bản 2 : Bạn không phải là người quyết định thực hành hoặc bạn là thành viên tương đối nhỏ trong đội

Đặt cược tốt nhất của bạn là chỉ giải quyết các vấn đề xem xét mã cho đến khi bạn đạt được kịch bản 1 .

Câu trả lời đơn giản để ngăn chặn các bình luận đánh giá mã "tầm thường" là nhấn mạnh (vì mục đích hiệu quả) rằng người đánh giá nên là người sửa chúng. Vì vậy, nếu người đánh giá thấy rằng bạn (kinh dị!) Đã bỏ lỡ toàn bộ hoặc đánh vần sai một bình luận, họ chỉ nên sửa nó và tiếp tục.

Theo kinh nghiệm của tôi, điều này có nghĩa là:

• người đánh giá của bạn ngừng thực hiện những nhận xét đánh giá tương đối vô nghĩa này và chuyển chúng trở lại để được sửa chữa.
• chỉ những người đánh giá OCD nhất mới sửa chúng, nghĩa là hầu hết các đánh giá của bạn sẽ vượt qua. điều này có tác dụng kích thích việc yêu cầu các nhà phát triển thực hiện các đánh giá thực tế hơn, những người báo cáo những điều lặt vặt vì họ không thực sự xem xét mã sẽ kết thúc bằng việc tại sao tất cả các đánh giá của họ vượt qua mà không có nhận xét.

Dù bằng cách nào, đây là một lợi ích. Chi phí cho một đánh giá thất bại là rất cao trong việc khiến nhà phát triển dừng những gì anh ta đang làm và xem lại mã của mình và đánh giá tiếp theo sau đó. Nếu một đánh giá tìm thấy chất lượng mã thực sự hoặc các vấn đề kiến ​​trúc thì chi phí này đáng giá từng xu, nhưng trả chi phí này cho những chuyện vặt vãnh thì không.

Xem lại quá trình đánh giá

Ngoài các đánh giá mã, tôi cũng đề nghị xem xét lại Quy trình đánh giá một cách thường xuyên. Chắc chắn có rất nhiều người có thể học ở đây, ví dụ như làm thế nào để đưa ra các đánh giá mã phù hợp.

Thông thường, một số người đi xe đạp chỉ thiếu kinh nghiệm và không biết phải tìm gì. Họ cần một chút hướng dẫn không chỉ liên quan đến mã của họ, mà còn cả những người đánh giá mã hữu ích. Cung cấp phản hồi về các đánh giá sẽ dẫn đến một quá trình học tập mà (hopefull) dẫn đến các đánh giá tốt hơn và mã tốt hơn.

Tiếp theo, có thể là một ý tưởng tốt để (chính thức) chính thức hóa một tập hợp các giá trị và tiêu chí, những gì tổ chức hoặc nhóm nhận thấy là Good Code ™ và những gì nên tránh các mô hình chống. Đây không phải là về thiết lập sth. cụ thể, nhưng về việc có được sự đồng thuận chung về chất lượng mã ngay từ đầu .

Là một người ở cả hai phía của điều này (xem lại mã được viết bởi người khác, cũng như có mã tôi đã viết đã xem xét), tôi nói rằng tôi có ba loại phản hồi rơi vào. Chà, bốn, cũng có trường hợp thú vị của "tất cả đều ổn".

"Sẽ rất tuyệt, nhưng nó sẽ không chặn bạn" (nếu tất cả các phản hồi thuộc danh mục này, tôi có thể gửi yêu cầu hợp nhất với "sẽ hợp nhất tại XX: XX, trừ khi bạn nói với tôi rằng bạn muốn sửa chúng" hoặc "chắc chắn, hãy tiếp tục kiểm tra, bất kỳ khối nào hệ thống sẽ ném đã bị vô hiệu hóa"):

• Quên các điểm dừng đầy đủ ở cuối câu (trong chuỗi doc hoặc bình luận). Ngữ pháp vụng về trong bất cứ điều gì không được phát ra cho người dùng dưới bất kỳ hình thức hoặc hình thức nào (một lần nữa, chuỗi doc và nhận xét)
• Mã có cách thanh lịch hơn, nhưng những gì có thể hiểu và thành ngữ (có lẽ tôi thậm chí sẽ đưa đề xuất của mình vào, vì vậy thật dễ dàng để lại hoặc sửa chữa)

"Những thứ cần được sửa chữa, nhưng tôi sẽ tin tưởng bạn làm điều đó" (nếu tất cả những thứ thuộc loại này hoặc loại trước đó, tôi sẽ trả lời với "sửa những thứ này, tôi sẽ hợp nhất khi bạn nói với tôi bạn ' xong rồi "(và tại thời điểm đó có lẽ tôi sẽ nhanh chóng quét để thấy rằng không có gì khác xuất hiện)):

• Phân biệt nhỏ ("bạn đang so sánh một boolean với true, đó là một chút hoang tưởng ...", ...)
• Vi phạm kiểu nhỏ, ("hướng dẫn kiểu nói X, những gì bạn đã làm nằm ngoài điều đó; tôi sẽ làm Y hoặc Z, tùy thuộc vào cách bạn muốn đi")
• Một vài trường hợp thử nghiệm bị thiếu, không khó để viết

Và cuối cùng, "những vấn đề có vấn đề, tôi sẽ cần xem lại mã của bạn một lần nữa khi bạn đã khắc phục những vấn đề này" (nếu có bất kỳ vấn đề nào trong danh mục này, sẽ cần phải có một vòng đánh giá khác, vì vậy hãy đưa ra nhận xét " cũng có một vài điều nhỏ nhặt, sẽ rất tuyệt khi thấy một vài trong số đó được sửa trong khi bạn ở đó "nếu có bất cứ điều gì từ hai loại đầu tiên có mặt):

• Đây sẽ là những thứ như "không, thực sự có một cách viết tốt hơn RẤT NHIỀU", "bạn không tính toán những gì bạn mong đợi, bởi vì bài kiểm tra đơn vị của bạn bỏ lỡ những trường hợp cạnh này" và tất cả các vấn đề nghiêm trọng khác.

Có vẻ như một số người đã quên câu hỏi quan trọng nhất: bạn muốn thực sự đạt được điều gì với các đánh giá mã?

Mục đích của đánh giá mã là để có được mã không có lỗi và có thể bảo trì nhanh hơn. Đánh giá mã đạt được điều này theo nhiều cách: Nhà phát triển viết mã tốt hơn ngay từ đầu vì họ biết nó sẽ được xem xét, kiến ​​thức được chia sẻ như một phần của quy trình đánh giá, lỗi sẽ được tìm thấy vì người đánh giá không mù quáng trước những sai lầm của chính họ khi nhà phát triển có thể.

Nếu bạn thấy quá trình xem xét là một cơ hội để hạ bệ đồng nghiệp của mình, hoặc tạo ra công việc cho họ, thì bạn đã làm sai.