Đôi khi, khi chúng tôi kiểm tra lịch sử cam kết của một phần mềm, chúng tôi có thể thấy rằng có một vài cam kết thực sự LỚN - họ có thể thay đổi 10 hoặc 20 tệp với hàng trăm dòng mã nguồn đã thay đổi (delta). Tôi nhớ rằng có một thuật ngữ thường được sử dụng cho cam kết LỚN như vậy nhưng tôi không thể nhớ chính xác thuật ngữ đó là gì. Ai giúp tôi với? Thuật ngữ mà các lập trình viên thường sử dụng để nói về cam kết LỚN và khổng lồ như vậy là gì?

BTW, có cam kết nhiều thay đổi cùng nhau là một thực tiễn tốt?

CẬP NHẬT: cảm ơn các bạn đã thảo luận đầy cảm hứng! Nhưng tôi nghĩ "bom mã" là thuật ngữ mà tôi đang tìm kiếm.

(1) Ben Collins-Sussman : "..." bom mã ". Đó là, bạn sẽ làm gì khi ai đó xuất hiện trong một dự án nguồn mở với một tính năng mới khổng lồ phải mất hàng tháng để viết? Ai có thời gian để xem xét hàng ngàn dòng mã? ... "

(2) Dan Fabulich : "Bom mã, hoặc: Người mới với ý tưởng lớn ... Bom mã là một miếng vá lớn đến mức không ai có thể xem lại."

(3) Google Summer Code: Nguyên tắc : "Cam kết sớm, cam kết thường xuyên ... Vui lòng không làm việc cả ngày và sau đó đẩy mọi thứ ra trong một quả bom mã duy nhất . Thay vào đó, mọi cam kết chỉ nên khép kín trong một nhiệm vụ cần được tóm tắt trong thông điệp tường trình. "

(4) Jeff Atwood : "bom mã ... Quy tắc số 30: Đừng đi tối . ...

Chúng tôi có thể gọi nó là một cam kết xấu . :)

Thực hành xấu

Và vâng, điều đó thường được coi là thực hành xấu , vì nó có những tác động tiêu cực của:

• làm cho nó khó khăn để xem xét ,
• làm cho khó nắm bắt dễ dàng và nhanh chóng mục đích ban đầu của cam kết ,
• làm cho nó khó khăn để xem làm thế nào nó đã tác động đến mã để khắc phục hoặc giải quyết vấn đề một cách rõ ràng ,
• làm cho khó biết liệu kích thước của cam kết có phải do tiếng ồn của những thay đổi có thể không liên quan khác không (ví dụ: dọn dẹp nhỏ hoặc các nhiệm vụ khác).

Các trường hợp được chấp nhận

Tuy nhiên, bạn có thể có trường hợp các cam kết lớn là hoàn toàn chấp nhận được . Ví dụ:

• khi sáp nhập giữa các chi nhánh ,
• khi thêm các nguồn mới từ một cơ sở mã không phiên bản khác,
• khi thay thế một tính năng lớn tại chỗ (mặc dù bạn nên thực hiện điều đó trong một nhánh, với các cam kết nhỏ hơn giải quyết các phần khác nhau của thay đổi, sau đó hợp nhất lại toàn bộ, để bạn có thể có một cửa sổ tốt hơn về sự phát triển gia tăng của tính năng và các vấn đề có thể gặp phải trên đường đi),
• khi tái cấu trúc một API ảnh hưởng đến nhiều lớp người tiêu dùng và hậu duệ.

Vì vậy, bất cứ khi nào có thể, hãy ưu tiên "tấn công phẫu thuật" - các loại cam kết (và liên kết chúng với ID nhiệm vụ trong trình theo dõi vấn đề của bạn!). Nếu bạn có một lý do hợp lệ, hãy tiếp tục.

Ngoài ra, tôi thực sự không biết và không nghĩ rằng tôi đã từng nghe một cái tên đặc biệt cho một cam kết lớn. Một quái vật cam kết? Một cam kết béo?

Cập nhật: Câu trả lời của David Cary liên kết với các diễn viên CNTT đáng chú ý bằng thuật ngữ "bom mã" (quan trọng nhất là Collins-Sussman, người sáng tạo ban đầu của Subversion ). Như vậy (mặc dù cho đến nay tôi không thể nói rằng tôi thường xuyên nghe thấy).

BTW, có cam kết nhiều thay đổi cùng nhau là một thực tiễn tốt?

Chà, thật không tốt khi giữ các thay đổi trong một thời gian dài và thực hiện nhiều tính năng và sửa lỗi, sau đó cam kết chúng, đó là một cách mà một cam kết lớn có thể xảy ra.

Một cách khác điều này có thể xảy ra là nếu tái cấu trúc thay đổi chữ ký của hàm được sử dụng rộng rãi, và sau đó tất cả những thứ đó phải được thay đổi. Điều này không hẳn là xấu và tôi không muốn các nhà phát triển kiềm chế làm sạch mã vì sợ vượt qua một số ngưỡng.

Vì vậy, có nhiều thứ hơn là chỉ nhìn vào số lượng tệp được chạm trong một cam kết.

Thuật ngữ tôi đã nghe là "kiểm tra chunky" . Và tôi không phải là một fan hâm mộ của họ. Tôi thích các cam kết nhỏ hơn để đảm bảo không có gì khác bị phá vỡ ở bước hợp lý trong một dự án. Các cam kết lớn nói chung thường đầy rẫy những vấn đề gây tiếng vang trong một thời gian khi điều đó xảy ra.

Tôi gọi đó là "cam kết SVN điển hình" hoặc "ngày mai là ngày phát hành cam kết"

Tôi yêu SVN rất nhiều, tôi đã bị tắt bởi thực tế là tôi không thể thực hiện các cam kết địa phương.

EDIT: họ thường có các từ "thứ" và "bia" trong thông điệp cam kết.

EDIT LẠI: Cam kết rất nhiều thay đổi, trong khi không nhất thiết là một thực hành xấu, nên tránh càng nhiều càng tốt. Tôi thấy dễ dàng hơn để xem xét sửa đổi / cam kết ngắn gọn và súc tích. (được ghép nối với một thông báo cam kết được viết tốt, xem bản chỉnh sửa trước đây của tôi để biết ví dụ xấu)

Một "mã hấp nóng". :-)

• cam kết ban đầu - dự án không thuộc quyền kiểm soát sửa đổi được ném vào SVN
• tái cấu trúc - kiến ​​trúc sư có ý tưởng tuyệt vời về việc thay đổi tên lớp từ / sang Công ước đặt tên Smurf hoặc thay đổi gốc của hệ thống phân cấp gói
• định dạng mã - kiến trúc sư đã quyết định thay đổi thụt đang 4-3 chỗ hoặc kết thúc thay đổi dòng từ Unix Windows (hoặc trở lại)
• Cam kết thứ Sáu - Joe luôn cam kết làm việc cả tuần vào thứ Sáu lúc 16:30
• uuups cam kết - Ted đã vô tình xóa thư mục gốc, đã cam kết điều đó và bây giờ anh ấy lại bơm toàn bộ hệ thống phân cấp tệp vào SVN

Thông thường nhiều người có xu hướng thực hiện cam kết lớn bằng cách sử dụng VCS tập trung, đặc biệt là máy chủ thực thi chính sách cam kết tốt. Đó là cam kết phải vượt qua tất cả các bài kiểm tra và các bài kiểm tra mất nhiều thời gian hơn (dài hơn vài giây). Vì vậy, các nhà phát triển không muốn đợi quá lâu để cam kết nhiều lần và chia các thay đổi thành nhiều cam kết nhỏ.

Và các nhà phát triển có màu xanh đối với VCS có thể quên chia nhỏ các thay đổi thành nhiều cam kết nhỏ. Họ chỉ nhớ cam kết khi họ phát hành chương trình cho nhóm QA. Tệ hơn nữa, để tránh những người khác nhìn thấy mã lỗi, họ không cam kết trước khi vượt qua thử nghiệm QA thành công. Cuối cùng, họ đã không nhận ra rằng họ đã cam kết các tệp nhị phân đầu ra, các tệp tạm thời và đầu ra của trình liên kết, thực sự tạo ra các cam kết "lớn".