Có biện minh cho việc để lại các dấu hiệu xung đột trong mã đăng ký không?

Xem xét các dấu hiệu xung đột. I E:

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

Trong trường hợp cụ thể đã thúc đẩy tôi đăng câu hỏi này, thành viên nhóm chịu trách nhiệm vừa hoàn thành việc hợp nhất từ ​​thượng nguồn đến chi nhánh của chúng tôi và trong một số trường hợp đã để lại những điều này, như là một tài liệu về những gì vừa xảy ra giải quyết. Anh ta để nó ở trạng thái biên dịch, các bài kiểm tra trôi qua, vì vậy nó không tệ như bạn nghĩ.

Mặc dù theo bản năng, tôi thực sự phản đối điều này, tuy nhiên việc quỷ chủ trương với chính tôi Tôi có thể thấy lý do tại sao anh ta có thể làm điều đó:

• bởi vì nó nổi bật với các nhà phát triển nhóm khác, những gì đã thay đổi do sự hợp nhất.
• bởi vì những người có chuyên môn hơn với các đoạn mã cụ thể sau đó có thể giải quyết các mối quan tâm được minh họa bằng các bình luận để anh ta không phải đoán.
• bởi vì hợp nhất ngược dòng là một nỗi đau đúng đắn và khó có thể biện minh thời gian để giải quyết mọi thứ tốt và hoàn toàn, vì vậy một số thông báo FIXME bán hoàn chỉnh là cần thiết, vậy tại sao không sử dụng xung đột ban đầu làm nhận xét để ghi lại điều này.

Sự phản đối của tôi là theo bản năng, nhưng tôi muốn có thể biện minh cho nó một cách hợp lý, hoặc nhìn nhận vị trí của tôi một cách khôn ngoan hơn. Bất cứ ai cũng có thể cho tôi một số ví dụ hoặc thậm chí kinh nghiệm nơi mọi người đã có một thời gian tồi tệ với người khác làm điều này và / hoặc lý do tại sao nó thực hành xấu (hoặc bạn có thể chơi người ủng hộ của quỷ và hỗ trợ nó).

Mối quan tâm trước mắt của tôi là rõ ràng sẽ rất khó chịu nếu tôi chỉnh sửa một trong các tệp có liên quan, kéo các thay đổi, có xung đột thực sự, nhưng cũng kéo theo các nhận xét. Sau đó, tôi đã có một tập tin rất lộn xộn thực sự. May thay điều đó đã không xảy ra.

Điều này rõ ràng là sai. Công việc của hệ thống kiểm soát phiên bản là theo dõi các thay đổi và công việc của các công cụ khác là hiển thị những gì đã thay đổi do kết quả của việc hợp nhất. Cần có một nhận xét trong nhật ký cam kết và có thể trong mã, giải thích những gì đã thay đổi và tại sao. Tuy nhiên, IMHO, để lại các dấu hiệu xung đột trong các nhận xét cũng giống như để lại mã chết xung quanh.

Tôi đã gặp vấn đề tương tự với một số mã hoặc được nhận xét (bằng cách nào đó tương tự như trường hợp của bạn) hoặc chuyển sang một phương thức không thực sự được gọi ở bất cứ đâu. Khi được hỏi tại sao mọi người làm điều này, câu trả lời là họ cảm thấy an toàn hơn một chút khi họ vẫn còn một số khối mã. Đối số rõ ràng nhất là công việc của VCS chứ không phải của họ. Tuy nhiên, cũng có một khía cạnh khác. Khi ai đó đang đọc mã trong khi học hoặc thực hiện các thay đổi, anh ta có thể sẽ bị theo dõi bởi một nhận xét như vậy. Anh ấy chắc chắn sẽ đọc nó và có lẽ dành một chút thời gian để hiểu tại sao nó ở đây và nó có liên quan gì đến công việc hiện tại của anh ấy. Vì một dấu hiệu xung đột là dấu hiệu của một cuộc xung đột, đã được giải quyết, điều này chắc chắn là lãng phí thời gian.

Tôi nghĩ rằng các bình luận nên đề cập đến mã ở đó, không phải là mã đã có ở quá khứ, cũng không phải là các sự kiện đã xảy ra với mã trong quá khứ, cũng không phải là mã tồn tại trong vũ trụ song song (nhánh khác) trong quá khứ. Để lại các điểm đánh dấu theo cách mà thành viên trong nhóm của bạn đã tạo ra ít nhất ba vấn đề:

1. Mã ban đầu có thể là một cái gì đó giống như blah blah null, và báo cáo lỗi cho biết "Không thể sử dụng null ở đó, sử dụng cái này hoặc cái kia, hoặc bất cứ điều gì." Vì vậy, hai người đã độc lập sửa lỗi và khi các bản sửa lỗi được hợp nhất, xung đột nảy sinh. Bây giờ các tài liệu bình luận không phải là vấn đề cũng như sửa lỗi gì, mà chỉ có hai cách khắc phục khác nhau tại một số điểm trong quá khứ. Điều đó không hữu ích lắm. Một nhận xét như thế //blah blah needs a non-null argumentít nhất sẽ đưa ra một dấu hiệu cho thấy những gì đã thay đổi (và thậm chí thông tin đó có sẵn dễ dàng hơn từ nhận xét cam kết của hệ thống kiểm soát phiên bản).
2. Phiên bản được hợp nhất thậm chí có thể không giống như một trong những dòng gốc. Có lẽ nếu bạn muốn blah blah lấy cái này và cái kia, hình thức chính xác là blah blah (this,that)hoặc thậm chí một cái gì đó phức tạp hơn. Trong trường hợp đó, để lại thông điệp xung đột dưới dạng một nhận xét chắc chắn sẽ gây nhầm lẫn cho bất kỳ ai đang cố đọc mã sau này.
3. Hầu hết các hệ thống kiểm soát phiên bản cung cấp cho bạn quyền truy cập vào lịch sử dự án. Ví dụ: tôi có thể nhấp chuột phải vào một tệp trong nhật thực (với svn), nói "Hiển thị lịch sử ..." và sau đó nói "So sánh hiện tại với ... 'và nhận được một cửa sổ khác biệt làm nổi bật sự khác biệt. dễ dàng hơn để tìm hiểu nếu các điểm nổi bật khác nhau chứa các khác biệt thực tế và không phải là các nhận xét xung quanh chúng. Mỗi một chút thay đổi phi chức năng trong mã làm cho điều đó khó đọc hơn.

Làm thế nào gây phiền nhiễu là các dấu xung đột trong mã đăng ký?

Thật phiền phức.