Làm thế nào để đối phó với một người không thích ý tưởng đánh giá mã?

Rõ ràng, nếu quản lý mua để dành thời gian với đánh giá mã, thì mọi người phải làm điều đó.

Nhưng luôn có những kẻ (hoặc những cô gái) chống cự với mỗi ounce của bản thể họ.

Làm thế nào để bạn quản lý hiệu quả việc xử lý tình huống này khi xử lý nó với tư cách là người đánh giá ngang hàng?

Anh chống cự vì sợ hãi . Điều kiện này có thể là kết quả của (các) trải nghiệm tồi tệ trước đây về việc được xem xét, khi còn bé, ở trường, tại nơi làm việc hoặc thậm chí trong nhóm hiện tại của bạn. Trong xã hội hiện đại của chúng ta, việc chúng ta nhầm lẫn giữa đầu ra công việc của ai đó với giá trị của anh ta là điều rất phổ biến. Đó là lý do tại sao đánh giá tại nơi làm việc không được nhận thức tốt. Đó cũng là lý do tại sao nói trước công chúng ở một trong những nỗi ám ảnh lan rộng nhất (sợ bị phán xét).

Để tránh hành vi như vậy, bạn sẽ cần một số tâm lý. Bạn phải chứng minh cho bộ não thằn lằn của anh ta điều đó sẽ không xảy ra (anh ta sẽ không bị phán xét, làm nhục, giết chết, bất cứ điều gì ...) bằng cách giải mẫn anh ta để đánh giá mã.

Một trong những phương pháp hiệu quả nhất mà tôi tìm thấy để bỏ chặn ai đó là yêu cầu anh ta xem lại mã của bạn , trước khi yêu cầu xem lại mã của anh ta.

Sau một thời gian, đề nghị anh ta đọc mã của mình để học hỏi từ nó và tại sao không đề xuất cải tiến. Khi bạn tìm thấy một cái gì đó để thay đổi, hãy cẩn thận trong những gì bạn viết. Anh ta sẽ hiểu không có gì phải sợ, và anh ta sẽ chỉ lấy phần tích cực của quá trình xem xét: học hỏi và tăng kiến ​​thức của mình .

Tôi sẽ thử làm việc theo cặp - nhóm một người ghét ý tưởng với người thích nó và yêu cầu họ xem lại mã của nhau trong một vài tuần. Rõ ràng điều này có thể có hoặc không có ích, nhưng ở cả hai đầu của bài đánh giá ít nhất sẽ đưa ra một cái nhìn tròn hơn về quy trình. Có một cặp làm việc cùng nhau sẽ cho phép họ làm quen với phong cách và những lỗi phổ biến của nhau và sẽ cho họ thời gian để thực sự giúp nhau trở nên tốt hơn, thay vì con dấu cao su. Điều này cũng có thể giúp bạn thúc đẩy lập trình cặp trong môi trường làm việc của bạn, vì tôi nghĩ rằng bạn có thể thấy xu hướng ngày càng tăng không chỉ xem xét, mà còn mã hóa lại hoặc thậm chí lập kế hoạch và mã từ đầu.

Miễn là các bên không quan tâm sẵn sàng thử, điều này có thể giúp ích. Nếu họ từ chối xem xét, bạn sẽ không thể làm được gì nhiều miễn là họ ở trong đội.

Câu trả lời của @ Pierre là đúng hướng cho một người sợ đánh giá mã. Tôi có thể tưởng tượng một tình huống khác. Một lập trình viên ngôi sao cảm thấy việc xem xét mã là một sự lãng phí thời gian vì có mã đạt đến một tiêu chuẩn chấp nhận được về chất lượng và tính chính xác. Trong trường hợp này, họ có thể cảm thấy một đánh giá mã là một kẻ lãng phí thời gian và một cuộc săn phù thủy. (Đó là tìm kiếm một vấn đề khi không tồn tại.)

Trong trường hợp này tôi sẽ định hướng lại mục tiêu của đánh giá. Thay vì xem xét mã về việc tìm kiếm "vấn đề" trong mã, hãy coi nó như một tìm kiếm cho các mục tiêu bao thanh toán lại hoặc các cải tiến tiềm năng trong tương lai hoặc các tính năng thiết kế bổ sung. Theo cách này, cả người viết mã và người đánh giá đều tham gia vào quá trình và hy vọng rằng người viết mã có khả năng này sẽ cảm thấy như có thời gian được sử dụng tốt.

Thành thật mà nói, câu hỏi này không có ý nghĩa gì nếu bạn có một cửa hàng được quản lý tốt:

1) Nếu đó là một phần của công việc, bạn phải thực hiện nó hoặc bạn không tuân thủ. Một số người kiên quyết từ chối thực hiện một phần công việc họ bắt buộc phải làm nên bị đóng hộp. Lập trình là một nghề thủ công và một nghề nghiệp - các nhà phê bình và quản lý luôn sẵn sàng giúp đỡ hoàn thành công việc, không phải đối phó với những đứa trẻ hư hỏng (ở mọi lứa tuổi.).

2) Nếu bạn có một hệ thống kiểm soát nguồn được quản lý tốt, (điều bắt buộc trong bất kỳ cửa hàng phần mềm chuyên nghiệp nào), thì mã của họ có thể được xem xét cho dù họ có thích hay không. Vì vậy, xem lại mã của họ:

• Nếu nó tốt, hãy thông báo cho họ và vỗ nhẹ vào lưng họ - điều đó sẽ khuyến khích sự tham gia.

• Nếu nó không tốt, cũng cho họ biết. Điều này sẽ có tác dụng thúc đẩy họ tham gia, để tự vệ. Nếu không, bạn có thể sử dụng các biện pháp trừng phạt: Hình phạt tài chính, giảm nhẹ tình trạng, v.v ... Nếu bất chấp nỗ lực của bạn, nhân viên này không đến, IMO bạn có một nhân viên tồi và họ sẽ được đưa ra cửa.

Họ có một số trải nghiệm tiêu cực ở những nơi mà các đánh giá mã không được thực hiện đúng không? Họ có thể có mối quan tâm chính đáng.

Nếu họ hoàn toàn thấy không có công với bài tập, hãy yêu cầu họ kiên nhẫn và xem điều gì xảy ra với mã của họ và đặc biệt là những thứ khác (nếu họ nghĩ là hoàn hảo).

Đánh giá mã 'nên' cải thiện sự phát triển, nhưng cho đến khi bạn có một hệ thống thực sự hoạt động, tại sao mọi người lại muốn làm điều đó?

Cá nhân tôi cho rằng có một số trận đánh không thể chiến thắng với 100% dân số.

Tôi có thể thấy đủ lý do tại sao lập trình cặp sẽ không hoạt động khi ai đó bị buộc phải làm điều đó.

Nhưng đánh giá mã là khác nhau - chúng thay đổi năng suất của bạn, không nhất thiết là thói quen làm việc của bạn.

Quản lý có thể làm một số điều để giảm sức đề kháng do năng suất: 1) Chấp nhận giảm tốc độ cho tất cả các nhà phát triển. 2) Cung cấp các công cụ thích hợp để đối phó với việc quản lý và hợp nhất nhiều phiên bản do chu kỳ xem xét (ví dụ: cho phép nhà phát triển có kho lưu trữ git cục bộ) 3) Áp dụng một số hình thức xã hội hoặc áp lực khác để đảm bảo phân phối tải và chất lượng và kịp thời đánh giá.

Nếu họ làm điều đó, việc yêu cầu mọi người tham gia, IMHO là hợp pháp. Công ty tôi hiện đang làm việc cho các lực lượng này trên toàn cầu - bạn chỉ cần không thể gửi mà không có sự chấp thuận của chủ sở hữu. Và trong khi điều này làm mọi thứ chậm lại, nó ngăn ngừa rất nhiều tai nạn.

Chúng tôi đã sử dụng các biện pháp kỹ thuật để bắt buộc xem xét mã.

Cách chúng tôi giới thiệu đánh giá mã là trong kiểm soát nguồn của chúng tôi, không thể hợp nhất mã không được ký bởi người khác sau đó là người đã đẩy nó.

Bắn chúng

Thật đơn giản - hoặc họ có được một dự án đơn độc, hoặc họ phải đi. Đưa họ ra khỏi đội của bạn. Họ không chỉ không làm phần việc của mình, mà còn làm xói mòn tinh thần và thực hành của đội.

Bây giờ, nếu có vẻ như bạn phải sa thải 50% đội của mình, thì ...

Hiểu không

Tại sao một số từ chối? Họ không có thời gian à? Họ có bị cháy không? Là những đánh giá về một cái gì đó họ không có kinh nghiệm với? Họ có nghĩ rằng đó là một sự lãng phí thời gian, nếu vậy tại sao?

Phương pháp nhanh nhẹn sẽ giúp ích ở đây - Tôi giả sử bạn liên tục làm việc chống lại silo (tức là để giảm yếu tố xe buýt) và các cá nhân trong nhóm của bạn có liên quan đến những gì người khác làm.

Làm việc để đảm bảo các yêu cầu hợp nhất cá nhân là khá nhỏ. Nếu có nhiều hơn 1 màn hình thay đổi, nó cần một cuộc trò chuyện độc lập hoặc chớp nhoáng để giải thích những gì đang được thực hiện. Nếu là 10 trang, nó cần một bản trình bày với các slide và sơ đồ kiến ​​trúc.

Có phải tất cả mọi người trong câu hỏi làm việc trên cùng một dự án?

Là dự án đã bị chôn vùi dưới núi nợ kỹ thuật?

Họ có tin vào dự án và cải tiến liên tục?