Là cam kết / kiểm tra mã hàng ngày là một thực hành tốt?

Tôi đã đọc ghi chú của Martin Fowler về Tích hợp liên tục và anh ấy liệt kê là phải "Mọi người cam kết chính tuyến mỗi ngày".

Tôi không muốn cam kết mã trừ khi phần tôi đang làm việc hoàn tất và trong thực tế, tôi cam kết mã của mình cứ sau ba ngày: một ngày để điều tra / tái tạo nhiệm vụ và thực hiện một số thay đổi sơ bộ, ngày thứ hai để hoàn thành các thay đổi và ngày thứ ba để viết bài kiểm tra và dọn dẹp ^ để nộp. Tôi sẽ không cảm thấy thoải mái khi gửi mã sớm hơn.

Bây giờ, tôi lấy các thay đổi từ kho lưu trữ và tích hợp chúng cục bộ thường hai lần một ngày, nhưng tôi không cam kết điều đó thường xuyên trừ khi tôi có thể tạo ra một công việc nhỏ hơn.

Câu hỏi: việc cam kết mỗi ngày là một cách thực hành tốt đến mức tôi nên thay đổi quy trình làm việc của mình để điều chỉnh nó, hay nó không được khuyến khích?

Chỉnh sửa: Tôi đoán tôi nên đã làm rõ rằng tôi có nghĩa là "cam kết" theo nghĩa CVS của nó (hay còn gọi là "đẩy") vì đó có thể là ý nghĩa của Fowler vào năm 2006 khi ông viết điều này.

^ Thứ tự tùy ý hơn và phụ thuộc vào nhiệm vụ, quan điểm của tôi là minh họa khoảng thời gian và hoạt động, chứ không phải trình tự chính xác.

Tôi không đồng ý với quy tắc này và tôi đồng ý với những gì Mason Wheeler nói. Tôi muốn thêm một vài ý tưởng.

Tôi cố gắng cam kết mỗi khi tôi có một thay đổi có ý nghĩa để cam kết: điều này có thể là vài lần một ngày nếu tôi sửa một vài lỗi nhỏ hoặc mỗi tuần một lần nếu tôi đang làm việc trên một phần mềm lớn hơn mà phần còn lại không thể sử dụng mã theo bất kỳ cách có ý nghĩa cho đến khi nó đạt đến một trạng thái nhất quán.

Ngoài ra, tôi giải thích cam kết là xuất bản một bản sửa đổi có ý nghĩa đóng góp chức năng mới cho cơ sở mã. Tôi nghĩ rằng người ta nên cố gắng làm sạch mã trước khi cam kết để các nhà phát triển khác có thể hiểu ý nghĩa và mục đích của thay đổi khi họ nhìn vào lịch sử sửa đổi. Càng ít thay đổi mà các nhà phát triển khác thấy trong lịch sử thì càng tốt: khi tôi nhìn vào lịch sử sửa đổi, tôi muốn thấy các mức tăng thêm một số chức năng có ý nghĩa; Tôi không quan tâm đến mọi ý tưởng nhỏ mà mỗi nhà phát triển đã có và muốn thử trước khi họ đạt được giải pháp.

Hơn nữa, tôi không nghĩ nên sử dụng máy chủ SVN (hoặc bất kỳ hệ thống kiểm soát phiên bản nào) làm phương tiện dự phòng mà ảnh chụp nhanh mã hiện tại được cam kết (với điều kiện là nó biên dịch): bạn có thể sử dụng thẻ USB hoặc ổ đĩa USB ngoài hoặc ổ đĩa mạng để phản chiếu mã hiện tại của bạn để nó không bị mất nếu máy tính của bạn bị hỏng. Kiểm soát sửa đổi và sao lưu dữ liệu là hai điều khác nhau. Xuất bản bản sửa đổi không giống như lưu ảnh chụp nhanh mã của bạn.

Cuối cùng, tôi nghĩ rằng không nên là một vấn đề để cam kết mọi lúc và sau đó (tức là chỉ khi một người thực sự hài lòng với trạng thái hiện tại của mã) và tránh xung đột hợp nhất không phải là một lý do tốt để cam kết (quá) thường xuyên. Nhiều xung đột hợp nhất xảy ra khi những người khác nhau làm việc trên cùng một tệp cùng một lúc, đó là một thực tiễn xấu (xem ví dụ bài viết này , điểm 7). Hợp nhất các xung đột nên được giảm bớt bằng cách chia một dự án thành các mô-đun với giao diện rõ ràng và càng ít phụ thuộc càng tốt, và bằng cách phối hợp công việc của các nhà phát triển để mã mà họ làm việc chồng chéo ít nhất có thể.

Chỉ 2 xu của tôi.

BIÊN TẬP

Một lý do khác chống lại các cam kết sớm xuất hiện trong đầu tôi là một phiên bản lỗi (rất) không thể được kiểm tra. Nếu bạn đang cam kết trên thân cây và nhóm thử nghiệm của bạn đang thử nghiệm mỗi ngày, họ có thể không có phiên bản thử nghiệm nào trong vài giờ (hoặc trong một ngày). Ngay cả khi bạn không cố gắng sửa lỗi và chỉ hoàn nguyên các thay đổi của mình, việc xây dựng lại có thể mất một vài giờ. Với, giả sử, năm người thử nghiệm làm việc trong nhóm của bạn, bạn đã lãng phí 5 x 2 = 10 giờ thời gian của nhóm do không hoạt động. Nó đã xảy ra với tôi một lần vì vậy tôi thực sự cố gắng tránh các cam kết sớm trong tên của cam kết càng sớm càng tốt .

Tôi cam kết mã nhiều lần trong ngày . Bất cứ khi nào tôi đạt đến điểm mà mã hoàn thành đủ để biên dịch và không phá vỡ những thứ khác, nó sẽ đi vào.

Bạn nên xem xét việc chia nhỏ công việc để có thể kiểm tra một cách an toàn một vài lần một ngày.

Các lý do cho điều này là hai:

1. Bất kỳ công việc nào không được kiểm tra có thể bị mất - máy tính của bạn có thể bị lỗi nghiêm trọng. Trong trường hợp này, bạn càng chờ đợi lâu, bạn càng mất nhiều công việc.
2. Bạn càng làm nhiều việc mà không cần đăng nhập, càng nhiều mã người khác sẽ cần tích hợp khi cuối cùng bạn quyết định rằng nó sẽ ra. Điều này giới thiệu nhiều cơ hội xung đột và hợp nhất các vấn đề.

Nghiêm túc tuân thủ bất kỳ phương pháp hoặc thực hành nào mà không hiểu lý do đằng sau nó không bao giờ là một ý tưởng tốt. Đó là nơi lập trình sùng bái hàng hóa đến từ.

Do đó, "Tôi nên cam kết mỗi ngày vì Martin Fowler đã nói như vậy" chỉ là ngu ngốc. Và đôi khi nó cũng không thực tế. Nếu bạn đang làm việc trên một tính năng mới phức tạp, bạn có thể không đạt đến điểm đáng để kiểm tra cho đến khi bạn đã làm việc với nó trong vài ngày.

Điều này không có nghĩa là bạn nên đảm bảo mọi thứ đều hoàn hảo trước khi kiểm tra. Đó là cách tốt để mất việc nếu có sự cố xảy ra. Điều đúng đắn cần làm là phát triển và sử dụng phán đoán tốt về vấn đề này. Quy tắc của ngón tay cái chỉ có thể giúp bạn rất nhiều.

Oded đã đưa ra hai lý do quan trọng để cam kết mã thường xuyên nhất có thể. Tôi sẽ thêm một vài điều nữa:

1. Trong khi làm việc với đoạn mã của bạn, người khác có thể cần một số chức năng trên mã đó. Họ không nên đợi 6 ngày để có được nó. Trong trường hợp này, các đồng nghiệp của tôi thường tạo một nguyên mẫu trong đoạn mã của tôi, cam kết nó, tôi thêm phần thân và cam kết lại. Và điều này thường được thực hiện trong một vài giờ.

2. Mã 'chung' dành cho mọi người để xem mọi thay đổi càng sớm càng tốt. Nếu đoạn mã bạn đang làm việc hoàn toàn tách biệt với công việc của người khác và bạn sẽ không phải chờ họ, thì bạn nên tạo một nhánh để bạn làm việc, và sau đó, nếu mọi thứ thành công, hãy hợp nhất nó với đường dây chính

Tôi là một người tin tưởng mạnh mẽ vào việc cam kết mọi thay đổi hợp lý đáng để giữ. Cam kết thường xuyên và nếu mã không đáng để giữ, hãy hoàn nguyên mã về trạng thái sạch. Bạn càng chờ đợi lâu để đẩy / xuất bản mã của mình trở lại, thì càng khó thực hiện và càng gặp nhiều vấn đề hơn. Bạn cũng sẽ nhận được phản hồi về đóng góp của mình nhanh hơn rất nhiều:

• họ có phá vỡ công trình không?
• bạn đang nhân đôi nỗ lực của một thành viên khác trong nhóm?
• bạn đang làm gì đó không đúng?
• hoặc mọi người đang chờ đợi những thứ từ bạn?

Những thay đổi nhỏ dễ quản lý hơn rất nhiều.

Ngoài ra, đáng chú ý sự khác biệt giữa các hệ thống kiểm soát phiên bản khác nhau. Một số, chẳng hạn như Git (phân phối), sẽ cho phép bạn cam kết và kiểm soát toàn bộ lịch sử của mình cục bộ, chỉ đẩy khi bạn sẵn sàng xuất bản. Những người khác, như SVN (tập trung), sẽ kết hợp hai bước làm cho các cam kết nhỏ rất không hiệu quả.

Đừng quên rằng các cam kết của bạn về cơ bản là thay đổi tài liệu. Khi mọi thứ đi sai, bạn sẽ vui mừng khi có nhiều lịch sử hơn là không đủ. Một cam kết duy nhất cho một tuần làm việc dường như vô dụng đối với tôi. Cuối cùng tôi chỉ đọc từng dòng mã được thay đổi thay vì tóm tắt từng đoạn logic.

Tôi nghĩ rằng hầu hết các câu trả lời ở đây đều bỏ lỡ một trong những điểm chính trong tuyên bố của Martin Fowlers. Điều này có liên quan đến Tích hợp liên tục . Mã không được kiểm tra (đẩy / xuất bản / sáp nhập) vào dòng chính không được kiểm tra.

Điều này không nên được đọc như một sự khuyến khích để cam kết bất kỳ mã nào bạn có trong máy cục bộ của mình bất cứ khi nào rời khỏi văn phòng. Như được chỉ ra bởi một số người khác ở đây sẽ là xấu, sẽ phá vỡ công trình và gây ra một tuyến chính không ổn định.

Tuy nhiên, thật đáng khích lệ khi cố gắng thực hiện các thay đổi của bạn trong các bước nhỏ có thể được kiểm tra vào tuyến chính mà không gây ra sự cố. Điều này khuyến khích sự phát triển của mã thay vì tách nó ra và viết lại.

Bây giờ, những gì tốt về cách làm việc này?

1. Không cam kết các đoạn mã lớn hoặc thay đổi mang tính cách mạng làm giảm cơ hội phá vỡ bản dựng.
2. Nếu cam kết của bạn phá vỡ bản dựng, việc xác định vấn đề là gì khá đơn giản, để hoàn nguyên nó và sau đó cam kết một phiên bản cố định một cách nhanh chóng.
3. Bằng cách đảm bảo tất cả các thử nghiệm chạy trên mỗi thay đổi nhỏ trong mã, bạn đảm bảo rằng bạn không đưa ra các lỗi hoặc hồi quy tinh vi có thể xuất phát từ việc có mã phát triển bên ngoài sơ đồ tích hợp liên tục.

Tất nhiên không phải tất cả các thay đổi đều cho vay theo cách tiếp cận này. Như những người khác chỉ ra, không có quy tắc là tuyệt đối. Tuy nhiên, đối với những thay đổi được dự kiến ​​sẽ nằm ngoài tuyến chính trong một thời gian dài, hãy thiết lập một tuyến chính thay thế với sơ đồ tích hợp liên tục của riêng nó và thực hiện theo cách tiếp cận tương tự đối với nó. Với các VCS phân tán ngày nay, đó là một điều khá dễ thực hiện.

Đối số để kiểm tra mỗi ngày:

• Mã được lưu trữ và sao lưu chống lại lỗi ổ cứng
• Hoạt động có thể được ghi lại trong ghi chú cam kết ( tôi đã làm gì vào thứ năm ...? )
• Tích hợp với cơ sở mã hiện tại xảy ra sớm hơn và trong các phần nhỏ hơn, hy vọng xác định các xung đột hoặc hợp nhất các vấn đề sớm hơn
• Nhóm của bạn có tầm nhìn về những gì bạn đang làm việc trên
• Các đồng nghiệp của bạn có thể làm việc với các giao diện của bạn sớm hơn, cho họ nhiều thời gian hơn để tích hợp với 'mã phức tạp lớn' của bạn
• Mã của bạn sẽ được kiểm tra trong thế giới thực sớm hơn hoặc ít nhất là tiếp xúc với việc sử dụng nhiều hơn số tiền bạn cung cấp, dẫn đến việc xác định sớm hơn các lỗi hoặc thiếu sót.

Đối số chống lại việc kiểm tra mỗi ngày:

• Không cần hoặc không muốn
• Chưa 'dọn dẹp' mã của tôi, đó là một mớ hỗn độn
• Không có thời gian

Tôi không tin có bất kỳ lý do chính đáng nào để kiểm tra ít hơn hàng ngày ngoài sự lười biếng hoặc vô tổ chức. Không có gì tệ hơn là thấy mã đang chạy trong môi trường phát triển không khớp với mã trong nhánh phát triển vì ai đó 'chưa kết thúc' và do đó chưa đăng ký.

Tôi rất muốn sai về điều này vì vậy xin vui lòng cho tôi biết bất kỳ lý lẽ hợp pháp nào chống lại việc đăng ký hàng ngày.

Nếu bạn có nghĩa là "cam kết" là "hợp nhất vào dòng chính", thì bạn chắc chắn không nên làm điều đó hàng ngày trên một dự án phần mềm được phát hành cho khách hàng. Bạn nên hợp nhất các thay đổi đã được thực hiện và thử nghiệm để tuyến chính luôn hoạt động và có thể giải phóng được, và không ở trạng thái bị hỏng với các tính năng đã hoàn thành một nửa.

Tuy nhiên, điều thú vị khi làm việc với kiểm soát phiên bản phân tán ngày nay là bạn có thể giữ ổn định tuyến chính, đồng thời làm git/hg/whatever commitmọi lúc bạn cảm thấy muốn duy trì trạng thái của mọi thứ. Tôi làm điều này một lần một vài giờ và chắc chắn vào cuối mỗi ngày.

Với DVCS, bạn có thể xuất bản tác phẩm của mình, cộng tác với những người khác trong nhóm của bạn và cập nhật nó với những thay đổi trong nhánh chính. Bạn có thể làm tất cả điều này mà không làm ô nhiễm sự ổn định của mã khách hàng của bạn và / hoặc các nhóm khác phụ thuộc vào.

Trong thời đại, Subversion là công nghệ mới nhất và không có cách nào để rẽ nhánh và hợp nhất các nhánh tính năng mà không quá đau đớn, có một tuyến chính trong đó một số tính năng khác nhau được xây dựng đồng thời có thể là cách tiếp cận tốt nhất. Nhưng sự vượt trội này không vượt quá năm 2010.

Trong Team Foundation Server, bạn có thể 'Kệ' không giống như đăng ký, nhưng chỉ cần sao lưu mã của bạn để nếu máy của bạn chết, bạn sẽ không bị mất các thay đổi.

Tôi cũng đã thấy các nhà phần mềm có 'dòng nhà phát triển' và 'dòng chính'. Các nhà phát triển có thể tự do đăng ký vào dòng nhà phát triển bất cứ khi nào họ thấy phù hợp và chỉ có trưởng nhóm mới có quyền truy cập vào tuyến chính để họ có trách nhiệm sao chép mã từ dev sang main khi sản phẩm sẵn sàng.