Làm thế nào để khuyến khích các nhà phát triển cơ sở tham gia đánh giá mã?

Tôi hiện đang làm việc như một nhà phát triển cấp cao với 3 đàn em bên dưới và đã giới thiệu quy trình xem xét mã để giúp quản lý chất lượng mã đi vào sản xuất.

Tôi cảm thấy rất có lợi cho tất cả chúng ta khi xem xét công việc của nhau, tuy nhiên sau khoảng 5 tuần của quy trình, tôi là người duy nhất đưa ra bất kỳ nhận xét nào trong công cụ (BitBucket).

Tôi nghĩ rằng có một số vấn đề văn hóa tại nơi làm việc, và có lẽ là một sự miễn cưỡng tự nhiên trong trường hợp ý kiến ​​của họ là sai, nhưng có cách nào và tôi có thể giúp các đàn em cảm thấy thoải mái hơn khi phê bình tôi và mỗi người làm việc không?

Đối với tôi, câu hỏi ở đây là "bạn đang tìm kiếm nhà phát triển cơ sở nào để thoát khỏi các đánh giá mã?". Đối với tôi, có khả năng điều quan trọng nhất là để các nhà phát triển cơ sở học hỏi bằng cách xem xét những gì được hy vọng là mã tốt; nếu họ tình cờ tìm thấy các vấn đề trong mã của bạn, đó là một phần thưởng.

Nếu bạn đang tìm kiếm nhân viên cấp dưới của mình để học hỏi từ các đánh giá mã, điều quan trọng nhất bạn phải làm là tạo ra một môi trường mà việc học có giá trị và không bị xem là lãng phí thời gian. Điều này có nghĩa là một số điều:

• Không có gì là một câu hỏi ngu ngốc . Nếu ai đó không hiểu một chút về mã, tại sao bạn đã sử dụng một mẫu nhất định hoặc bất cứ điều gì, họ cần thoải mái hỏi, mà không bao giờ cảm thấy rằng họ đang lãng phí thời gian của bạn hoặc của các nhà phát triển khác .
• Thời gian học tập là thời gian chi tiêu tốt . Bạn muốn các nhà phát triển cơ sở của mình dành thời gian xem mã và học hỏi từ nó, bởi vì điều đó sẽ giúp họ trở thành nhân viên tốt hơn, năng suất hơn trong tương lai. Trừ khi đó là một sửa chữa quan trọng cần được xem xét ngay bây giờ , khuyến khích họ dành nhiều hơn, thay vì ít hơn, thời gian cho các đánh giá mã.
• Nhân viên cấp cao không phải lúc nào cũng đúng . Chỉ vì bạn đã làm điều này lâu hơn không có nghĩa là bạn đúng. Nếu họ nghĩ rằng họ đã tìm thấy một lỗi, có lẽ họ đã đúng. Nếu họ nghĩ rằng một mẫu thiết kế khác sẽ phù hợp với đoạn mã này, thì họ cần cảm thấy thoải mái khi nói như vậy mà không nhận được phản hồi tiêu cực.

Có các cuộc họp xem xét mã trực tiếp vào thời gian thiết lập mỗi tuần. Tôi đã bán nó cho đồng đội của mình như thế này (chúng tôi thực sự là cả hai nhà phát triển cao cấp, nhưng bất cứ điều gì):

"Việc xem xét mã là một phần để tôi hiểu mã của bạn hơn một chút và biết những gì đang diễn ra bên cạnh bạn trong trường hợp bạn bị xe tải đâm vào một ngày nào đó và tôi được lệnh hoàn thành chạy nước rút. Nhưng chủ yếu là ở đó để bạn giải thích mã của mình cho người khác, bởi vì khi bạn làm điều đó, nó tham gia vào một phần khác của bộ não của bạn và thường xuyên giải thích cho bạn, và / hoặc câu hỏi hoặc nhận xét của họ, có thể khiến bạn nhớ ra điều gì đó bạn đã quên để làm trong mã, hoặc có thể khiến bạn nhận ra một cách tốt hơn để làm cho nó dễ đọc hơn hoặc kiến ​​trúc sư tốt hơn. Điều đó dẫn đến mã đẹp hơn. "

Tôi thích nghĩ về nó như một chương trình biểu diễn. Mọi người có thể thể hiện công việc của họ với đồng nghiệp của họ. Đó không phải là về những đồng nghiệp của bạn phát hiện ra những điều sai trái trong công việc của bạn, điều mà không ai thích cảm giác đó. Đó là về việc gây ấn tượng với đồng nghiệp của bạn bằng mã tuyệt vời của bạn, điều mà mọi người đều thích cảm giác đó.

Tuy nhiên, tôi nghĩ rằng việc sử dụng các công cụ đánh giá mã khi không có sự tương tác của con người, không có cuộc họp trong phòng, không có bảng trắng .. nó trở thành một "việc" gây phiền nhiễu khác. Không phải là không nên có những công cụ như vậy, nhưng chúng nên là thứ bạn sử dụng nếu trong cuộc họp đánh giá mã, nó nhận ra rằng việc xem xét sâu hơn về một phần mã nhất định có thể là cần thiết. Sau đó, bạn có thể chỉ định một trong những nhà phát triển cơ sở để xem lại mã của người khác trên một khu vực nhất định.

Bạn có thể giúp đỡ bằng cách nêu một ví dụ tốt. Bạn không thể phòng thủ khi ai đó chỉ ra sai lầm của bạn. Thực hiện đánh giá mã trên mã của riêng bạn và lưu ý các lĩnh vực cải tiến. Chia sẻ điều này với nhóm. Cuối cùng, họ sẽ biết rằng điều này được khuyến khích và không ai sẽ bị đánh vì có lỗi trong mã của họ.

Có một công việc có nghĩa là nhận trách nhiệm và niềm tự hào trong công việc của bạn. Nếu đánh giá mã là một phần của điều đó, thì việc tham gia đánh giá mã phải được đưa vào các đánh giá. Tôi đã tham gia các lớp học trực tuyến trong đó việc tham gia các cuộc thảo luận trực tuyến là một phần của lớp. Bình luận cần được xây dựng trên. "Tôi đồng ý" không được chấp nhận.

Xem lại mã nên cải thiện mã. Tùy thuộc vào tình huống của bạn, nó có thể được đo bằng số bán hàng, khiếu nại của người dùng hoặc một số đánh giá khác nếu bạn viết mã để sử dụng nội bộ. Thực tế là mã của bạn phục vụ mục đích nào đó và nhóm của bạn nên được đo lường bằng mức độ họ phục vụ mục đích đó. Những người bạn xác định đóng góp cho sự thành công, có được để chia sẻ tương ứng trong phần thưởng.

Tập trung vào việc phát hành mã chất lượng. Mục tiêu không phải là để mọi người cảm thấy tốt về bản thân họ bằng cách tránh xa các lỗi. Tôi viết mã xấu; Tôi phải sửa mã xấu. Đó là công việc và cuộc sống. Tôi ghét sửa lỗi, vì vậy tôi cố gắng tránh chúng. Tôi tự hào về công việc của mình, vì vậy nó làm phiền tôi khi mã của tôi không hoạt động. Tôi cảm thấy tồi tệ cho người dùng hoặc bất kỳ ai khác phải dành thời gian của họ để chỉ ra những điều này và nó thúc đẩy tôi muốn sửa nó.

Như một lưu ý phụ, nếu bạn có một môi trường mà không ai có thể đưa ra hoặc chấp nhận những lời chỉ trích mang tính xây dựng, bạn có một vấn đề.

Quá trình: Ai đó muốn cam kết thay đổi của mình. Ai đó được chỉ định là người đánh giá và xem xét các thay đổi. Sau đó, các thay đổi được xem xét và cố định đi đến thử nghiệm.

Nếu kiểm tra tìm thấy lỗi được giới thiệu trong thay đổi, thì tác giả và người đánh giá cũng đáng trách.

Vì vậy, thực hiện đánh giá mà không có bất kỳ nhận xét nào sẽ khiến bạn gặp rắc rối trừ khi mã hoàn hảo.