Ai nên làm mã đánh giá?

Trong công ty của tôi chủ yếu là kiến ​​trúc sư đánh giá mã. Anh ấy là một người rất có kinh nghiệm và phần mềm thông minh, vì vậy anh ấy rất giỏi về nó. Khi các nhà phát triển thực hiện đánh giá mã, họ cũng không làm điều đó một nửa. Chúng tôi đã cố gắng cung cấp cho các nhà phát triển để thực hiện nhiều đánh giá mã hơn, nhưng chất lượng của các đánh giá mã không tốt. Chúng tôi sử dụng Scrum cho phương pháp phát triển.

Tuy nhiên với hệ thống hiện tại có hai vấn đề:

1. Kiến trúc sư trở thành nút cổ chai

2. Các nhà phát triển không chịu trách nhiệm về chất lượng của mã và kiến ​​trúc (dẫn đến tất cả các loại vấn đề).

Làm thế nào chúng ta có thể giải quyết những vấn đề này? Chúng ta có nên thay đổi ai làm mã đánh giá?

Các nhà phát triển nên làm mã đánh giá. Họ nên thực hiện đánh giá mã, bởi vì họ nên biết mã, các tiêu chuẩn và thông lệ về phong cách của công ty. Bằng cách nhờ người khác thực hiện đánh giá mã, bạn đang nói với các nhà phát triển của mình rằng họ không có trách nhiệm đảm bảo mã đáp ứng các tiêu chuẩn của công ty.

Nếu bạn nghĩ rằng họ cần được đào tạo về đánh giá mã, hãy lấy nó cho họ. Với tình hình hiện tại của bạn, bạn có thể yêu cầu nhà phát triển đánh giá mã và sau đó nhận xét của kiến ​​trúc sư của bạn - yêu cầu nhà phát triển gửi đánh giá cho kiến ​​trúc sư để phê duyệt trước khi gửi cho người nộp.

Trong tình huống này, những gì bạn cần là kiến ​​thức của nhà phát triển có kinh nghiệm này để giúp phần còn lại của nhóm phát triển. Chất lượng của một nhóm không được xác định bởi các kỹ năng của nhà phát triển tốt nhất; nó được xác định bởi các kỹ năng tồi tệ nhất. Bạn có thể thử những thứ như:

• Đánh giá hợp tác. Điều này làm việc thực sự tuyệt vời trong đội cuối cùng của tôi. Chúng tôi đưa cả đội vào một phòng có máy chiếu và bắt đầu xem xét một số vật phẩm. Có lẽ lúc đầu, kiến ​​trúc sư là người hướng dẫn đánh giá, nhưng trong một vài tuần (chúng tôi dành một hoặc hai giờ mỗi thứ Sáu), cả nhóm bắt đầu nói và hiểu các khái niệm chính mà hiện tại chỉ có kiến ​​trúc sư biết.

• Lập trình cặp. Đối với tôi đây là công cụ tốt nhất để truyền bá kiến ​​thức trong một nhóm.

Mặc dù tôi có thể thấy điểm cần thiết khi kiến ​​trúc sư hệ thống / phần mềm ký tắt tất cả các thay đổi / cam kết, các nhà phát triển phần mềm có thể thực hiện đánh giá mà không liên quan đến kiến ​​trúc sư - ngoại trừ trọng tài.

Thủ tục xem xét [*] ưa thích của tôi là:

• Nhóm thay đổi theo yêu cầu / vấn đề.
• Mời tất cả các nhà phát triển, kiến ​​trúc sư phần mềm và tác giả của yêu cầu / vấn đề cần xem xét. (Họ đang không phải tất cả cần phải làm một bài đánh giá.)
• Xem xét đánh giá kết thúc khi:
  • Hai nhà phát triển đã xem xét.
  • Tất cả các ý kiến ​​được phản hồi. (Có thể bằng cách kiến ​​trúc sư phần mềm đưa ra quyết định.)
  • Một ngày làm việc đã trôi qua mà không cần thảo luận thêm (hoặc tất cả các bên được mời đã xem xét).

Vì vậy, câu trả lời ngắn gọn của tôi cho câu hỏi của bạn là: Các nhà phát triển nên thay đổi đánh giá.

[*] Thật không may, đây không phải lúc nào cũng là cách các dự án tôi tham gia vận hành.

Tôi thích thực hành đánh giá mã nhóm thỉnh thoảng bao gồm toàn bộ đội ngũ kiến ​​trúc sư, nhưng sau đó rất nhiều và rất nhiều đánh giá mã giữa hai hoặc ba thành viên của nhóm.

Nếu đó là mã thực sự phức tạp hoặc nhạy cảm, thì hãy tranh thủ kiến ​​trúc sư hoặc thành viên cấp cao của nhóm.

Thành thật mà nói, nghe có vẻ vô lý khi có một kiến ​​trúc sư thực hiện đánh giá mã. Anh ta nên thực hiện đánh giá thiết kế, hoặc thỉnh thoảng đánh giá mã không chính thức để chia sẻ chuyên môn của mình. Đội ngũ kỹ thuật phải chịu trách nhiệm về mã. Nếu có vấn đề, sau đó họ sẽ trở nên tốt hơn với thời gian.

Tôi đồng ý, nếu chỉ cần một người đánh giá, những người còn lại có thể sẽ chỉ đi với "Tôi không biết, nó có vẻ hiệu quả, nhưng hãy để anh chàng thông minh đó tìm ra nếu nó ổn hay không". Tôi có thể nghĩ về những điều sau đây:

• công khai mã của bạn để mọi người có thể thấy mọi người đang làm gì; đặt tên ở đầu mỗi tệp có chứa mã; có thể in chúng ra và đóng dấu chúng trong, uhh, phòng tắm hoặc bất cứ nơi nào bạn cảm thấy nó sẽ bắt mắt
• lập trình cặp; với một bộ não khác bên cạnh bạn, bạn sẽ suy nghĩ kỹ trước khi đặt tên cho biến của mìnhi
• nhấc người gác cổng của bạn và giải thích cho anh ta cách thức kế thừa đó hoạt động (oh, vâng, nó không hoạt động). Giải thích mã của bạn cho người khác giúp. Có thể nó biên dịch, có thể nó làm đúng thứ, nhưng bạn không thực sự hiểu tại sao. Bây giờ là cơ hội của bạn
• có một bộ hướng dẫn và làm cho mọi người tuân theo chúng; bất kể hướng dẫn nào, tốt hơn là không có hướng dẫn