Quy trình xem xét mã nơi tác giả yêu cầu kéo phải hợp nhất

Một số nhóm tại công ty của tôi thực hành quy trình đánh giá mã mà tôi chưa từng thấy trước đây. Tôi đang cố gắng để hiểu suy nghĩ đằng sau nó, với ý tưởng rằng có giá trị trong việc làm cho toàn bộ công ty nhất quán. (Tôi đóng góp cho nhiều cơ sở mã hóa và đã bị tăng gấp ba bởi những khác biệt trong quá khứ.)

1. Mã tác giả gửi yêu cầu kéo
2. Người kiểm tra kiểm tra mã
3. • Nếu người đánh giá chấp thuận, họ sẽ để lại nhận xét dọc theo dòng chữ "Có vẻ tốt, hãy thoải mái hợp nhất"
   • Nếu người đánh giá có mối quan tâm, họ để lại nhận xét như "Vui lòng sửa các vấn đề nhỏ X và Y, sau đó hợp nhất" (Đối với các thay đổi lớn, quay lại bước 2)
4. Tác giả mã thực hiện các thay đổi nếu cần thiết, và sau đó hợp nhất yêu cầu kéo của chính họ

Tôi có những mối quan tâm sau:

• Trong trường hợp phê duyệt ở bước 3, quy trình làm việc này tạo ra một vòng tròn dường như không cần thiết cho tác giả yêu cầu kéo. Người đánh giá, người đã xem mã, có thể hợp nhất nó ngay lập tức.

• Trong trường hợp các thay đổi được yêu cầu ở bước 3, cơ quan hợp nhất yêu cầu kéo giờ chỉ thuộc về tác giả của PR. Không ai ngoài tác giả sẽ xem xét các thay đổi trước khi sáp nhập.

Một số lợi thế hoặc bất lợi khác cho quy trình công việc này là gì? Là công việc này phổ biến trên các nhóm kỹ thuật khác?

Trong trường hợp đầu tiên, đó thường là phép lịch sự. Trong hầu hết các tổ chức, việc sáp nhập khởi động một loạt các thử nghiệm tự động phải được xử lý kịp thời nếu chúng thất bại. Đặc biệt là nếu có một sự chậm trễ đáng kể giữa khi yêu cầu kéo được gửi và khi nó được xem xét, thật lịch sự khi cho phép nó được hợp nhất theo thời gian biểu của tác giả, vì vậy họ có thời gian để xử lý bất kỳ sự cố bất ngờ nào. Cách dễ nhất để làm điều đó là để cho họ tự hợp nhất nó.

Ngoài ra, đôi khi tác giả nhận ra lý do sau đó yêu cầu kéo không nên được hợp nhất. Có thể PR của nhà phát triển khác được ưu tiên cao hơn và sẽ gây ra xung đột. Có lẽ cô nghĩ về một trường hợp sử dụng không được phát hiện. Có thể một nhận xét đánh giá đã kích hoạt một động não cần điều tra thêm trước khi vấn đề được thỏa mãn hoàn toàn. Tác giả biết nhiều nhất về mã, và thật ý nghĩa khi đưa cho anh ấy hoặc cô ấy lời cuối cùng về khi nó được hợp nhất.

Về điểm thứ hai, đó chỉ là vấn đề của niềm tin. Nếu bạn không thể tin tưởng mọi người khắc phục các sự cố nhỏ mà không bị kiểm tra hai lần, họ sẽ không làm việc cho bạn. Nếu vấn đề đủ lớn để nó cần một đánh giá khác sau khi khắc phục, thì hãy tin tưởng các nhà đánh giá để yêu cầu một vấn đề.

Điều đó đang được nói, đôi khi tôi hợp nhất các yêu cầu kéo của tác giả khác, nhưng thường là những thay đổi rất đơn giản hoặc từ các nguồn bên ngoài, nơi cá nhân tôi chịu trách nhiệm cho việc che chở thông qua bất kỳ lỗi tự động thử nghiệm nào.

Có tác giả ban đầu hợp nhất yêu cầu kéo của riêng họ là quy trình làm việc ưa thích của tôi trong các nhóm nhỏ. Ngoài các lợi thế kỹ thuật đã được đề cập (ví dụ về việc giải quyết xung đột hợp nhất), tôi nghĩ rằng nó tăng thêm giá trị ở cấp độ văn hóa: Nó xây dựng ý thức về quyền sở hữu.

Tôi đã chỉ định tác giả ban đầu cho trường hợp (hiếm) khi một nhà phát triển khác sẽ thêm các cam kết vào yêu cầu kéo mở (kéo nhánh tính năng đang thực hiện và đẩy lùi nó). Điều này không xảy ra thường xuyên và sẽ dẫn đến một cuộc trò chuyện trực tiếp hoặc qua Slack: Những cam kết bổ sung này (bởi người khác) không nên đến đó một cách bất ngờ! Trong bối cảnh này, bởi tác giả ban đầu , tôi có nghĩa là người đã gửi yêu cầu kéo.

Trong tổ chức của tôi, chúng tôi khá mới mẻ trong các yêu cầu kéo và câu hỏi của bạn là một câu hỏi mà tôi đã tự suy ngẫm.

Một quan sát tôi muốn thêm: Trong một số công cụ (chúng tôi sử dụng TFS) có thể có một mục công việc liên quan đến yêu cầu kéo.

Nếu đó là trường hợp, nó trở thành một chút rắc rối để theo dõi khi người đánh giá thực hiện hợp nhất. Trong kịch bản đó, nhà phát triển sau đó phải xem lại PR, mở lỗi hoặc thay đổi yêu cầu và đánh dấu là 'đã giải quyết'. Nếu chúng tôi đánh dấu 'đã giải quyết' quá sớm, những người kiểm tra tin rằng bản sửa lỗi đã là một phần của bản dựng hiện tại.

TFS 2017 đã cải thiện việc họ thực hiện yêu cầu kéo. Bây giờ, nhà phát triển có thể yêu cầu Yêu cầu kéo tự động hợp nhất nếu tất cả các điều kiện được đáp ứng (không có xung đột hợp nhất, phê duyệt từ người đánh giá và không có bản dựng bị hỏng). YMMV.

Bằng cách này, tác giả có cơ hội thay đổi suy nghĩ về chi nhánh của mình, có thể anh ta đã tìm ra điều gì đó nên được thực hiện theo một cách khác và đưa các khoản phí bổ sung trở lại để xem xét.