มีเหตุผลในการออกเครื่องหมายความขัดแย้งในรหัสตรวจสอบใน?

พิจารณาเครื่องหมายความขัดแย้ง เช่น:

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

ในกรณีเฉพาะที่กระตุ้นให้ฉันโพสต์คำถามนี้สมาชิกในทีมที่รับผิดชอบเพิ่งจะทำการผสานตั้งแต่ต้นน้ำจนถึงสาขาของเราและในบางกรณีก็ทิ้งสิ่งเหล่านี้ไว้ในความคิดเห็นเป็นเอกสารประกอบสิ่งที่เพิ่งเกิดขึ้น การแก้ไข เขาทิ้งไว้ในสถานะที่รวบรวมการทดสอบผ่านดังนั้นจึงไม่เลวร้ายอย่างที่คุณคิด

โดยสัญชาตญาณแม้ว่าฉันจะคัดค้านเรื่องนี้จริง ๆ แต่เป็นมารสนับสนุนให้ตัวเองฉันสามารถดูว่าทำไมเขาอาจทำ:

• เพราะมันเน้นไปที่นักพัฒนาทีมคนอื่น ๆ สิ่งที่มีการเปลี่ยนแปลงอันเป็นผลมาจากการรวม
• เพราะผู้ที่มีความเชี่ยวชาญมากขึ้นในส่วนของรหัสสามารถแก้ไขข้อกังวลที่แสดงโดยข้อคิดเห็นเพื่อที่เขาจะได้ไม่ต้องเดา
• เนื่องจากการรวมอัปสตรีมเป็นความเจ็บปวดที่ถูกต้องและอาจเป็นเรื่องยากที่จะพิสูจน์เวลาในการแก้ไขทุกอย่างให้ดีและสมบูรณ์ดังนั้นการแจ้งเตือน FIXME แบบกึ่งสมบูรณ์จึงมีความจำเป็นดังนั้นทำไมไม่ใช้ความขัดแย้งเดิมเป็นความคิดเห็น

การคัดค้านของฉันเป็นสัญชาตญาณ แต่ฉันต้องการที่จะพิสูจน์เหตุผลอย่างมีเหตุผลหรือเห็นตำแหน่งของฉันอย่างชาญฉลาด ทุกคนสามารถให้ฉันตัวอย่างหรือประสบการณ์ที่ผู้คนมีช่วงเวลาที่เลวร้ายกับคนอื่นทำเช่นนี้และ / หรือเหตุผลที่ว่าทำไมมันถึงเป็นการปฏิบัติที่ไม่ดี (หรือคุณสามารถเล่นผู้สนับสนุนของปีศาจและสนับสนุนมัน)

ข้อกังวลของฉันเองในทันทีคือมันจะน่ารำคาญถ้าฉันได้แก้ไขไฟล์ใดไฟล์หนึ่งที่เกี่ยวข้องดึงการเปลี่ยนแปลงมีความขัดแย้งจริง แต่ก็ดึงความคิดเห็น ถ้าอย่างนั้นฉันจะมีไฟล์ยุ่งมากแน่นอน โชคดีที่ไม่ได้เกิดขึ้น

นี่เป็นความผิดที่ชัดเจน มันเป็นงานของระบบควบคุมเวอร์ชันเพื่อติดตามการเปลี่ยนแปลงและเป็นหน้าที่ของเครื่องมือต่าง ๆ เพื่อแสดงสิ่งที่เปลี่ยนไปอันเป็นผลมาจากการผสาน ควรมีความคิดเห็นในบันทึกการกระทำและอาจอยู่ในรหัสอธิบายสิ่งที่เปลี่ยนแปลงไปและทำไม อย่างไรก็ตาม IMHO การทิ้งเครื่องหมายความขัดแย้งไว้เป็นความคิดเห็นเหมือนกับการทิ้งโค้ดไว้

ฉันมีปัญหาที่คล้ายกันกับรหัสบางอย่างอาจถูกคอมเม้นท์ (ซึ่งคล้ายกับกรณีของคุณ) หรือย้ายไปยังวิธีที่ไม่ได้ถูกเรียกจริง เมื่อถูกถามว่าทำไมผู้คนถึงทำสิ่งนี้การตอบสนองคือพวกเขารู้สึกปลอดภัยขึ้นเล็กน้อยเมื่อพวกเขามีบล็อคโค้ดอยู่ อาร์กิวเมนต์ตัวนับที่ชัดเจนที่สุดคือว่ามันเป็นงาน VCS ไม่ใช่ของพวกเขา อย่างไรก็ตามยังมีแง่มุมอื่น เมื่อมีคนอื่นกำลังอ่านรหัสในขณะที่เรียนรู้หรือทำการเปลี่ยนแปลงเขาอาจจะถูกติดตามโดยความคิดเห็นดังกล่าว เขาจะอ่านอย่างแน่นอนและอาจใช้เวลาสักครู่เพื่อทำความเข้าใจว่าทำไมถึงมาถึงที่นี่และความสัมพันธ์ที่เป็นไปได้กับงานปัจจุบันของเขา เนื่องจากเครื่องหมายความขัดแย้งเป็นสัญญาณของความขัดแย้งที่ได้รับการแก้ไขแล้วนี่เป็นการเสียเวลาอย่างแน่นอน

ฉันคิดว่าความคิดเห็นควรอ้างถึงรหัสที่มีไม่ใช่รหัสที่เคยมีในอดีตหรือเหตุการณ์ที่เกิดขึ้นกับรหัสในอดีตและรหัสที่มีอยู่ในเอกภพคู่ขนาน (สาขาอื่น) ใน อดีต ออกจากเครื่องหมายในแบบที่สมาชิกในทีมของคุณสร้างขึ้นอย่างน้อยสามปัญหา:

1. รหัสต้นฉบับอาจเป็นอะไรที่คล้ายblah blah nullกันและรายงานข้อผิดพลาดบอกว่า "ไม่สามารถใช้ null ได้ใช้สิ่งนี้หรือสิ่งนั้นหรืออะไรก็ตาม" ดังนั้นคนสองคนจึงแก้ไขข้อผิดพลาดได้อย่างอิสระและเมื่อมีการรวมการแก้ไขความขัดแย้งจึงเกิดขึ้น ตอนนี้เอกสารความคิดเห็นไม่ใช่ปัญหาที่เกิดขึ้นหรือสิ่งที่แก้ไขได้รับการแก้ไข แต่เพียงว่ามีการแก้ไขที่แตกต่างกันสองครั้งในอดีต นั่นไม่เป็นประโยชน์มาก ความคิดเห็นที่ต้องการ//blah blah needs a non-null argumentอย่างน้อยก็จะให้สิ่งที่บ่งบอกถึงการเปลี่ยนแปลง (และแม้กระทั่งว่าข้อมูลนั้นสามารถใช้งานได้ง่ายขึ้นจากคอมมิทคอมของระบบควบคุมเวอร์ชัน)
2. เวอร์ชันที่ผสานอาจดูไม่เหมือนหนึ่งในบรรทัดต้นฉบับ บางทีถ้าคุณต้องการ blah blah ที่จะใช้สิ่งนี้และรูปแบบที่ถูกต้องคือblah blah (this,that)หรือแม้กระทั่งบางสิ่งที่ซับซ้อนมากขึ้น ในกรณีดังกล่าวการทิ้งข้อความแสดงความขัดแย้งไว้ในความคิดเห็นจะสร้างความสับสนให้กับทุกคนที่พยายามอ่านรหัสในภายหลัง
3. ระบบควบคุมเวอร์ชันส่วนใหญ่ให้คุณเข้าถึงประวัติโครงการ ตัวอย่างเช่นฉันสามารถคลิกขวาที่ไฟล์ใน eclipse (กับ svn) พูดว่า "Show History ... " แล้วพูดว่า "Compare Current with ... 'และรับหน้าต่าง diff ที่เน้นความแตกต่างข้อมูลนั้นเป็นวิธี ง่ายกว่าที่จะติดตามถ้าไฮไลต์ diff มีความแตกต่างจริงและไม่ใช่ความคิดเห็นที่อยู่รอบ ๆ การเปลี่ยนแปลงที่ไม่ทำงานในโค้ดทำให้การอ่านยากขึ้น

เครื่องหมายข้อขัดแย้งในรหัสที่เช็คอินน่ารำคาญแค่ไหน?

ดังนั้นน่ารำคาญ