Bắt TẤT CẢ các nhà phát triển thực hiện đánh giá mã

Tôi là nhà phát triển phần mềm trong nhóm 7-8 nhà phát triển. Chúng tôi đã thực hiện đánh giá mã trong một thời gian khá lâu và chất lượng mã đã được cải thiện theo thời gian.

Tuy nhiên gần đây tôi nhận thấy rằng một số nhà phát triển đang được yêu cầu đánh giá mã nhiều hơn những người khác. Tôi sợ đó là vì thái độ linh hoạt của họ.

Theo quan điểm của tôi, đây không phải là cách đánh giá mã nên được thực hiện: tất cả các nhóm phải chịu trách nhiệm về nó và người đánh giá mã không nên được chọn vì họ sẵn sàng dễ dàng chấp nhận thay đổi.

Làm thế nào để bạn đối phó với vấn đề này trong nhóm của bạn?

Bạn đã thiết lập các quy tắc để chọn người đánh giá mã?

Bạn có nghĩ rằng người đánh giá mã nên được khen thưởng cho thời gian họ dành để thực hiện đánh giá mã (tốt) không? Và họ nên được khen thưởng như thế nào?

Cảm ơn câu trả lời / ý tưởng của bạn.

Chúng tôi không chọn người đánh giá.

Trong nhóm của chúng tôi:

• Tất cả các thay đổi mã phải được xem xét mã trước khi Yêu cầu kéo được hoàn thành
• Ít nhất một nhà phát triển phải đánh giá mã (hai hoặc nhiều người đánh giá là tốt hơn và có người kiểm tra, nhà phân tích và các thành viên khác trong nhóm thực hiện đánh giá mã cũng cực kỳ có lợi)

Nhận xét mã không được chỉ định, mọi người nhận chúng khi nó hoạt động cho họ. Sự hiểu biết là chúng ta không thể đẩy câu chuyện qua đường ống dẫn. Thỉnh thoảng ai đó sẽ đề cập rằng họ đang chờ CR trong tình huống chờ đợi nhưng đó là về nó.

Tôi thích mô hình này, nó cho phép mọi người chọn những gì họ có thể và tránh "giao việc cho mọi người".

Đưa ra một quy tắc rằng một lỗi có thể được chỉ định để sửa chữa, không chỉ cho những người đã thực hiện thay đổi, mà chỉ cho những người đã xem xét nó. Điều đó sẽ tạo ra quan điểm chính xác cho việc xem xét mã.

Đối với

Bạn có nghĩ rằng người đánh giá mã nên được khen thưởng cho thời gian họ dành để thực hiện đánh giá mã (tốt) không?

Chà, tôi không chắc các nhà phát triển thường được khen thưởng như thế nào khi thực hiện công việc của họ ngoại trừ việc chỉ nhận được tiền lương và tự hào về những gì họ đã làm. Nhưng vì mã đánh giá là một phần công việc của họ, người đánh giá nên dành thời gian để xem xét và chia sẻ tín dụng bằng cách nào đó.

Vấn đề chính bạn gặp phải không phải là kỹ thuật, nhưng một số công cụ có thể làm giảm lượng nỗ lực mà các đánh giá mã thực hiện. Có một vài thách thức cần vượt qua:

• Hiểu được sự thay đổi là gì. Yêu cầu kéo Git trên các nhánh tính năng thực sự giúp ích cho quá trình này.
• Làm cho mã xem lại một sự kiện mà mọi người phải ở trong cùng một phòng. Điều này làm tăng thêm sự căng thẳng của việc lên lịch, tài nguyên cuộc họp, v.v. GitHub, GitLab và BitBucket cho phép đánh giá không đồng bộ để chúng có thể xảy ra khi ngang hàng đã sẵn sàng.
• Khả năng cung cấp thông tin phản hồi có ý nghĩa khi xem mã. Thành thật mà nói, tính năng bình luận từng dòng trong các yêu cầu kéo GitHub, GitLab, Bitbucket thực sự hữu ích hơn so với gặp mặt trực tiếp. Nó cảm thấy ít chính trị hơn.

Điều đó không có nghĩa là bạn không thể sử dụng SubVersion hoặc các công cụ khác (như Fisheye) để trợ giúp, nhưng việc tích hợp được tích hợp vào đường ống Git với các nhánh tính năng thực sự làm cho công việc trở nên khó khăn hơn.

Ngoài công cụ, bạn cần xem xét nhiều thách thức xã hội hơn:

• Yêu cầu các nhà phát triển của bạn bắt đầu ngày mới bằng cách xem xét bất kỳ yêu cầu kéo mở nào để đăng xuất.
• Yêu cầu các nhà phát triển của bạn xem xét mọi yêu cầu kéo mở trước khi họ bắt đầu một nhiệm vụ mới
• Yêu cầu phê duyệt từ nhiều người cho các yêu cầu kéo của bạn.

Cũng có thể đáng để kiểm tra loại nhiệm vụ nào đang được xem xét bởi những người tham gia nhiều hơn. Họ có thể lấy tất cả các đánh giá dễ dàng, điều này làm cho mọi thứ khác đau đớn hơn.

Một ý tưởng tốt là thực hiện nó trên cơ sở luân chuyển vòng - bạn chọn ai đó đã thực hiện số lượng đánh giá ít nhất cho mã của mình. Theo thời gian, mọi người trong nhóm nên đã thực hiện một số lượng đánh giá bằng nhau. Nó truyền bá kiến ​​thức quá.

Rõ ràng sẽ có những trường hợp ngoại lệ không thường xuyên như ngày lễ, nơi sẽ có đỉnh và đáy.

Không nên có sự phân biệt giữa đàn em và đàn anh / dẫn. Đánh giá mã nên được thực hiện cho mã của mọi người - bất kể họ cao cấp đến đâu. Nó làm giảm ma sát và giúp chia sẻ các phương pháp khác nhau.

Nếu bạn vẫn lo ngại về chất lượng của các đánh giá sau tất cả những điều này, hãy xem xét giới thiệu một bộ tiêu chuẩn tối thiểu để đánh giá mã được thông qua. Những gì bạn bao gồm hoàn toàn tùy thuộc vào bạn nhưng một số điều bạn có thể muốn xem xét là phạm vi bảo hiểm mã, kiểm tra đơn vị, xóa mã nhận xét, số liệu, nhận xét đầy đủ, chất lượng xây dựng, nguyên tắc RẮN, DRY, KISS, v.v.

Đối với đánh giá mã khuyến khích, mã chất lượng là phần thưởng. Tất cả chúng tôi chắc chắn đã làm việc trên các cơ sở mã tối ưu phụ, trong đó nỗi đau có thể giảm đi đáng kể khi một nhà phát triển khác chỉ đưa mã một lần nữa ngay từ đầu và đề xuất thay đổi mang tính xây dựng.

Có vẻ như nhóm thiếu một quy trình chính thức để đánh giá mã.

Tôi không nói về việc tạo một tài liệu Word 350 trang, mà chỉ là một số gạch đầu dòng đơn giản về những gì quy trình đòi hỏi.

Các bit quan trọng:

1. Xác định một bộ các nhà phê bình cốt lõi. Không có tuyên bố chung. Tên người.

   Đây nên là nhà phát triển cao cấp của bạn.

2. Yêu cầu nhiều hơn 1 người đánh giá cốt lõi để đăng xuất vào đánh giá.

3. Xác định ít nhất 1 người đánh giá không cốt lõi khác mỗi lần chạy nước rút hoặc phát hành ai là người đánh giá cốt lõi tạm thời. Yêu cầu đăng xuất của họ trên tất cả các đánh giá mã trong thời gian này.

Mục số 3 cho phép các nhà phát triển khác xoay vòng vào nhóm người đánh giá cốt lõi. Một số tuần họ sẽ dành nhiều thời gian cho đánh giá hơn những người khác. Đó là một hành động cân bằng.

Còn khen thưởng cho mọi người? Nhiều lần thừa nhận nỗ lực mà một người đang thực hiện trong quá trình xem xét mã trước toàn bộ nhóm có thể làm việc, nhưng đừng căng thẳng vì điều này.

Khi nghi ngờ, hãy xác định quy trình và nói với nhóm mà họ cần bám sát.

Và có một điều cuối cùng bạn có thể thử - gây tranh cãi vì nó có thể là: hãy để @ # $% chạm vào người hâm mộ, nếu tôi có thể sử dụng một thành ngữ.

Hãy để nhóm thất bại, vì quá trình xem xét mã không được tuân theo. Quản lý sẽ tham gia, và sau đó mọi người sẽ thay đổi. Đây thực sự chỉ là một ý tưởng tốt trong những trường hợp cực đoan nhất mà bạn đã xác định một quy trình và nhóm từ chối tuân theo nó. Nếu bạn không có quyền sa thải mọi người hoặc kỷ luật họ (vì hầu hết các nhà phát triển chính không có ) thì bạn cần phải có ai đó tham gia có thể làm công việc này.

Và không có gì giống như thất bại để khiến mọi thứ thay đổi. Mặc dù mọi người có thể nói gì, bạn có thể điều khiển tàu Titanic - nhưng không phải trước khi nó đâm vào băng trộm.

Đôi khi bạn chỉ cần để Titanic đâm vào tảng băng.