Bạn và hầu hết những người trả lời tiếp cận vấn đề này như một vấn đề giao tiếp giữa hai đồng nghiệp, nhưng tôi thực sự không nghĩ vậy. Những gì bạn mô tả nghe có vẻ giống như một quy trình xem xét mã bị hỏng khủng khiếp hơn bất cứ điều gì khác.
Đầu tiên, bạn đề cập rằng đồng nghiệp của bạn là người chỉ huy thứ hai và dự kiến anh ta sẽ xem lại mã của bạn. Thật tồi tệ. Theo định nghĩa, đánh giá mã ngang hàng không phân cấp và chắc chắn chúng không chỉ là tìm lỗi. Họ cũng có thể cung cấp kinh nghiệm học tập (cho mọi người tham gia), một cơ hội để tương tác xã hội và chứng minh một công cụ có giá trị để xây dựng quyền sở hữu mã tập thể. Thỉnh thoảng bạn cũng nên xem lại mã của anh ấy, học hỏi từ anh ấy và sửa lỗi cho anh ấy khi anh ấy sai (không ai hiểu đúng mọi lúc).
Hơn nữa, bạn đề cập rằng đồng nghiệp của bạn thực hiện thay đổi ngay lập tức. Điều đó cũng sai, nhưng tất nhiên bạn đã biết điều đó; bạn sẽ không hỏi câu hỏi này nếu cách tiếp cận gung ho của anh ấy không phải là vấn đề. Tuy nhiên tôi nghĩ rằng bạn đang tìm kiếm một giải pháp không đúng chỗ. Thành thật mà nói, đồng nghiệp của bạn nhắc nhở tôi một chút về ... tôi, và điều làm việc cho tôi trong những tình huống tương tự là một quy trình đánh giá rõ ràng và vững chắc và một bộ công cụ tuyệt vời. Bạn không thực sự muốn ngăn đồng nghiệp xem lại mã của mình và yêu cầu anh ta dừng lại và nói chuyện với bạn trước khi mọi thay đổi nhỏ không thực sự có hiệu quả. Nó có thể, trong một thời gian, nhưng anh ấy sẽ sớm đạt đến một điểm mà nó sẽ trở nên quá khó chịu và bạn sẽ quay lại nơi bạn bắt đầu, hoặc tệ hơn: anh ấy sẽ ngừng xem lại mã của bạn.
Chìa khóa để giải quyết ở đây có thể là một công cụ đánh giá mã ngang hàng. Tôi thường tránh các đề xuất sản phẩm, nhưng để đánh giá mã Atlassian's Cruciblethực sự là một cứu tinh Những gì nó có vẻ rất đơn giản, và nó là, nhưng điều đó không có nghĩa là nó không tuyệt vời đáng kinh ngạc. Nó kết nối với kho lưu trữ của bạn và cung cấp cho bạn cơ hội để xem xét các thay đổi, tệp hoặc nhóm tệp riêng lẻ. Bạn không được thay đổi bất kỳ mã nào, thay vào đó bạn nhận xét về mọi thứ không hoàn toàn đúng. Và nếu bạn hoàn toàn phải thay đổi mã của người khác, bạn chỉ cần để lại nhận xét với bộ thay đổi giải thích các thay đổi của bạn. Video giới thiệu tại trang sản phẩm của Crucible rất đáng xem nếu bạn muốn biết thêm chi tiết. Giá của Crucible không dành cho tất cả mọi người, nhưng có rất nhiều công cụ đánh giá ngang hàng có sẵn miễn phí. Một người tôi đã làm việc cùng và rất thích là Hội đồng Đánh giá và tôi chắc chắn bạn sẽ tìm thấy nhiều người khác chỉ với một tìm kiếm Google đơn giản.
Dù bạn chọn công cụ nào, nó sẽ thay đổi hoàn toàn quy trình của bạn. Không cần dừng lại, rời khỏi ghế của bạn, ngắt lời người khác và thảo luận về những thay đổi; tất cả những gì bạn cần làm là dành thời gian nghỉ mỗi tuần và xem qua các bình luận (mỗi tuần một lần chỉ là một gợi ý. Bạn biết lịch trình và thói quen hàng ngày của mình tốt hơn tôi). Quan trọng hơn các đánh giá cốt lõi được lưu trữ trong cơ sở dữ liệu ở đâu đó và bạn có thể truy xuất chúng bất cứ lúc nào. Họ không thảo luận sôi nổi xung quanh máy làm mát nước. Trường hợp sử dụng yêu thích của tôi cho các đánh giá cũ là khi giới thiệu một thành viên nhóm mới cho cơ sở mã của chúng tôi. Thật tuyệt khi tôi có thể dẫn một người mới qua codebase chỉ ra chính xác nơi chúng tôi bị mắc kẹt, nơi chúng tôi có ý kiến khác nhau, v.v.
Tiếp tục, bạn đề cập rằng bạn không phải lúc nào cũng tìm thấy mã của đồng nghiệp này có thể đọc được. Điều đó cho tôi biết rằng bạn không có một bộ tiêu chuẩn mã hóa chung và đó là một điều tồi tệ. Một lần nữa bạn có thể tiếp cận vấn đề này như một vấn đề của mọi người hoặc bạn có thể tiếp cận vấn đề này như một vấn đề quy trình, và một lần nữa tôi sẽ đề nghị mạnh mẽ vấn đề sau. Kết hợp nhóm của bạn và áp dụng một phong cách mã hóa chung và thiết lập các tiêu chuẩn càng sớm càng tốt. Sẽ không có vấn đề gì nếu bạn chọn một bộ tiêu chuẩn phổ biến trong hệ sinh thái phát triển của bạn hoặc bạn tự đưa ra. Điều thực sự quan trọng là các tiêu chuẩn của bạn phải nhất quán và bạn tuân thủ chúng. Có rất nhiều công cụ có thể giúp bạn, nhưng đó là một cuộc thảo luận hoàn toàn khác. Chỉ để bạn bắt đầu, một điều rất đơn giản để làm là có một hook pre-commit chạy một số loại định dạng kiểu trên mã của bạn. Bạn có thể tiếp tục viết mã theo cách bạn muốn và để công cụ "sửa lỗi" tự động trước khi bất kỳ ai khác nhìn thấy mã đó.
Cuối cùng, bạn đề cập đến trong một bình luận rằng quản lý không tin rằng các nhánh dev riêng lẻ là cần thiết. Chà, có một lý do chúng tôi gọi chúng là "nhánh dev" chứ không phải "nhánh quản lý". Tôi sẽ dừng lại ở đây vì không có lý do gì để cơn thịnh nộ hình thành trong đầu tôi thoát ra.
Tất cả những gì đã nói, hãy biết rằng tôi không nghi ngờ đồng nghiệp của bạn là (một chút) có lỗi ở đây. Đó không phải là quan điểm của tôi, quan điểm của tôi là toàn bộ quá trình phát triển của bạn cũng có lỗi và đó là điều dễ khắc phục hơn. Trang bị cho mình các công cụ thích hợp, khám phá nhiều quy trình chính thức và không chính thức và chọn những quy trình phù hợp với nhóm của bạn. Bạn sẽ sớm đạt đến một điểm mà bạn sẽ nhận ra rằng hầu hết "vấn đề con người" của bạn không còn tồn tại nữa. Và xin đừng nghe bất cứ ai (kể cả chính bạn) đưa ra lý do "chúng tôi là một nhóm nhỏ, chúng tôi không cần tất cả những điều đó". Một nhóm các nhà phát triển có thẩm quyền có thể thiết lập các công cụ cần thiết trong vòng chưa đầy một tuần, tự động hóa mọi thứ có thể được tự động hóa và không bao giờ nhìn lại.
Tái bút "Quyền sở hữu mã" là một thuật ngữ mơ hồ, liên tục được tranh luận và nó có nghĩa là những điều khác nhau đối với những người khác nhau. Bạn có thể tìm thấy một bộ sưu tập tuyệt vời của hầu hết các ý kiến khác nhau (và đôi khi phản đối) về C2 .