Một suy nghĩ hữu ích khi tiến hành đánh giá mã chính thức là gì

Nhóm của chúng tôi gần đây đã bắt đầu tiến hành đánh giá mã đối với mỗi lần đăng ký.

Khi trưởng nhóm, tôi đang cố gắng tìm sự cân bằng giữa việc cung cấp quá nhiều đề xuất, các nhà phát triển gây phiền nhiễu và giảm sản lượng của nhóm và buông mã tôi sẽ viết khác đi.

Có bằng chứng, nghiên cứu hoặc hướng dẫn từ các nguồn nổi tiếng cho thấy một cách tiếp cận hữu ích?

Hãy ghi nhớ các mục tiêu bao quát: cuối cùng, chỉ có vấn đề về phần mềm

Đánh giá ngang hàng và đánh giá mã đăng ký có mục tiêu để cải thiện chất lượng . Nhưng không có gì tồi tệ hơn cho chất lượng hơn một nhà phát triển đã được giải thích. Với tư cách là trưởng nhóm, vai trò của bạn không phải là xác nhận mã như một thứ mà bạn có thể tự viết, mà là để thúc đẩy tinh thần đồng đội và đảm bảo kết quả chung.

Đặt phạm vi rõ ràng cho đánh giá của bạn

Hãy ghi nhớ: đó không phải là mã của bạn, mà là mã của đội. Vì vậy, tập trung vào những thứ có thể dẫn đến kết quả sai.

• Đừng thách thức cách nhà phát triển của bạn đã chọn để đáp ứng các yêu cầu, trừ khi bạn chắc chắn rằng nó sẽ không hoạt động (nhưng nó đã thất bại trong các thử nghiệm, phải không?)

• Đừng thách thức cho hiệu suất kém trừ khi có một biện pháp cho thấy vấn đề nằm ở đâu. Tối ưu hóa sớm là gốc rễ của mọi tội lỗi ;-)

• Nếu bạn tìm thấy một thiết kế hoặc cấu trúc phần mềm để thách thức, thì hãy tự hỏi tại sao nó không được bắt kịp! Đã viết mã là tốn kém để viết lại. Nếu điều này xảy ra, đã đến lúc xem lại các hoạt động phát triển phần mềm và làm việc nhóm của bạn ít nhất bằng mã.

• tuân thủ địa chỉ với các tiêu chuẩn mã hóa được thiết lập. Đây là chủ đề khó chịu nhất để thảo luận cho cả người đánh giá và người được đánh giá. Khi tất cả mọi người đồng ý sử dụng tên lớp viết hoa trong nhóm của bạn và một anh chàng có một lớp mà không có, đó có phải là vấn đề của hương vị? Hoặc hiệu quả làm việc nhóm và rủi ro?

Nhân tiện, nếu bạn cảm thấy một tiêu chuẩn mã hóa không đáng để thảo luận, hãy loại bỏ nó thành tiêu chuẩn của bạn và đừng lãng phí thời gian và năng lượng cho nó.

Phát triển khả năng lãnh đạo: khía cạnh con người của đánh giá

Là người lãnh đạo nhóm, bạn có thể tìm thấy ở đây một cơ hội để phát triển bản thân và nhóm của mình, ngoài hình thức kiểm soát chất lượng:

• Đánh giá mã dễ chịu hơn nhiều cho mọi người, nếu có một trao đổi thực sự. Cung cấp cho nhà phát triển của bạn cơ hội cũng để thể hiện các kỹ năng của họ (và vâng, có lẽ bạn có thể học được điều gì đó mới).
• Có một tai mở để chỉ trích về lựa chọn thiết kế, hoặc các tiêu chuẩn hiện có. Đôi khi mọi người có thể đối phó tốt hơn với những thất vọng như vậy, chỉ vì họ có thể nói về nó.
• Huấn luyện cho đàn em của bạn: đừng ngần ngại đưa ra lời khuyên, hoặc tái cấu trúc các định hướng cho lần lặp tiếp theo. Đừng làm điều này với người cao niên: ở một thế giới khác, vai trò tương ứng của bạn có thể đã thay đổi.

Tận dụng các thực hành khác

Có một vài điều mà bạn có thể tránh khi xem lại mã:

• Việc sử dụng một bộ phân tích mã tĩnh trong chuỗi xây dựng của bạn có thể tự động hóa việc tìm kiếm các lỗi phổ biến hoặc các cấu trúc không di động, rất lâu trước khi đánh giá ngang hàng. Một số công cụ thậm chí có thể kiểm tra một số tiêu chuẩn mã hóa của bạn .
• Nếu bạn có các tiêu chuẩn về bố cục mã, hãy sử dụng một trình định dạng đẹp được in sẵn hoặc tương tự để định dạng mã theo yêu cầu tự động. Không bao giờ dành thời gian cho một cái gì đó phần mềm có thể làm cho bạn tốt hơn và không cần thảo luận :-)
• Cuối cùng, chất lượng không chỉ được đảm bảo bằng đánh giá, mà còn bằng các thử nghiệm. Nếu bạn chưa sử dụng TDD , hãy suy nghĩ độc lập với đánh giá mã.

Là nhà phát triển chúng tôi, tư duy nên luôn luôn mở và hoài nghi cùng một lúc.

Mở, bởi vì chúng tôi không biết khi nào nhà phát triển có thể làm chúng tôi ngạc nhiên và hoài nghi về ý tưởng của chúng tôi bởi vì chúng tôi thường quên rằng trong công nghệ phần mềm không có một cách chính xác duy nhất để thực hiện giải pháp. Lý do đằng sau các giải pháp của chúng tôi có thể có ý nghĩa đối với chúng tôi và không làm cho người khác. Đằng sau một mùi mã có thể là một ý tưởng tuyệt vời. Có lẽ, nhà phát triển đã không tìm ra cách thể hiện nó đúng.

Do chúng tôi (con người) rất tệ trong việc giao tiếp, không đưa ra các giả định sai, sẵn sàng hỏi chủ sở hữu mã về mã bạn đang xem xét. Nếu anh ấy / cô ấy thất bại trong việc mã hóa ý tưởng theo tiêu chuẩn của công ty, vì nhà phát triển chính cũng sẵn sàng hướng dẫn anh ấy / cô ấy.

Ở đây cách tiếp cận chủ quan. Cách tiếp cận khách quan, IMO, được giải thích rất rõ trong câu hỏi này .

Ngoài liên kết ở trên, tập hợp các mục tiêu cần đạt được (khả năng duy trì, khả năng đọc, tính di động, độ gắn kết cao, khớp nối lỏng lẻo, v.v.) không nhất thiết phải là Mười điều răn. Bạn (nhóm) sẽ có thể điều chỉnh các mục tiêu này đến một điểm mà sự cân bằng giữa chất lượng và năng suất làm cho công việc trở nên dễ hiểu và "có thể ở được cho các nhà phát triển".

Tôi sẽ đề nghị sử dụng các công cụ phân tích mã tĩnh để đo lường tiến trình của chất lượng theo các mục tiêu này. Các công cụ như SonarQube cung cấp cho chúng tôi Cổng chất lượng và Hồ sơ chất lượng có thể được tùy chỉnh theo các ưu tiên của chúng tôi. Nó cũng cung cấp cho chúng tôi một trình theo dõi vấn đề, nơi các nhà phát triển có thể được nhắm mục tiêu với các vấn đề liên quan đến mùi mã, lỗi, thực tiễn đáng ngờ, v.v.

Những loại công cụ này có thể là một điểm khởi đầu tốt, nhưng như tôi đã nói hãy giữ cho mình sự hoài nghi. Bạn có thể thấy một số quy tắc trong Sonar là vô nghĩa đối với bạn, vì vậy hãy bỏ qua chúng hoặc xóa chúng khỏi hồ sơ chất lượng của bạn.

Hòa giải với mã của nhà phát triển để thay đổi mỹ phẩm sẽ làm mất lòng nhà phát triển nhưng trong trường hợp tuyệt đối thì phải thực hiện. Người dẫn đầu phải tìm sự cân bằng giữa việc cung cấp đánh giá mã hữu ích và học cách loại bỏ những thiếu sót nhỏ. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-ledge/

Một số điều cần lưu ý:

1. Đó là về tâm lý cũng như về công nghệ, vì vậy không có quy tắc vàng ở đây.
2. Những gì về con người không chỉ là về kiến ​​thức mà còn về văn hóa và vị trí trong hệ thống phân cấp.
3. Nếu đây là một trò chơi "dài" (công ty ổn định và được thành lập), nhóm tích hợp tốt nơi mọi người tin tưởng lẫn nhau thường có giá trị cao hơn mã được xem xét. Nó không nên được sử dụng để buộc những thứ không hoàn toàn bắt buộc phải tiến hành. Quỷ dữ nằm trong chi tiết ...
4. Nếu đây là một trò chơi "ngắn" (dự án phụ, R & D, rất nhiều người làm việc tự do trong một nhóm) thì chi phí của CR thường vượt qua các cuộc phiêu lưu bắt đầu từ việc thực hiện chúng. Và thái độ nên là "chỉ làm cho nó trở nên"

Chỉ có hai điều quan trọng.

1. Có kiểm tra tự động cho tất cả các yêu cầu?
2. Có phải tất cả đều vượt qua?

Tất cả mọi thứ khác là mỹ phẩm và nên được tranh luận về bia hơn là thực thi như một cổng.

Nếu bạn theo quan điểm này, thì nó giới hạn bạn trong một khu vực hẹp tập trung.

Các yêu cầu có tốt không? Lý tưởng nào bạn nên biết trước khi bắt đầu nhiệm vụ, tức là hiệu năng, bảo mật, v.v.

Các bài kiểm tra có tốt không? Bất kỳ trường hợp cạnh bị bỏ lỡ, họ đang kiểm tra yêu cầu tốt, vv Cuối cùng: Bạn có thể viết một bài kiểm tra cho một yêu cầu hiện có nhưng sẽ thất bại?