Xem lại trước hoặc sau khi cam kết mã, cái nào tốt hơn?

Theo truyền thống, chúng tôi đã thực hiện đánh giá mã trước khi cam kết, tôi đã có một cuộc tranh luận với đồng nghiệp của tôi ngày hôm nay, người thích xem xét mã sau khi cam kết.

Đầu tiên, đây là một số nền tảng,

1. Chúng tôi có một số nhà phát triển có kinh nghiệm và chúng tôi cũng có những nhân viên mới với kinh nghiệm lập trình gần như bằng không.
2. Chúng tôi muốn thực hiện các bước lặp nhanh và ngắn để phát hành sản phẩm của mình.
3. Tất cả các thành viên trong nhóm được đặt tại cùng một trang.

Những lợi thế của việc xem xét mã trước khi cam kết tôi đã học:

1. Mentor thuê mới
2. Cố gắng ngăn ngừa lỗi, thất bại, thiết kế xấu ngay từ đầu trong chu kỳ phát triển
3. Học hỏi từ người khác
4. Sao lưu kiến ​​thức nếu ai đó thoát

Nhưng tôi cũng đã có một số trải nghiệm tồi tệ:

1. Hiệu quả thấp, một số thay đổi có thể được xem xét qua nhiều ngày
2. Khó cân bằng tốc độ và chất lượng, đặc biệt là cho người mới
3. Một thành viên trong nhóm cảm thấy không tin tưởng

Đối với đánh giá sau khi cam kết, tôi biết rất ít về điều này, nhưng điều tôi lo lắng nhất là nguy cơ mất kiểm soát do thiếu đánh giá. Có ý kiến ​​gì không?

CẬP NHẬT:

1. Chúng tôi đang sử dụng Perforce cho VCS
2. Chúng tôi mã hóa và cam kết trong cùng một nhánh (các nhánh sửa lỗi hoặc thân cây)
3. Để cải thiện hiệu quả, chúng tôi đã cố gắng chia mã thành các thay đổi nhỏ. Chúng tôi cũng đã thử một số đánh giá hộp thoại trực tiếp, nhưng không phải ai cũng tuân theo quy tắc. Đây là một vấn đề khác mặc dù.

Giống như Simon Whitehead đề cập trong bình luận của mình , nó phụ thuộc vào chiến lược phân nhánh của bạn.

Nếu các nhà phát triển có chi nhánh riêng để phát triển (dù sao tôi cũng khuyên dùng trong hầu hết các tình huống), tôi sẽ thực hiện đánh giá mã trước khi hợp nhất với trung kế hoặc kho lưu trữ chính. Điều này sẽ cho phép các nhà phát triển có quyền tự do kiểm tra thường xuyên như họ muốn trong chu kỳ phát triển / thử nghiệm của họ, nhưng bất kỳ mã thời gian nào đi vào nhánh chứa mã được gửi, nó sẽ được xem xét.

Nói chung, trải nghiệm xấu của bạn với đánh giá mã nghe có vẻ giống như một vấn đề với quy trình xem xét có giải pháp. Bằng cách xem xét mã theo từng phần nhỏ hơn, bạn có thể chắc chắn rằng nó không mất quá nhiều thời gian. Một con số tốt là 150 dòng mã có thể được xem xét trong một giờ, nhưng tốc độ sẽ chậm hơn đối với những người không quen với ngôn ngữ lập trình, hệ thống đang được phát triển hoặc mức độ quan trọng của hệ thống (một vấn đề quan trọng về an toàn đòi hỏi nhiều thời gian hơn) - thông tin này có thể hữu ích để cải thiện hiệu quả và quyết định ai tham gia đánh giá mã.

Có một câu thần chú mà dường như chưa ai trích dẫn: Kiểm tra sớm và thường xuyên :

Các nhà phát triển làm việc trong thời gian dài - và lâu dài, ý tôi là hơn một ngày - mà không kiểm tra bất cứ điều gì trong kiểm soát nguồn đang tự đặt ra cho một số vấn đề tích hợp nghiêm trọng. Damon Poole đồng tình :

Các nhà phát triển thường ngừng đăng ký. Họ bỏ qua vì họ không muốn ảnh hưởng đến người khác quá sớm và họ không muốn bị đổ lỗi vì phá vỡ công trình. Nhưng điều này dẫn đến các vấn đề khác như mất việc hoặc không thể quay lại các phiên bản trước.

Nguyên tắc nhỏ của tôi là "đăng ký sớm và thường xuyên", nhưng với lời cảnh báo rằng bạn có quyền truy cập vào phiên bản riêng tư. Nếu đăng ký ngay lập tức hiển thị cho người dùng khác, thì bạn có nguy cơ đưa ra các thay đổi chưa trưởng thành và / hoặc phá vỡ bản dựng.

Tôi thà kiểm tra các mảnh nhỏ theo định kỳ hơn là đi trong thời gian dài mà không biết đồng nghiệp của tôi đang viết gì. Theo như tôi quan tâm, nếu mã không được kiểm tra trong kiểm soát nguồn, thì nó không tồn tại . Tôi cho rằng đây vẫn là một dạng khác của Don't Go Dark ; mã này là vô hình cho đến khi nó tồn tại trong kho lưu trữ ở một số hình thức.

... Nếu bạn học cách đăng ký sớm và đăng ký thường xuyên, bạn sẽ có nhiều thời gian để phản hồi, tích hợp và đánh giá trên đường đi ...

Tôi đã làm việc cho một vài công ty có cách tiếp cận khác nhau đối với việc này. Người ta cho phép nó, miễn là nó không ngăn được việc biên dịch. Cái khác sẽ phát điên nếu bạn kiểm tra bất kỳ lỗi nào cả. Các cựu được ưa thích nhiều. Bạn nên phát triển trong một loại môi trường cho phép bạn cộng tác với những người khác trong những điều vẫn đang được tiến hành, với sự hiểu rằng tất cả sẽ được kiểm tra sau.

Ngoài ra còn có tuyên bố của Jeff Atwood: Đừng sợ phá vỡ mọi thứ :

Cách trực tiếp nhất để cải thiện như một nhà phát triển phần mềm là tuyệt đối không sợ hãi khi thay đổi mã của bạn. Các nhà phát triển sợ mã bị hỏng là các nhà phát triển sẽ không bao giờ trưởng thành thành chuyên gia.

Tôi cũng sẽ thêm rằng đối với các đánh giá ngang hàng, nếu ai đó muốn bạn thay đổi điều gì đó, có lịch sử của phiên bản gốc của bạn trong nguồn là một công cụ học tập rất có giá trị.

Gần đây tôi đã bắt đầu thực hiện các đánh giá trước khi cam kết trong một dự án mà tôi tham gia và tôi phải nói rằng tôi rất ngạc nhiên về mức độ không hiệu quả của nó.

Hạn chế lớn nhất của các đánh giá sau cam kết mà tôi thấy là nó thường chỉ dành cho một người duy nhất: Ai đó xem xét mã cho chính xác, nhưng tác giả thường không tham gia trừ khi có lỗi nghiêm trọng. Các vấn đề nhỏ, đề xuất hoặc gợi ý thường không đến được với tác giả.

Điều này cũng thay đổi kết quả cảm nhận của các đánh giá mã: nó được xem như là thứ chỉ tạo ra công việc bổ sung, trái ngược với thứ mà mọi người (người đánh giá và tác giả của mã) có thể học những điều mới mỗi lần.

Đánh giá mã xác nhận trước có vẻ rất tự nhiên, đối với tôi, việc đánh giá có thể được thực hiện một cách có chủ ý sau khi cam kết. Từ góc độ tích hợp liên tục, bạn muốn cam kết mã của mình sau khi hoàn thành, không phải ở trạng thái làm việc nhưng có thể được viết kém, phải không?

Có thể đó là vì cách chúng tôi luôn thực hiện trong các nhóm của mình là hộp thoại trực tiếp do nhà phát triển ban đầu khởi xướng, chứ không phải các đánh giá dựa trên tài liệu không đồng bộ, điều khiển, dựa trên tài liệu.

Hầu hết các kho lưu trữ ngày nay đều hỗ trợ một cam kết hai pha hoặc một kệ (chi nhánh riêng, yêu cầu kéo, gửi bản vá hoặc bất cứ điều gì bạn muốn gọi nó), điều đó sẽ cho phép bạn kiểm tra / xem xét công việc trước khi kéo nó vào dòng chính. Tôi muốn nói rằng việc tận dụng các công cụ này sẽ cho phép bạn luôn thực hiện các đánh giá trước khi cam kết.

Ngoài ra, bạn có thể coi mã hóa cặp (cặp cao cấp với đàn em) như một cách khác để cung cấp đánh giá mã tích hợp. Hãy coi nó như một sự kiểm tra chất lượng trên dây chuyền lắp ráp thay vì sau khi chiếc xe đã lăn bánh.

Làm tất cả :

• cam kết trước - thực hiện loại đánh giá này khi nó là một thứ gì đó rất quan trọng, như một đoạn mã rất có thể tái sử dụng hoặc quyết định thiết kế chính
• đăng bài cam kết - thực hiện loại đánh giá này khi bạn muốn có ý kiến ​​về một đoạn mã có thể được cải thiện

Bất kỳ đánh giá chính thức nào cũng phải được thực hiện đối với các tệp nguồn nằm dưới sự kiểm soát cấu hình và các hồ sơ đánh giá nêu rõ việc sửa đổi tệp.

Điều này tránh mọi đối số loại "bạn chưa có tệp mới nhất" và đảm bảo mọi người đang xem lại cùng một bản sao của mã nguồn.

Điều đó cũng có nghĩa là, nếu bất kỳ chỉnh sửa sau đánh giá nào được yêu cầu, lịch sử có thể được chú thích với thực tế đó.

Đối với bản đánh giá mã, phiếu bầu của tôi là "trong thời gian" cam kết.

Một hệ thống như gerrit hoặc clover (tôi nghĩ) có thể tạo ra sự thay đổi và sau đó người đánh giá cam kết nó với kiểm soát nguồn (đẩy vào git) nếu nó tốt. Đó là điều tốt nhất của cả hai thế giới.

Nếu điều đó không thực tế, tôi nghĩ rằng sau khi cam kết là sự thỏa hiệp tốt nhất. Nếu thiết kế tốt thì chỉ những nhà phát triển cơ sở nhất mới có những thứ đủ tệ mà bạn không muốn họ cam kết. (Thực hiện đánh giá trước khi cam kết cho họ).

Điều này dẫn đến việc xem xét thiết kế - trong khi bạn có thể thực hiện nó tại thời điểm xem xét mã (hoặc cho vấn đề đó vào thời điểm triển khai của khách hàng), việc tìm kiếm các vấn đề thiết kế nên được thực hiện sớm hơn thế - trước khi mã thực sự được viết.

Với đánh giá ngang hàng, có nguy cơ mất kiểm soát tối thiểu. Tất cả thời gian hai người có kiến ​​thức về cùng một mã. Họ phải thỉnh thoảng chuyển đổi, vì vậy họ phải luôn chú ý theo dõi mã.

Thật có ý nghĩa khi có một nhà phát triển khéo léo và một người mới làm việc cùng nhau. Thoạt nhìn điều này có vẻ không hiệu quả, nhưng thực tế không phải vậy. Trong thực tế, có ít lỗi hơn và mất ít thời gian hơn để sửa chúng. Bên cạnh đó, những người mới sẽ học nhanh hơn nhiều.

Điều gì đến để ngăn chặn thiết kế xấu, điều này nên được thực hiện trước khi mã hóa. Nếu có bất kỳ thay đổi / cải tiến / thiết kế mới đáng kể nào, nó cần được xem xét trước khi bắt đầu mã hóa. Khi thiết kế được phát triển hoàn chỉnh, không còn nhiều việc phải làm. Việc xem lại mã sẽ dễ dàng hơn và sẽ mất ít thời gian hơn.

Tôi đồng ý rằng không cần thiết phải xem lại mã trước khi cam kết chỉ khi mã được sản xuất bởi nhà phát triển có kinh nghiệm, người đã chứng minh được kỹ năng của họ. Nhưng nếu có người mới, mã cần được xem xét trước khi cam kết: người đánh giá nên ngồi cạnh nhà phát triển và giải thích mọi thay đổi hoặc cải tiến do họ thực hiện.

Đánh giá được hưởng lợi từ cả trước và sau khi cam kết.

Cam kết trước khi xem xét

• Cung cấp cho người đánh giá sự tự tin rằng họ đang xem xét sửa đổi mới nhất của tác giả.
• Giúp đảm bảo tất cả mọi người đánh giá cùng một mã.
• Cung cấp một tài liệu tham khảo để so sánh một khi các phiên bản được thực hiện từ các mục đánh giá đã hoàn tất.

Không có cam kết chạy trong quá trình đánh giá

Tôi đã sử dụng các công cụ Atlassian và đã thấy các cam kết chạy xảy ra trong quá trình xem xét. Điều này gây nhầm lẫn cho người đánh giá, vì vậy tôi khuyên bạn nên chống lại nó.

Sửa đổi bài đánh giá

Sau khi người đánh giá hoàn thành phản hồi của họ, bằng lời nói hoặc bằng văn bản, người điều hành cần đảm bảo tác giả thực hiện các thay đổi được yêu cầu. Đôi khi người đánh giá hoặc tác giả có thể không đồng ý về việc có nên chỉ định một mục đánh giá là lỗi, đề xuất hoặc điều tra hay không. Để giải quyết các bất đồng và đảm bảo các mục điều tra được xóa chính xác, nhóm đánh giá phụ thuộc vào phán quyết của người điều hành.

Kinh nghiệm của tôi với khoảng 100 kiểm tra mã là khi các nhà đánh giá có thể tham chiếu một tiêu chuẩn mã hóa rõ ràng và đối với hầu hết các loại logic và các lỗi lập trình khác, các kết quả đánh giá thường rõ ràng. Thỉnh thoảng có một cuộc tranh luận về việc chọn nit hoặc một điểm về phong cách có thể suy biến để tranh luận. Tuy nhiên, việc trao quyền quyết định cho người điều hành sẽ tránh bế tắc.

Cam kết sau đánh giá

• Cung cấp cho người điều hành và người đánh giá khác một điểm dữ liệu để so sánh với cam kết trước khi xem xét.
• Cung cấp các số liệu để đánh giá cả giá trị và thành công của đánh giá khi loại bỏ lỗi và cải thiện mã.

Nó phụ thuộc vào nhóm của bạn tạo nên. Đối với một nhóm tương đối có kinh nghiệm về các cam kết nhỏ, thường xuyên sau đó xem xét sau cam kết chỉ để có được một cặp mắt thứ hai về mã là tốt. Đối với các cam kết lớn hơn, phức tạp hơn và / hoặc cho các nhà phát triển ít kinh nghiệm hơn thì các đánh giá trước khi cam kết sửa chữa các vấn đề trước khi chúng có vẻ thận trọng hơn.

Dọc theo những dòng đó, có một quy trình CI tốt và / hoặc kiểm tra kiểm soát sẽ giảm bớt nhu cầu đánh giá trước khi cam kết (và có thể đăng bài cam kết cho nhiều người trong số họ).

Tôi và các đồng nghiệp của tôi đã thực hiện một số nghiên cứu khoa học về chủ đề này gần đây, vì vậy tôi muốn thêm một số hiểu biết của chúng tôi mặc dù đây là một câu hỏi khá cũ. Chúng tôi đã xây dựng mô hình mô phỏng quy trình / nhóm phát triển Kanban nhanh nhẹn và so sánh đánh giá trước cam kết và đăng bài cam kết cho một số lượng lớn các tình huống khác nhau (số lượng thành viên nhóm khác nhau, cấp độ kỹ năng khác nhau, ...). Chúng tôi đã xem xét kết quả sau 3 năm thời gian phát triển (mô phỏng) và tìm kiếm sự khác biệt về hiệu quả (điểm hoàn thành), chất lượng (lỗi được tìm thấy bởi khách hàng) và thời gian chu kỳ (thời gian từ khi bắt đầu chuyển giao câu chuyện của người dùng) . Phát hiện của chúng tôi như sau:

• Sự khác biệt về hiệu quả và chất lượng là không đáng kể trong nhiều trường hợp. Khi không, đánh giá cam kết bài đăng có một số lợi ích liên quan đến chất lượng (các nhà phát triển khác hoạt động như "người thử nghiệm beta" theo cách nào đó). Để hiệu quả, cam kết bài có một số lợi ích trong các nhóm nhỏ và cam kết trước có một số lợi ích trong các nhóm lớn hoặc không có kỹ năng.
• Đánh giá trước khi cam kết có thể dẫn đến thời gian chu kỳ dài hơn, khi bạn gặp tình huống bắt đầu các nhiệm vụ phụ thuộc bị trì hoãn bởi đánh giá.

Từ những điều này, chúng tôi đã rút ra các quy tắc heuristic sau:

• Khi bạn có một quy trình xem xét mã được thiết lập, đừng bận tâm thay đổi, có lẽ nó không đáng để nỗ lực
  • trừ khi bạn gặp vấn đề với thời gian chu kỳ => Chuyển sang bài viết
  • Hoặc các sự cố bị trượt làm gián đoạn nhà phát triển của bạn quá thường xuyên => Chuyển sang Pre
• Nếu bạn chưa làm đánh giá
  • Sử dụng cam kết trước nếu một trong những lợi ích này được áp dụng cho bạn
    • Đánh giá trước cam kết cho phép người ngoài không có quyền cam kết đóng góp cho các dự án nguồn mở
    • Nếu dựa trên công cụ, đánh giá cam kết trước sẽ thi hành một số kỷ luật đánh giá trong các nhóm với việc tuân thủ quy trình lỏng lẻo
    • Đánh giá trước cam kết dễ dàng giữ cho các thay đổi chưa được xem xét được gửi, rất gọn gàng cho việc triển khai liên tục / chu kỳ phát hành rất ngắn
  • Sử dụng cam kết trước nếu nhóm của bạn lớn và bạn có thể sống với hoặc khắc phục các sự cố trong thời gian chu kỳ
  • Mặt khác (ví dụ: nhóm công nghiệp nhỏ, lành nghề) sử dụng bài cam kết
• Tìm kiếm sự kết hợp mang lại cho bạn lợi ích của cả hai thế giới (chúng tôi chưa nghiên cứu chính thức về những điều này)

Tài liệu nghiên cứu đầy đủ có sẵn ở đây: http://dx.doi.org/10.1145/2904354.2904362 hoặc trên trang web của tôi: http://tobias-baum.de

Theo tôi, mã đánh giá ngang hàng hoạt động tốt nhất nếu được thực hiện sau cam kết.

Tôi khuyên bạn nên điều chỉnh chiến lược phân nhánh của bạn. Sử dụng một nhánh nhà phát triển hoặc nhánh tính năng có một số lợi ích ... không phải là ít nhất trong số đó là tạo điều kiện cho các đánh giá mã sau cam kết.

Một công cụ như Crucible sẽ làm trơn tru và tự động hóa quá trình xem xét. Bạn có thể chọn một hoặc nhiều thay đổi đã cam kết để đưa vào đánh giá. Crucible nó sẽ hiển thị các tệp đã được chạm vào trong các thay đổi đã chọn, theo dõi các tệp mà mỗi người đánh giá đã đọc (hiển thị% hoàn chỉnh tổng thể) và để người đánh giá dễ dàng nhận xét.

http://www.atlassian.com/software/crucible/overview

Một số lợi ích khác của nhánh người dùng / tính năng:

• Các nhà phát triển nhận được lợi ích của kiểm soát phiên bản (sao lưu thay đổi, khôi phục từ lịch sử, thay đổi khác biệt) mà không phải lo lắng về việc phá vỡ hệ thống cho mọi người khác.
• Những thay đổi gây ra lỗi hoặc không hoàn thành đúng hạn có thể được sao lưu, ưu tiên lại hoặc tạm dừng nếu cần thiết.

Đối với các nhà phát triển thiếu kinh nghiệm, tham khảo ý kiến ​​thường xuyên với một người cố vấn và / hoặc lập trình cặp là một ý tưởng tốt, nhưng tôi sẽ không coi đây là "đánh giá mã".

Cả hai. (Loại.)

Bạn nên xem lại mã của riêng bạn trước khi cam kết. Ở Git, tôi nghĩ khu vực dàn dựng rất tuyệt. Sau khi tôi dàn dựng các thay đổi của mình, tôi chạy git diff --cachedđể xem mọi thứ được dàn dựng. Tôi sử dụng điều này như một cơ hội để đảm bảo rằng tôi không kiểm tra bất kỳ tệp nào không thuộc về (xây dựng các tạo phẩm, nhật ký, v.v.) và đảm bảo rằng tôi không có bất kỳ mã gỡ lỗi nào trong đó hoặc bất kỳ mã quan trọng nào được nhận xét ngoài. (Nếu tôi đang làm điều gì đó mà tôi biết tôi không muốn đăng ký, tôi thường để lại nhận xét trong tất cả các mũ để tôi nhận ra điều đó trong khi dàn dựng.)

Đã nói rằng, đánh giá mã ngang hàng của bạn thường được tiến hành sau khi bạn cam kết, giả sử rằng bạn đang làm việc trên một nhánh chủ đề. Đây là cách dễ nhất để đảm bảo rằng mọi người khác đang xem xét điều đúng, và nếu có vấn đề lớn, thì sẽ không có vấn đề gì lớn để khắc phục chúng trên chi nhánh của bạn hoặc xóa chúng và bắt đầu lại. Nếu bạn tiến hành đánh giá mã không đồng bộ (nghĩa là sử dụng Google Code hoặc Atlassian Crucible), thì bạn có thể dễ dàng chuyển đổi chi nhánh và làm việc trên một cái gì đó khác mà không phải theo dõi riêng tất cả các bản vá / khác biệt hiện đang được xem xét trong vài ngày.

Nếu bạn không làm việc trên một nhánh chủ đề, bạn nên . Nó làm giảm căng thẳng và rắc rối và làm cho kế hoạch phát hành bớt căng thẳng và phức tạp hơn nhiều.

Chỉnh sửa: Tôi cũng nên thêm rằng bạn nên thực hiện đánh giá mã sau khi thử nghiệm, đây là một đối số khác có lợi cho việc cam kết mã trước tiên. Bạn không muốn nhóm thử nghiệm của mình loay hoay với hàng tá bản vá / khác với tất cả các lập trình viên, sau đó nộp lỗi chỉ vì họ áp dụng bản vá sai ở sai vị trí.

Lập trình được ghép nối 100% (cho dù bạn nghĩ bạn có thâm niên đến đâu) với rất nhiều cam kết nhỏ và hệ thống CI xây dựng trên MỌI cam kết (với kiểm tra tự động bao gồm các đơn vị, tích hợp và chức năng bất cứ khi nào có thể). Đánh giá sau cam kết cho những thay đổi lớn hoặc rủi ro. Nếu bạn phải có một số loại đánh giá gated / pre-commit, Gerrit hoạt động.

Ưu điểm của đánh giá mã khi đăng ký (kiểm tra bạn bè) là phản hồi ngay lập tức, trước khi các đoạn mã lớn được hoàn thành.

Nhược điểm của việc xem xét mã khi đăng ký là nó có thể không khuyến khích mọi người đăng ký cho đến khi đoạn mã dài được hoàn thành. Nếu điều này xảy ra, nó hoàn toàn phủ nhận lợi thế.

Điều làm cho điều này trở nên khó khăn hơn là không phải mọi nhà phát triển đều giống nhau. Các giải pháp đơn giản không làm việc cho tất cả các lập trình viên . Giải pháp đơn giản là:

• Lập trình cặp bắt buộc, cho phép thực hiện kiểm tra thường xuyên vì bạn thân ở ngay bên cạnh bạn. Điều này bỏ qua rằng lập trình cặp không phải lúc nào cũng hoạt động cho tất cả mọi người. Hoàn thành đúng cách, lập trình cặp cũng có thể thực sự mệt mỏi vì vậy nó không nhất thiết phải làm gì đó cả ngày.

• Chi nhánh nhà phát triển, mã chỉ được xem xét và kiểm tra trong nhánh chính khi hoàn thành. Một số nhà phát triển có xu hướng làm việc bí mật và sau một tuần họ đưa ra một số mã có thể hoặc không thể vượt qua đánh giá vì các vấn đề cơ bản có thể được phát hiện trước đó.

• Đánh giá trên mỗi đăng ký, đảm bảo đánh giá thường xuyên. Một số nhà phát triển hay quên và dựa vào kiểm tra rất thường xuyên, điều đó có nghĩa là những người khác phải thực hiện đánh giá mã cứ sau 15 phút.

• Xem lại tại một số thời điểm không xác định sau khi nhận phòng. Đánh giá sẽ được đẩy ra xa hơn khi có thời hạn cuối cùng. Mã phụ thuộc vào cam kết đã được xác nhận nhưng chưa được xem xét mã sẽ được cam kết. Đánh giá sẽ đánh dấu các vấn đề và các vấn đề sẽ được đưa vào hồ sơ tồn đọng để được sửa chữa "sau này". Ok, tôi đã nói dối: Đây không phải là một giải pháp đơn giản, nó hoàn toàn không phải là một giải pháp. Xem lại tại một số thời điểm được chỉ định sau khi đăng ký hoạt động, nhưng ít đơn giản hơn vì bạn phải quyết định thời gian được chỉ định đó là gì

Trong thực tế, bạn thực hiện công việc này bằng cách làm cho nó thậm chí đơn giản hơn và phức tạp hơn cùng một lúc. Bạn đặt các hướng dẫn đơn giản và để mỗi nhóm phát triển tìm ra một nhóm những gì họ cần làm để tuân theo các nguyên tắc này. Một ví dụ về các hướng dẫn như vậy là:

• Công việc được chia nhỏ trong các nhiệm vụ nên mất ít hơn một ngày.
• Một tác vụ chưa kết thúc nếu mã (nếu có) chưa được kiểm tra.
• Một tác vụ chưa kết thúc nếu mã (nếu có) chưa được xem xét.

Nhiều hình thức thay thế của hướng dẫn như vậy là có thể. Tập trung vào những gì bạn thực sự muốn (mã được đánh giá ngang hàng, tiến độ công việc có thể quan sát được, trách nhiệm) và để nhóm tìm ra cách họ có thể cung cấp cho bạn những gì họ muốn.

chúng tôi thực sự làm một phép lai trên LedgerSMB. Các ủy viên cam kết thay đổi được xem xét sau. Những người không tham gia trình thay đổi để các ủy viên được xem xét trước. Điều này có nghĩa là hai tầng đánh giá. Đầu tiên bạn có được một người cố vấn để xem xét và cố vấn cho bạn. Sau đó, người cố vấn đó nhận được mã được xem lại lần thứ hai sau khi anh ta hoặc cô ta ký vào đó và phản hồi lưu hành. Ban đầu, những người mới thường dành nhiều thời gian để xem xét các cam kết của người khác.

Nó hoạt động khá tốt. Điều mặc dù là một đánh giá sau thường là khó hiểu hơn so với đánh giá trước đó, vì vậy bạn muốn chắc chắn rằng đánh giá sau được dành riêng cho những người đã chứng minh bản thân. Nhưng nếu bạn có một đánh giá hai cấp cho những người mới, điều đó có nghĩa là các vấn đề có nhiều khả năng bị bắt và các cuộc thảo luận đã có.

Cam kết ở đâu? Có một chi nhánh mà tôi tạo ra để làm một số công việc. Tôi cam kết với chi nhánh đó bất cứ khi nào tôi cảm thấy thích nó. Đó không phải là việc của ai cả. Sau đó, tại một số điểm, nhánh đó được tích hợp vào một nhánh phát triển. Và một nơi nào đó ở giữa là một đánh giá mã.

Người đánh giá đánh giá rõ ràng sau khi tôi cam kết với chi nhánh của mình. Anh ta không ngồi ở bàn của tôi, vì vậy anh ta không thể xem lại trước khi tôi cam kết với chi nhánh của mình . Và ông đánh giá trước khi hợp nhất và cam kết với ngành phát triển.

Chỉ không làm đánh giá mã ở tất cả. Hoặc bạn tin rằng các nhà phát triển của bạn có khả năng viết mã tốt, hoặc bạn nên loại bỏ chúng. Lỗi trong logic nên được kiểm tra bằng các bài kiểm tra tự động của bạn. Lỗi là phong cách nên được bắt bởi các công cụ phân tích tĩnh và lint.

Có con người tham gia vào những gì nên là quá trình tự động chỉ là lãng phí.