Làm cách nào để khiến các nhà phát triển thực hiện đánh giá mã một cách kịp thời

12

Công ty tôi làm việc yêu cầu tất cả các mã phải được xem xét bởi các nhà phát triển khác trước khi cam kết. Các thành viên trong nhóm của tôi thường thất vọng vì các nhà phát triển khác quá bận rộn để viết mã, đặc biệt là nếu nó rất dài. Làm thế nào để bạn khuyến khích các nhà phát triển khác thực hiện đánh giá mã kịp thời?

(Chúng tôi sử dụng git-svn để chúng tôi có thể tiếp tục mã hóa trong khi chờ xem xét. Tuy nhiên, tôi vẫn thấy bực bội khi phải chờ một thời gian dài trước khi tôi có thể cam kết mã của mình.)

code-reviews

— titandecoy
nguồn

12

Hãy xem cách facebook thực hiện nó với ứng dụng của riêng họ, được gọi là photypeator: http://phovenator.org/

Về cơ bản, họ cam kết trên cơ sở từng vấn đề và đối với từng vấn đề, mã được hiển thị, được xem xét bởi ai đó. Mã không đi vào kho lưu trữ chính của họ cho đến khi người đánh giá nói rằng làm như vậy là ổn.

Tôi đoán nó làm cho nó vui hơn.

Ngoài ra, có lẽ một mã nên được gán cho hai người: một người thực hiện và một người đánh giá nó.

Mặc dù có lẽ đồng đội của bạn không tin vào đánh giá này.

Cá nhân, vì thiếu người đánh giá, tôi đã sử dụng các bài kiểm tra đơn vị cho các chức năng cấp thấp hơn và "kiểm tra người gác cổng" cho tất cả những người còn lại: kiểm tra người gác cổng được gọi theo cách đó, bởi vì ngay cả người gác cổng cũng có thể hiểu mã của bạn.

Tôi thường loại bỏ một số phần nhỏ, như dấu ngoặc phạm vi khối / chức năng, ký hiệu hiển thị, đôi khi cả loại và hiển thị cho người quản lý, chuyên gia tên miền, bạn bè, bất cứ ai yêu cầu mã: "đây có phải là điều bạn muốn không?"

Ngoài ra, đến đó cá nhân và không rời đi cho đến khi xem xét được thực hiện giúp.

Hoặc, trong trường hợp bạn không ổn với nhóm hoặc họ không ổn với bạn, bạn biết, "nếu bạn có thể 'thay đổi công ty, thay đổi công ty" ...

— Aadaam
nguồn

9

Tôi sẽ dựa trên một số giả định:

Mọi người dường như muốn viết mã (Nếu không, bạn có những người cần phải đi.).
Mọi người đều muốn mã riêng của họ được kiểm tra.

Chỉ cho phép những người hoàn thành đánh giá của họ được kiểm tra mã của họ.

Có thể một khối thời gian nhất định có thể được dành riêng cho đánh giá mã với hy vọng tránh được vấn đề bị can thiệp.

Mục tiêu nên là kiểm tra mã chất lượng. Bạn không muốn trừng phạt / buộc các đánh giá đến mức mọi người chỉ chấp thuận "đóng dấu cao su".

Nếu bạn có các cấp độ khác nhau (jr., Sr. V.v.), việc quảng bá và duy trì một tiêu đề nên phụ thuộc vào công việc của bạn.

— Jeff
nguồn

1

Tại một vài nhà tuyển dụng trước đó, chúng tôi đã luân chuyển những người đang xem xét Mã hàng ngày. Thông thường, 3 người đã chia sẻ một ngày CR và mỗi CR phải được hai người đánh giá ký tên. Điều này đảm bảo rằng khi đó là ngày của bạn, bạn biết rằng CR được mong đợi ở bạn, bất kể các dự án khác của bạn. Vì vậy, cứ sau 5 ngày, đến lượt bạn và bạn có thể điều chỉnh các nhiệm vụ phát triển của mình cho phù hợp.

Hiện tại, chúng tôi có một Trưởng nhóm thực hiện một CR đáng chú ý về mã nhóm của họ. Tùy thuộc vào khu vực nào của ứng dụng đã được cập nhật, sau khi CR hoàn thành, nó có thể được chuyển đến Nhóm đánh giá toàn cầu, nơi chúng tôi kiểm tra những thứ có tác động toàn cầu đến (các) ứng dụng, thay vì những thứ đó liên quan đến một tính năng duy nhất. Khi có một Đánh giá lớn được thực hiện, chúng tôi thường chia nó giữa một vài người để không ai phải đối phó với các thay đổi trên một số lượng tệp vô lý.

Điều đó nói rằng, chúng tôi chỉ đang xem xét mã đã được cam kết với chi nhánh / biến thể Dev hiện tại. Mã phải vượt qua Đánh giá mã, Đánh giá toàn cầu, Đánh giá DB và Đánh giá giao diện người dùng (mỗi khi cần thiết) trước khi có thể được quảng bá sang môi trường tiếp theo (ví dụ Alpha).

Cuối cùng, chúng tôi đồng ý với SLA về cách nhanh chóng Nhận xét được quay vòng. Hầu như không có gì trong hàng đợi trong hơn 48 giờ và hầu hết các đánh giá được thực hiện trong vòng chưa đầy 24 giờ.

— Adrian J. Moreno
nguồn

1

Công ty tôi làm việc yêu cầu tất cả các mã phải được xem xét bởi các nhà phát triển khác trước khi cam kết. Các thành viên trong đội của tôi thường thất vọng ...

Trừ khi bạn đang thực hiện nhiệm vụ phần mềm quan trọng hoặc các bản vá quan trọng cho mã ứng viên phát hành sản xuất, không có lý do thuyết phục nào để gắn bó chặt chẽ với các loại đánh giá mã cụ thể.

^{Ý tưởng đằng sau yêu cầu công ty của bạn nghe có vẻ hợp lý trên một bề mặt (mã được xem xét 100%) nhưng phương tiện họ quyết định sử dụng là phản tác dụng - bởi vì như bạn chỉ ra, những điều này dẫn đến các nhà phát triển bị thất vọng.}

Đi trong đôi giày của bạn, trước tiên tôi sẽ chỉ ra cho ban quản lý rằng các đánh giá mã sau cam kết được coi là ngang hàng như những người trước khi cam kết . Các thuật ngữ này có thể tìm kiếm trên web - nếu cần, hãy tìm các tài liệu tham khảo để sao lưu này. Một người không nhất thiết cần đánh giá trước khi cam kết để có được mã được xem xét 100%.

Dựa trên, tôi sẽ đề nghị họ từ bỏ thái độ quản lý vi mô và để các nhà phát triển thử cách cảm thấy thuận tiện hơn với họ. Đánh giá trước hoặc sau cam kết là tốt nhất để các lập trình viên lựa chọn. Nếu công ty biết rõ hơn lập trình viên, tại sao họ không tự viết mã?

— gặm
nguồn

1

"Nếu công ty biết rõ hơn lập trình viên, tại sao họ không tự viết mã?": Nhận xét rất tốt! Nhưng tôi hy vọng rằng các nhà quản lý phát triển là những nhà phát triển trước đây.

— Giorgio

3

Post-commit làm tổn hại đến chất lượng mã của bạn một cách khủng khiếp theo kinh nghiệm của tôi. Các lập trình viên lười biếng, và họ sẽ cảm thấy họ đã hoàn thành nếu có thể cam kết: "ừ, không, nó không hoàn hảo, nhưng ai là người quan tâm, điều gì hoàn hảo trong cuộc sống? Đó là công việc, phải không? " câu trả lời tốt duy nhất là KHÔNG, và có lẽ các nhà quản lý có một hình ảnh thực tế hơn về các lập trình viên so với bản thân họ, đó là lý do tại sao họ yêu cầu đánh giá mã trước khi cam kết (hoặc ít nhất là trước khi hợp nhất).

— Aadaam

@Aadaam trải nghiệm của bạn chắc chắn khác với tôi - không chỉ liên quan đến phần sau, mà còn (và đặc biệt) phần viết của "Lập trình viên lười biếng ..." Đối với các nhà quản lý có hình ảnh thực tế hơn, tôi đồng ý rằng đó là trường hợp điển hình trong các đội của tôi; nó chỉ không dẫn dắt các nhà quản lý mà tôi từng làm việc với những ý tưởng vô nghĩa về việc xem xét loại nào để ép buộc

— gnat

Vâng, tôi đã làm việc trong gia công phần mềm. Trong việc thuê ngoài, hầu hết các lập trình viên không tham gia vì lập trình rất thú vị, họ tham gia vì lập trình có tỷ lệ công việc / lương cao nhất, với tỷ lệ cao hơn nhiều so với bất kỳ công việc nào khác ... họ ghét nó như mọi công việc khác .. và họ hãy cố gắng làm mọi thứ để tiếp tục "tối ưu hóa" tỷ lệ này, nếu bạn hiểu ý tôi là ...

— Aadaam

1

Bạn có một số vấn đề cần giải quyết - bạn phải giành được trái tim và tâm trí và bạn phải đảm bảo rằng thời gian có sẵn để đánh giá mã.

Phần thứ hai có lẽ là dễ nhất - bạn đồng ý (gọi chung và phải bao gồm cả quản lý) rằng điều đầu tiên mà một nhà phát triển làm mỗi buổi sáng là đánh giá mã của họ - điều này đơn giản, dễ hiểu, hiệu quả và mang lại cho bạn một cây gậy rõ ràng đẹp để đánh bại mọi người nếu họ không tuân thủ. Tốt hơn, bạn không làm gián đoạn bất cứ điều gì, bạn không yêu cầu họ ngừng làm việc với mã của họ, bạn sẽ không yêu cầu mọi người ép thứ gì đó vào danh sách việc cần làm của họ ...

Phần đầu tiên là vấn đề thực sự - những người tham gia trong quá trình đánh giá phải xem đó là giá trị nếu không họ sẽ không bao giờ thực hiện đánh giá mã (được coi là không có giá trị) khi họ có thể viết mã hoặc sửa lỗi (mà chắc chắn là quan trọng hơn ...?).

Nếu bạn có thể kết hợp cả hai - trước hết hãy đảm bảo rằng mọi người đều tin (hoặc hiểu) rằng có giá trị trong các đánh giá mã - về cơ bản nhất có nghĩa là ít lỗi hơn có nghĩa là nhiều mã mới thường vui hơn - và sau đó sắp xếp thứ hai mọi thứ để có một không gian rõ ràng trong lịch trình cho các đánh giá mã được thực hiện sau đó hy vọng những điều tốt đẹp sẽ xảy ra ... nó sẽ trở thành một phần của văn hóa.

Một khi là một phần của văn hóa, có thể không còn cần phải nói "điều đầu tiên mỗi ngày" - nhưng đã nói rằng tôi nghĩ rằng nó phù hợp với mô hình mà người ta có thể muốn một nhà phát triển làm việc.

— Murph
nguồn

Bạn không thể thực sự đồng ý rằng quy tắc "điều đầu tiên mỗi ngày" ở nơi đầu tiên. Nếu ai đó tìm thấy một lỗi gây thiệt hại cho công ty X đô la mỗi giờ (hoặc tăng nguy cơ bỏ lỡ thời hạn quan trọng thêm X điểm phần trăm mỗi giờ) và họ tình cờ làm như vậy năm phút trước khi bạn vào, thì đánh giá mã không phải là của bạn ưu tiên hàng đầu. Về cơ bản vấn đề là sự xung đột giữa mong muốn thiết lập các quy tắc đơn giản, so với thực tế là các ưu tiên không phải lúc nào cũng đơn giản. Rủi ro là tất cả mọi người sẽ hết lòng đồng ý quy tắc này và trong vòng 24 giờ sẽ tìm thấy một số lý do tại sao ngày nay là một ngoại lệ đối với quy tắc này.

— Steve Jessop

Và giải pháp rất khó, nhưng IME bạn phải tìm đủ "không gian" để giới thiệu một thực hành làm việc mới tốn thời gian nhưng đáng giá. Điều này đòi hỏi tầm nhìn xa để xác định thời gian chậm chạp, sẵn sàng để thời hạn trôi qua vì giá của việc đưa ra một thay đổi đáng giá, hoặc cả hai. TANSTAAFL. Giống như bạn nói, một khi mọi người đã ổn định trong khuôn mẫu, họ có thể tạo ra ngoại lệ. Hy vọng họ làm như vậy dựa trên sự đánh giá đúng về giá trị của mẫu chung.

— Steve Jessop

Tôi nói "hãy để thời hạn trôi qua", đáng lẽ tôi nên nói "di chuyển thời hạn". "trượt" ngụ ý di chuyển chúng sau khi chúng được cam kết, tức là thất bại, nhưng nó không cần phải như vậy. Thay vào đó, bạn có thể lập kế hoạch cho một khoảng thời gian năng suất giảm nhẹ do quy tắc mới không linh hoạt (và sự thiếu hiệu quả không thể tránh khỏi do mọi người cố gắng thực hiện theo bất kỳ quy trình mới nào - nếu bạn đang thực hiện đánh giá mã trước tiên thì bạn sẽ bỏ lỡ scrum buổi sáng họp vào những ngày mà việc đánh giá mã mất quá nhiều thời gian, hoặc bất cứ điều gì độc đáo gây khó chịu cho tổ chức của bạn có thể đưa vào hỗn hợp). Nếu đó là một quy tắc tốt, bạn sẽ sớm vượt lên trên nơi bạn bắt đầu.

— Steve Jessop

@SteveJessop tất nhiên bạn có thể thực sự đồng ý rằng. Và tất nhiên sẽ có ngoại lệ (tôi tình cờ nghĩ rằng quan sát scrum là ngớ ngẩn - đặc biệt là câu trả lời là rõ ràng (- :). Tôi nghĩ rằng điều quan trọng là không có "một kích thước phù hợp với tất cả giải pháp" Tôi chỉ đề xuất một cái gì đó đơn giản và dễ hiểu và tương đối khó để sắp xếp lịch trình của một người (một lần nữa tùy thuộc vào môi trường)

— Murph

1

Tại hầu hết các công ty tôi đã làm việc, bạn có 3 ngày để hoàn thành đánh giá. Không thể chấp nhận việc không đánh giá. Đó là một phần công việc của bạn. Nếu bạn không đánh giá đúng thời gian, nó sẽ ảnh hưởng đến việc đánh giá hiệu suất của bạn. Và vâng, các đánh giá dường như luôn xảy ra vào những thời điểm không thuận lợi nhất. Quá tệ, học cách bao gồm thời gian xem xét trong ước tính của bạn. Dù sao, nếu quản lý thực sự tin rằng các đánh giá là quan trọng (nghĩa là họ bắt buộc tất cả các mã được xem xét) thì họ sẽ thúc đẩy một chính sách tương tự. Ngoài ra, nếu mọi người không hoàn thành đánh giá trong thời gian quy định, đó là sự chấp nhận của họ đối với tài liệu.

— Úp rổ
nguồn

0

Xem xét sử dụng một công cụ như Bảng đánh giá . Nó rất hữu ích, đặc biệt là cho các đánh giá dài.

Bạn có thể tải lên khác biệt của bạn và đợi cho đến khi một người đánh giá kết thúc đánh giá của họ. Nếu bạn có các đánh giá mở ngăn bạn tiếp tục công việc, bạn có thể báo cáo việc này trong các cuộc họp hàng ngày (nhóm của bạn muốn kiểm tra các tính năng mới để chúng có thể được kiểm tra càng sớm càng tốt, phải không?).

— Giorgio
nguồn

0

Một vài điểm để thêm mà không có trong các câu trả lời khác.

Mã cần được xem xét phải được kiểm tra

để bạn đang xem xét một phiên bản ổn định.
Nó có thể nằm trong nhánh phát triển chính nếu một bản phát hành đủ xa
Nó có thể ở trên nhánh nếu có lý do chính đáng để không gây ô nhiễm chính

Các nhiệm vụ chặn được ưu tiên, do đó, đánh giá mã nên ưu tiên hơn các công việc khác (nhưng cố gắng không phá vỡ luồng của bạn). Là một nhà phát triển, bạn nên muốn người khác xem lại mã của mình (vì bạn đang hướng đến việc làm cho nó tốt hơn). Trong kiến thức đó, bạn nên thực hiện đánh giá cho người khác kịp thời.

Các câu hỏi khó hơn là khi nào và làm thế nào để đánh giá mã tốt.

Một quy tắc đã có hiệu quả đối với chúng tôi khi đó là mã chia sẻ phải được xem xét vì nó có tác động rộng hơn trong khi mã cho một ứng dụng (đặc biệt là chúng tôi đang sử dụng phát triển theo hướng kiểm tra) ít quan trọng hơn.

— Bruce Adams
nguồn