Khi nào cam kết mã?

Khi làm việc trên một dự án, mã có thể được phát triển hợp lý nhanh chóng trong một ngày hoặc từng chút một trong thời gian kéo dài vài tuần / tháng / năm. Vì các cam kết mã đang trở nên được coi là một biện pháp phát triển dự án, điều đó không thực sự có nghĩa là nó có nhiều mã được viết hơn một dự án có ít cam kết hơn.

Vì vậy, câu hỏi là khi nào thực sự thực hiện một cam kết với kho lưu trữ để cam kết là chính đáng?

Là một tiện ích bổ sung: Đây có phải là một cách thực hành chính xác để đo lường sự phát triển của dự án dựa trên các cam kết của nó không?

Bạn cam kết khi bạn đã đạt đến trạng thái cơ sở mã bạn muốn ghi nhớ. Có rất nhiều lý do tại sao bạn có thể muốn nhớ một trạng thái cơ sở mã cụ thể, vì vậy không thể có các quy tắc khó và nhanh về thời điểm cam kết. Tuy nhiên, số lượng cam kết chắc chắn không phải là thước đo chất lượng hoặc tiến độ.

Tôi thích nghĩ về tiền mã hóa như leo núi trong bối cảnh này. Bạn leo lên một chút, và sau đó bạn đặt một cái neo vào đá. Nếu bạn từng ngã, mỏ neo cuối cùng bạn trồng là điểm bảo vệ bạn, vì vậy bạn sẽ không bao giờ rơi quá vài mét. Tương tự với kiểm soát nguồn; bạn viết mã một chút và khi bạn đạt đến một vị trí hơi ổn định, bạn cam kết sửa đổi. Nếu bạn thất bại khủng khiếp, bạn luôn có thể quay lại bản sửa đổi cuối cùng đó và bạn biết nó ổn định.

Điều đó nói rằng, nếu bạn làm việc trong một nhóm, theo thông lệ, hãy đảm bảo mọi thứ bạn cam kết đã hoàn thành, có ý nghĩa, xây dựng sạch sẽ và không phá vỡ nội dung của bất kỳ ai khác. Nếu bạn cần thực hiện các thay đổi lớn hơn có thể ảnh hưởng đến công việc của người khác, hãy tạo một chi nhánh để bạn có thể cam kết mà không làm phiền bất kỳ ai khác.

Nó cũng phụ thuộc vào hệ thống SCM bạn đang sử dụng. Các hệ thống phân tán thường làm cho việc hợp nhất và chuyển đổi không đau đớn và nhanh chóng, và bạn có thể cam kết cục bộ; điều này có nghĩa là bạn nên cam kết nhiều và đẩy / hợp nhất khi bạn đã hoàn thành một khối lượng công việc đáng kể. Với các hệ thống tập trung như svn hoặc cvs, việc cam kết sẽ tốn kém hơn và nó ảnh hưởng đến tất cả mọi người. Việc phân nhánh một phần giải quyết vấn đề này, nhưng vì nó xảy ra trên máy chủ, nên nó có thể bị chậm một cách khó khăn và việc hợp nhất có thể trở nên cồng kềnh. Vì vậy, với SCM tập trung, thường có một nền văn hóa cẩn thận hơn, nơi bạn chỉ cam kết một khi bạn đã hoàn thành một lượng công việc đáng kể.

Về phần bổ trợ: Xin vui lòng, đừng làm vậy. Các dòng mã, số lần xác nhận, số lỗi được tìm thấy / giải quyết, v.v., đều là các phép đo rất tệ về chất lượng hoặc thậm chí số lượng.

Nếu bạn đang sử dụng DVCS như Mercurial hoặc Git, bạn nên cam kết với kho lưu trữ cục bộ của mình bất cứ khi nào bạn hoàn thành khối lượng công việc đáng kể. Tuy nhiên, chỉ đẩy nó vào kho lưu trữ được chia sẻ chỉ sau khi nó hoạt động, thay đổi độc lập đã được thử nghiệm.

Đối với các VCS không phân tán (ví dụ: SVN) áp dụng logic tương tự, thay vì kho lưu trữ cục bộ sử dụng nhánh riêng, thay vì đẩy - hợp nhất vào nhánh chính.

Bạn nên cam kết sớm và thường xuyên.

Tôi biết những người cam kết thường xuyên cứ sau 90 giây. Nghiêm túc. Nó dường như làm việc cho họ. Tôi đã thử nghiệm cam kết mỗi lần tôi lưu một tệp, có lẽ thường xuyên hơn 90 giây. Hôm nay, tôi có thể cam kết cứ sau 15 phút. Một VCS cho phép bạn nén nhiều xác nhận thành một và cho phép các xác nhận cục bộ (như git) làm cho việc này dễ dàng hơn nhiều.

Bao lâu bạn nên cam kết? Khó nói, nhưng có lẽ thường xuyên hơn bạn bây giờ. Tiếp tục cam kết ngày càng thường xuyên hơn, tìm một điểm cảm thấy như nó quá vô lý quá thường xuyên, và sau đó lùi lại một chút. Rất có thể bạn sẽ kết thúc với một cái gì đó hợp lý.

Bạn đo lường sự phát triển của sản phẩm dựa trên giá trị được phân phối cho người dùng. Không có phép đo chính xác khác.

Cam kết là các khối xây dựng của bất kỳ phiên bản dữ liệu / mã nào được kiểm soát. Mỗi cam kết nên thực hiện chính xác một trong những điều sau đây:

• Thêm một phần dữ liệu hoặc chức năng mới
• Khắc phục một hoặc nhiều lỗi (một cam kết cho mỗi sửa chữa nếu có thể) trong đó sửa lỗi có thể là:
  • Cải thiện hiệu suất
  • Sửa lỗi hành vi mã sai
  • Xóa lỗi đánh máy
• Tái cấu trúc mã hoặc dữ liệu mà không thay đổi ngữ nghĩa. Điêu nay bao gôm:
  • Viết lại mã hoạt động giống hệt với bản gốc
  • Thay đổi cách trình bày dữ liệu sang định dạng khác
  • Định dạng mã hoặc dữ liệu để đáp ứng các nguyên tắc định dạng của dự án
• Hợp nhất các thay đổi từ một nhánh khác (ngược dòng / hạ lưu)

Ngoài ra khi làm việc trong các chi nhánh, các cam kết phải đến một chi nhánh có nhiều khả năng hơn. Hai cam kết không nên có cùng một thông điệp cam kết (ngụ ý những thay đổi tương tự) nhưng trong các nhánh khác nhau vì nó gây nhầm lẫn cho các cộng tác viên. Một cách tốt hơn là cam kết với nhánh chính và hợp nhất với nhánh tính năng.

Nếu các ủy viên tuân theo quy tắc trên, nó trở nên tầm thường đối với:

• Hoàn nguyên một thay đổi cụ thể mà không có tác dụng phụ
• Xác định thay đổi hành vi thay đổi mã từ thay đổi định dạng mã
• Hợp nhất giữa các nhánh khác nhau để tránh hầu hết các xung đột
• Phối hợp với các nhà phát triển khác, những người có thể giúp bạn thay đổi dễ dàng

Về việc đo lường tiến độ của dự án dựa trên các cam kết, có thể nếu các cam kết Tái cấu trúc và các cam kết sửa lỗi không được tính đến.

Chỉ cam kết khi bạn đã kiểm tra đơn vị thành công chức năng / mô-đun / chức năng nhất định và bạn hoàn toàn yên tâm rằng nó đã sẵn sàng để tích hợp hoặc kiểm tra hệ thống.

Và để trả lời các câu hỏi bổ trợ của bạn - KHÔNG !! thước đo nơi dự án không bao giờ được xác định bởi số lượng cam kết ... ai biết những gì đã thực sự được cam kết? Nó đã được thử nghiệm thành công hệ thống hoặc thậm chí đơn vị thử nghiệm. Chỉ vì nó được cam kết - không có nghĩa là nó đã sẵn sàng sản xuất.

Là một tiện ích bổ sung: Đây có phải là một cách thực hành chính xác để đo lường sự phát triển của dự án dựa trên các cam kết của nó không?

Không. Có một WTF hàng ngày về lý do tại sao đó là một ý tưởng khủng khiếp.

Nguyên tắc chung của tôi về việc cam kết mã là kiểm tra khi tôi đã hoàn thành một đoạn mã và nó biên dịch. Chunk không thực sự được xác định. Nếu đó là một nhiệm vụ nhỏ, tôi có thể không đăng ký cho đến khi tôi hoàn thành nó. Nếu nó lớn hơn, tôi có thể kiểm tra sau khi từng phần logic được hoàn thành.

Nhưng không bao giờ kiểm tra nếu nó không biên dịch. Tôi biết có vẻ như thật ngu ngốc khi thực sự nói to, nhưng tôi đã phải giải thích nó với mọi người trước đây.

Thực hiện cam kết khi mã sẵn sàng được chia sẻ với những người dùng mã khác - khi nó tương đối ổn định, an toàn và được kiểm tra đúng cách.

Và không, tôi không nghĩ rằng các cam kết là một thước đo tuyệt vời cho sự phát triển của dự án, bởi vì tôi biết một số nhà phát triển sẽ cam kết mọi thay đổi nhỏ và nhỏ, và những người khác sẽ chỉ cam kết những thay đổi lớn đối với chức năng. Làm thế nào để bạn đo lường một cách định lượng giá trị của một cam kết so với một cam kết khác?

Ngay khi nhiệm vụ tương ứng được thực hiện . Một nhiệm vụ là một phần của câu chuyện người dùng .

Một nhiệm vụ được thực hiện khi:

• các bài kiểm tra đơn vị tương ứng,
• mã được ghi lại đúng cách và
• mã được cam kết.

Bạn có thể có một định nghĩa khác về thực hiện .

Tôi không thấy giá trị trong việc đo lường số lần xác nhận. Tuy nhiên, nếu bạn thấy ai đó làm việc trong một thời gian dài trên cùng một câu chuyện của người dùng (hoặc tệ hơn là các câu chuyện), thì đây là một mùi.

Cam kết mọi thay đổi đáng kể mà bạn không nghĩ sẽ phá vỡ một cái gì đó. Điều duy nhất bạn không nên cam kết là thay đổi phong cách vì chúng không thể hiện sự thay đổi trong logic. Nhưng nếu không, những thay đổi bạn cam kết càng nhỏ càng tốt.

Các cam kết càng nhỏ, bạn càng có thể ghi lại quá trình suy nghĩ chi tiết, đó là một khía cạnh của nhật ký cam kết tốt. Một đánh giá mã tốt không chỉ là về kết quả mã mà còn là quá trình suy nghĩ.

Ngoài ra, việc có nhiều cam kết nhỏ giúp dễ dàng chia đôi, một cách sử dụng quá ít tính năng kiểm soát phiên bản, một cách giúp tôi tiết kiệm nhiều giờ để tìm lỗi kim trong các cơ sở mã hóa.

Nói ngắn gọn; Khám phá một vấn đề trong codebase hiện tại. Sau đó, chọn một cam kết trong danh sách thay đổi nơi bạn chắc chắn rằng vấn đề cụ thể không tồn tại. Bắt đầu với việc kiểm tra cam kết ngay giữa phiên bản "tốt" và "xấu". Kiểm tra để xem nếu vấn đề vẫn còn. Nếu đúng như vậy, bạn cần nhìn lại, ở giữa "tốt" và cam kết đã được thử nghiệm trước đó. Nếu vấn đề không còn nữa, nó đã được đưa ra sau khi thay đổi cụ thể này, vì vậy bạn cần kiểm tra giữa "xấu" và cam kết đã được thử nghiệm trước đó. Nói lại. Cuối cùng, bạn sẽ kết thúc với cam kết đưa ra vấn đề. Nhưng chỉ khi bạn có những cam kết nhỏ, nếu không bạn sẽ chỉ biết trong đó có nhiều thay đổi lớn mà vấn đề đã tồn tại.

Đây là cách nó hoạt động với Git nhưng hiệu trưởng áp dụng cho mọi điều khiển phiên bản.

Khi nào:

• nó xây dựng (LUÔN)
• bài kiểm tra đơn vị vượt qua
• nó hoạt động (trừ khi nó được đánh dấu rõ ràng là "công việc đang tiến hành")
• lợi ích của việc lưu trạng thái của mã vượt quá rắc rối khi chạy thử nghiệm, nghĩ đến một thông điệp cam kết tốt và giải quyết bất kỳ xung đột hợp nhất nào trong quá trình cam kết