Một lập trình viên có nên sửa lỗi xây dựng thất bại của người khác không? [đóng cửa]

Một lập trình viên đã cam kết một số công việc với kho SVN, sau đó về nhà. Sau khi anh ta rời đi, việc xây dựng tự động Hudson thất bại. Một lập trình viên khác đã thấy điều này và sau khi xem qua các thay đổi mã, đã phát hiện ra rằng vấn đề là sự vắng mặt của một thư viện. Ông đã thêm thư viện này vào SVN và bản dựng tiếp theo đã hoàn thành thành công.

Có phải lập trình viên thứ hai đã làm đúng hay anh ta chỉ nên đợi cho đến khi lập trình viên đầu tiên khắc phục vấn đề?

Nó phụ thuộc vào một mức độ nào đó vào cách nhóm của bạn thường làm việc, nhưng tôi sẽ nói rằng điều đó là tốt. Giữ cho công trình xây dựng tiết kiệm thời gian của mọi người.

Thật là lịch sự khi lập trình viên thứ hai bỏ email đầu tiên để giải thích những gì anh ta đã làm, chỉ trong trường hợp cần một phiên bản cụ thể của thư viện hoặc có một số phức tạp khác. Đó cũng là một cách tinh tế hơn một chút để chỉ ra rằng họ đã phá vỡ công trình.

Nó phụ thuộc.

• Là lỗi rõ ràng đến nỗi thêm một thư viện là cách để sửa nó? Đôi khi sửa chữa là trong việc tìm một cách giải quyết không cần thư viện đó.

• Là dự án trong một giai đoạn mà tất cả các thay đổi phải được liên kết với một vé hiện có? Nếu vậy, bạn đã nộp một vé? Vé đó đã được chỉ định cho bạn chưa?

Dù sao, tập trung vào sửa lỗi, không đổ lỗi cho người chịu trách nhiệm.

Vâng, không sao đâu. Tuy nhiên, thật không chuyên nghiệp khi lập trình viên ban đầu về nhà trước khi thử nghiệm bản dựng sẽ biên dịch.

Danh tiếng của bạn là 100% trong sự kiểm soát của bạn. Những thứ như thế này làm mờ danh tiếng của bạn và cố gắng đánh bóng danh tiếng bị mờ nhạt là rất khó.

Giao tiếp

Không có quy tắc nghiêm ngặt (bên cạnh quy tắc nhóm của riêng bạn) cho các kịch bản đó.

Dev2 có thể nói với dev1 rằng anh ta có thể sửa lỗi của mình, không ai trong số họ nên sợ điều gì đó từ việc trao đổi này, họ là một phần của một nhóm.

Tại sao không? Nếu sản phẩm của bạn quan trọng hơn sửa lỗi, chắc chắn là ổn. Mặc dù việc xây dựng thất bại vì thay đổi thư viện là khá khập khiễng và bạn cần khiển trách nhà phát triển vì đã không kiểm tra nó.

Xây dựng thất bại xảy ra. Nếu điều quan trọng là việc xây dựng hàng ngày xảy ra thì tôi sẽ sửa nó và sau đó yêu cầu nhà phát triển đã kiểm tra mã bị hỏng để xem xét sửa lỗi vào ngày hôm sau và đảm bảo rằng mã hiện tại như hiện tại.

Như đã nói, anh chàng đã sửa nó có lẽ nên gửi email cho anh chàng đã phá vỡ nó và chi tiết cách khắc phục.

Phương châm của tôi là không cam kết với SVN sau 3 giờ chiều theo cách đó bạn luôn có thể khắc phục các lỗi xây dựng của chính mình.

Nếu bạn không khắc phục lỗi xây dựng của anh ấy / cô ấy, thì bản dựng của mọi người khác cũng sẽ thất bại. Tôi sẽ sửa nó để tiết kiệm thời gian trong thời gian dài, nhưng hãy chắc chắn rằng họ biết rằng bạn phải sửa nó.

Có một số loại kịch bản 'chỉ tay vào đổ lỗi' là một cách tốt để làm điều này, hoặc làm cho người phá vỡ xây dựng mua bánh rán !!

Ai đó cần sửa nó và lập trình viên đầu tiên không nên về nhà mà không đảm bảo rằng anh ta đã không phá vỡ bản dựng. Tuy nhiên, đối với một vấn đề dễ dàng khắc phục như vậy, việc gọi lại cho anh ta để tự khắc phục nó sẽ là cực kỳ.

Tôi đồng ý với đề nghị của Luke Graham về việc gửi e-mail giải thích, mặc dù tôi muốn nói rằng nó còn hơn cả lịch sự - đó là giao tiếp cơ bản.

Có có có! Nó thúc đẩy quyền sở hữu mã tập thể và tạo ra một loại áp lực ngang hàng lành mạnh trong nhóm để giữ tiêu chuẩn cao và không để kịch bản cửa sổ bị phá vỡ phát triển. Một chút giao tiếp để cho các nhà phát triển khác biết là một ý tưởng tốt.

Tôi nghĩ rằng sẽ ổn khi sửa những thứ rõ ràng - tức là, nếu bạn chắc chắn 100% thì anh chàng có mã bạn đang sửa sẽ làm như vậy - hoặc thực chất là giống nhau - sửa. Nếu cách khắc phục phức tạp hơn, thường là lịch sự khi nói chuyện với người có mã bạn đang sửa - có thể là bạn đã hiểu sai ý định hoặc lý do phá vỡ không phải là điều bạn nghĩ, hoặc có thể anh ta có ý định sửa khác nhưng vì một số lý do không thể cam kết ngay bây giờ (cuộc sống xảy ra, bạn biết đấy :).

Nói chung, quy tắc thường là: bạn phá vỡ bản dựng - bạn sửa bản dựng, nhưng vẫn có trường hợp ngoại lệ, đặc biệt nếu bản sửa lỗi rõ ràng và / hoặc người chịu trách nhiệm không thể truy cập được.

Tất nhiên, nếu bạn gặp trường hợp bộ ngắt xây dựng nối tiếp - đặc biệt với mẫu "đã đăng ký, về nhà, xây dựng bị hỏng trong nhiều ngày" - người có trách nhiệm cần nói chuyện về lý do tại sao các hệ thống và kiểm tra CI tồn tại và làm thế nào để kiểm tra kiểm tra trước khi đăng ký :)

Sự việc xảy ra. Việc không thêm tệp mã mới (dù là nguồn hoặc được biên dịch) vào Subversion có lẽ là nguyên nhân phổ biến nhất của các bản dựng bị hỏng, giả sử nó hoạt động trên máy tính của nhà phát triển. Ở công việc cuối cùng của tôi với môi trường CI, ngay cả những người cao cấp nhất đôi khi cũng quên mất.

Tôi nghĩ rằng, nếu một người khác có thể sửa chữa bản dựng và do đó giữ cho nhóm hoạt động tốt, điều đó tốt. Tôi nghĩ rằng lập trình viên về nhà cần ít nhất một e-mail thân thiện nêu rõ những gì đã xảy ra và để nhắc nhở anh ta đảm bảo rằng mã mới được thêm vào trước khi cam kết. Nếu điều đó xảy ra thường xuyên, có thể khiến cho một hành vi phạm tội nhỏ bị trừng phạt bằng "vũ điệu xấu hổ", để giúp giảm bớt sự xuất hiện (và làm nhẹ tâm trạng).

Nó phụ thuộc vào tính năng động của Nhóm, nhưng trong một thế giới lý tưởng, mọi người trong Nhóm sẽ "sở hữu" toàn bộ dự án, tất cả các mã, và do đó, tất cả các lỗi cùng nhau. Vì vậy, nếu bạn tìm thấy một vấn đề bạn khắc phục nó và chỉ liên lạc với người khởi tạo lỗi nếu có một số giá trị gia tăng cụ thể cho mã khi thực hiện.

Bạn có thể sửa chữa trừ khi đây là một sự cố thường xuyên trong trường hợp tôi sẽ nhờ sếp gọi cho anh ta và khiến anh ta quay lại và tự sửa nó.

Nó phụ thuộc, nó phụ thuộc ...

Là lập trình viên, công việc của chúng tôi là để mọi thứ hoạt động chứ không phải đánh giá con người. Vì vậy, tôi muốn nói rằng điều tốt nhất bạn có thể làm là sửa nó, hoặc nếu nó không rõ ràng, chỉ cần khôi phục các thay đổi và cho lập trình viên đầu tiên biết để anh ta có thể sửa nó sau.

Dù sao, có anh chàng mới nhất phá vỡ bản dựng để đội một chiếc mũ kỳ lạ là đủ để chú ý nhiều hơn vào lần tới ^ _ ^

Trong một số môi trường, điều này rất thô lỗ, và vì lý do tốt. Trong các môi trường khác, nó được mong đợi, và vì lý do tốt.

Trong các môi trường khác, nó rất thô lỗ hoặc được mong đợi vì những lý do rất xấu.

Nó chủ yếu phụ thuộc vào mức độ quan trọng của một bản dựng bị hỏng so với mức độ quan trọng của một bản dựng chính xác được xác minh. Và ở một mức độ nào đó, nó phụ thuộc vào mức độ rõ ràng rằng bản sửa lỗi là bản sửa lỗi phù hợp và là thứ duy nhất cần thiết.

Đầu tiên, "về nhà" là lỗi thời. Các lập trình viên không về nhà nữa - họ chỉ trực tuyến hoặc ngoại tuyến. Bạn có thể ping và chờ đợi.

Nghiêm trọng hơn, thực sự có hai phần của câu hỏi. "Xem qua các thay đổi mã" là tốt; Nghỉ ngơi có thể không phải là điều đúng đắn. Điều gì nếu phán đoán của ông về một thư viện mất tích là sai?