มันเป็นการดีที่จะเก็บความคิดเห็นข้อผิดพลาดในรหัสหรือไม่

ทีมของฉันใช้ตัวพิมพ์เล็ก - ใหญ่เป็นตัวควบคุมเวอร์ชัน โครงการที่ฉันทำงานอยู่ไม่ได้เริ่มต้นมาตั้งแต่ 7-8 ปี ตลอดช่วงเวลาของโครงการเรามีการเปิดตัวเซอร์วิสแพ็คแก้ไขข้อผิดพลาดหลายครั้งปัญหาถูกติดตามโดยใช้ระบบติดตามบั๊กและผู้คนส่วนใหญ่ที่ทำงานแก้ไขบั๊กจะทำตามความคิดเห็นใน START / END block พร้อมกับวันที่, ผู้แต่ง, bug-id ฯลฯ

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

วิธีปฏิบัติที่ดีที่สุดที่ควรปฏิบัติตามคืออะไร

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

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

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

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

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

การปฏิบัติที่ไม่ดี ความคิดเห็นจะล้าสมัยและทำให้รหัสยุ่งเหยิง ข้อมูลยังคงมีอยู่ในประวัติรุ่นของระบบ SCC ของคุณหากจำเป็น

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

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

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

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

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

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

vcs blame file.ext

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

ระบบ VCS ที่ดีจะช่วยให้คุณไม่สนใจช่องว่างเมื่อคำนวณว่าใครแก้ไขบรรทัด

ฉันไม่รู้ว่า Clear Case มีคุณสมบัตินี้อย่างไร