Làm thế nào để dần dần giới thiệu đánh giá mã?


26

Tôi đang lãnh đạo một nhóm với một nửa tá kỹ sư cao cấp. Tôi rất tin rằng nó sẽ có lợi cho chúng tôi rất nhiều để thực hiện đánh giá mã cho tất cả các lý do tiêu chuẩn. Không nhất thiết là mọi thay đổi nhưng ít nhất là một dòng đánh giá nền ổn định. Vì vậy, mọi người ít nhất nhìn thấy những thay đổi của người khác và bắt đầu nói về chúng.

Có một cách tốt để giới thiệu đánh giá? Tôi cảm thấy một sự miễn cưỡng lớn từ đội, bởi vì đó chỉ là một việc nữa để làm và các cuộc trò chuyện có thể trở nên đau đớn. Tôi cảm thấy như xem xét mọi thay đổi là không bắt đầu, ít nhất là bước đầu tiên. Tôi muốn mọi người hòa vào nhịp điệu và thực hành đánh giá với tần suất thấp trước khi tăng số lượng.

Có ai giới thiệu thành công mã đánh giá dần dần? Làm sao? Mặc dù tôi đã yêu cầu đánh giá về các tệp hoặc thư viện "nóng". Hoặc chọn ngẫu nhiên. Hoặc tôi chọn "lựa chọn" phải xem xét thay đổi. Hay là lao vào và thực hiện mọi thay đổi là cách duy nhất để đi?


Tôi đã không nhấn mạnh nó đủ trong câu hỏi nhưng "dần dần" là yếu tố chính ở đây. Tôi không nghĩ rằng việc xem xét 100% các thay đổi là hoàn toàn khả thi. Tuy nhiên, nếu chỉ xem xét một phần, làm thế nào để chọn một phần? Chỉ cần chọn "thay đổi yêu thích"? Một cái gì đó ngẫu nhiên? Lựa chọn chì? Câu trả lời ở đây rất hay nhưng thực sự không đánh vào phần "dần dần" trong tâm trí tôi.
Philip

Câu trả lời:


16

Đây không phải là một vấn đề về dụng cụ hoặc quy trình. Đó là về văn hóa. Bạn mô tả một nhóm bao gồm những người nhạy cảm với những lời chỉ trích và bảo vệ công việc của chính họ. Nó rất, rất phổ biến. Nhưng nó không chuyên nghiệp.

Lời khuyên của tôi là bắt đầu dẫn đầu bằng ví dụ. Cung cấp cam kết của bạn để xem xét. Hãy cởi mở về việc yêu cầu mọi người nêu bật những vấn đề trong cách tiếp cận của bạn. Hãy tiếp thu phản hồi. Đừng phòng thủ, mà thay vào đó hãy khám phá những lý do đằng sau phản hồi & đồng ý về các hành động như một đội. Khuyến khích một bầu không khí của hộp thoại mở. Tìm một hoặc hai nhà vô địch trong đội của bạn, những người sẵn sàng làm điều này cũng.

Đó là công việc khó khăn.


38

Bước đầu tiên sẽ là đến gặp ai đó và nói "này, bạn có xem lại mã của tôi không?". Hãy là người thay đổi bạn muốn thấy trong tổ chức của bạn. Nếu bạn không thể tìm thấy một cá nhân nào sẵn sàng làm điều đó, bạn sẽ không thể thuyết phục được cả nhóm. Nếu hai bạn có một số thành công, báo cáo lại cho nhóm.

Khi bạn đã tìm thấy ai đó để xem lại mã của mình, hãy hỏi xem họ có phiền không nếu bạn xem lại một số mã của họ . Phát âm nó như một cơ hội học tập cho bạn và không phải là cơ hội để họ cải thiện mã của họ.


10
"Này, tôi không hài lòng với thiết kế này, tôi có thể có được một bộ nhãn cầu thứ hai không?" Là một bước đầu tiên tuyệt vời. ++
RubberDuck

4

Là một nhóm trưởng, giá trị nhất tôi nhận được từ quá trình xem xét mã là nhận thức về những gì đang diễn ra. Tôi muốn có cơ hội thấy từng thay đổi, ngay cả khi tôi không có bất kỳ thay đổi hoặc đề xuất nào cho nhà phát triển. Tôi gọi đây là "đánh giá nhận thức." Tôi có thể xoay chúng trong vòng dưới 30 phút để không bị tắc nghẽn.

Tôi sẽ đề nghị bạn bắt đầu với những người. Xác định quy trình gửi đánh giá mã (nó khá dễ cắt và khô nếu bạn sử dụng TFS) và khiến mọi người tham gia vào việc gửi thay đổi của họ cho bạn (và chỉ bạn) trước khi đăng ký. Nói với họ rằng nó chỉ dành cho nhận thức và không ai sẽ chỉ trích mã của họ.

Sau một hoặc hai lần đánh giá nhận thức, hãy bắt đầu mời các thành viên khác trong nhóm xem xét mã của nhau ... một lần nữa, chỉ để nhận thức. Tin hay không, điều này một mình có thể hữu ích cho sự gắn kết nhóm và tính đồng nhất mã.

Khi bạn đã tham gia vào toàn bộ nhóm, có thể bạn sẽ thấy rằng các nhà phát triển của bạn không thể cưỡng lại việc đưa ra đề xuất về mã của nhau. Nó sẽ xảy ra một cách tự nhiên và hữu cơ (các kỹ sư không thể tự giúp mình!) Nhóm sẽ gặp nhau để thảo luận về vấn đề này và đưa ra các hướng dẫn để đưa ra phản hồi mang tính xây dựng cho nhau. Sau đó đặt chúng vào nó. Xin chúc mừng, bạn hiện đang ở chế độ xem lại mã đầy đủ!


1
Tôi thực sự thích thuật ngữ "đánh giá nhận thức" khái niệm thú vị. Đối với một khách hàng tiềm năng, có vẻ như bạn muốn nhận thức về những gì người khác đang làm. Nhưng tôi nghĩ bạn có thể làm cho mọi người trong nhóm, chúng ta cần nhận thức được những gì người khác đang làm vì lợi ích của chúng ta và của họ. Nếu không, chúng tôi thậm chí không ở trong một nhóm, chúng tôi chỉ làm việc song song.
Philip

4

Có một cách tốt để giới thiệu đánh giá?

Có thể có một số cách tốt, tùy thuộc vào nhóm của bạn và lợi ích bạn hy vọng nhận được từ các đánh giá, nhưng bất kỳ cách tiếp cận nào cũng sẽ có một số tính năng phổ biến:

  • giải thích những gì bạn mong đợi: Đây là một quy trình mới cho nhóm của bạn hoặc ít nhất là thay đổi quy trình hiện có, vì vậy thật công bằng khi cho nhóm biết lý do tại sao bạn tạo ra thay đổi, cách bạn mong đợi nhóm sẽ có lợi và Làm thế nào bạn sẽ biết liệu nó hoạt động.

  • xác định quy trình: Đưa mọi người qua quy trình bạn muốn họ theo dõi để xem xét mã, thảo luận về các thay đổi, v.v., để mọi người trong nhóm biết cách tiến hành.

  • xác định tiêu chí: Đưa ra các loại thay đổi mà mọi người nên và không nên gọi là cần cải thiện. Ví dụ, các lỗi và cải tiến hiệu suất đáng kể là tốt để chỉ ra; các tiêu chuẩn mã hóa, khả năng đọc và khả năng bảo trì cần được lưu ý nhưng không được chú ý; vấn đề sở thích cá nhân hoặc phong cách nên được để lại một mình.

  • thảo luận về hành vi: Chỉ ra rằng mục tiêu là cải thiện mã và thúc đẩy sự hiểu biết chung sẽ giúp nhóm viết mã tốt hơn trên bảng, không làm xấu hổ bất cứ ai, giải quyết điểm số, v.v. Phê bình nên khách quan và mang tính xây dựng, không bao giờ mang tính cá nhân. Việc đặt ra một số quy tắc cơ bản có thể giúp giảm bớt rủi ro về việc xem lại mã.

  • Đặt bản thân bạn lên ghế nóng trước: Cho dù bạn có kế hoạch đánh giá cá nhân hay đánh giá nhóm, có lẽ nên trải qua một vài lần đầu tiên với tư cách là một nhóm. Đánh giá đầu tiên phải là mã của riêng bạn để các thành viên khác trong nhóm có thể thấy rằng quy trình không quá tệ và bạn sẵn sàng tự mình trải qua.

Bắt đầu bằng cách tổ chức một cuộc họp khởi động để giải thích tất cả những điều trên và giải quyết các mối quan tâm của các thành viên trong nhóm. Theo dõi với e-mail tài liệu quá trình.

Tôi cảm thấy một sự miễn cưỡng lớn từ đội, bởi vì đó chỉ là một việc nữa để làm và các cuộc trò chuyện có thể trở nên đau đớn.

Đó là hai mối quan tâm riêng biệt. Nếu bạn tin rằng đánh giá sẽ hữu ích, thì bạn cần xây dựng thời gian vào lịch trình để thực hiện chúng. Hãy chắc chắn rằng các thành viên trong nhóm hiểu rằng việc xem xét là công việc giống như bất kỳ nhiệm vụ nào khác, không phải là điều gì đó bổ sung mà họ phải làm trong khi tiếp tục hoàn thành các nhiệm vụ khác với cùng một tỷ lệ.

Các cuộc họp đánh giá nhóm nên được dẫn dắt bởi một người điều phối, người sẽ tiếp tục thảo luận, hạn chế thời lượng cuộc họp và giữ mọi thứ mang tính xây dựng. Điều đó sẽ đi một chặng đường dài để tránh các cuộc trò chuyện đau đớn. Vào thời điểm bạn sẵn sàng bắt đầu đánh giá cá nhân, nhóm sẽ hy vọng có những hành vi được áp dụng để giúp họ giữ mọi thứ mang tính xây dựng.

Bạn cũng nên xem lại quá trình xem xét theo thời gian. Kết hợp nhóm thường xuyên để thảo luận về quy trình: nó hoạt động tốt như thế nào, có thể cải thiện nó như thế nào, nên bỏ những thực hành nào, v.v. Hãy cho nhóm sở hữu quy trình và tự do thử những điều mới.


-2

Một cách để làm điều đó là tiến hành các phiên đánh giá mã sau mỗi lần chạy nước rút và trải qua các thay đổi của mọi người trong đó mã được chiếu lên một màn hình lớn nào đó để mọi người trong nhóm có thể tham gia. Bất kỳ cải tiến có thể được thêm vào như nợ kỹ thuật để tồn đọng.

Cách tiếp cận này hiệu quả, nhưng nó không hoàn hảo.

Mục tiêu cuối cùng sẽ là sử dụng yêu cầu kéo để hợp nhất mã trở lại nhánh chính hoặc phát triển chi nhánh nơi mỗi dòng mã phải được xem xét.


3
Ngồi mọi người hàng giờ để xem lại tất cả các mã được tạo trong một lần lặp sau khi nó kết thúc (và quá muộn một cách hợp pháp) nghe có vẻ là một cách tuyệt vời để khiến mọi người ghét ý tưởng về Code Reviews.
RubberDuck

Chà .. nếu phải mất hàng giờ để xem lại mã được tạo trong một lần chạy nước rút, thì bạn đã làm sai, hoặc Sprint là 6 tháng hoặc nhóm có 50 người hoặc nhà phát triển không làm gì về mã hóa hoặc thực tiễn tốt nhất. Vì mã hóa không kết thúc sau khi lặp, không bao giờ là quá muộn và mã luôn thay đổi và nợ công nghệ có thể được xử lý trong các lần lặp tiếp theo. Và thực hiện đánh giá mã theo cách này cho phép các nhà phát triển chưa bao giờ thực hiện để xem những gì cần tìm và cứ thế ... một khi nó bắt đầu như vậy, nó có thể dần dần được chuyển sang các yêu cầu kéo
Low Flying Pelican

nhóm 7 người của tôi thêm / xóa / sửa đổi vài nghìn dòng mã trong hơn 3 chục lần xác nhận mỗi hai tuần. Một đánh giá chất lượng của một PR mất khoảng 15-60 phút. PR trung bình là 3-4 cam kết. Vì vậy, vâng. Nếu chúng tôi làm tất cả cùng một lúc thì sẽ mất 8 giờ X 7 dev thay vì 8 giờ trải khắp đội. Tôi bực bội khi bạn nói rằng chúng tôi đang làm gì đó sai. Chúng tôi đi prod vài lần một tuần . Phải không
RubberDuck

Chúng tôi thực hiện prod một lần mỗi lần lặp
Low Flying Pelican
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.