การเช็คอินของรหัส "แสดงความคิดเห็นออก" [ปิด]

โอเคนี่คือสิ่งที่ทำให้เกิดความขัดแย้งในงานปัจจุบันของฉันและฉันไม่คาดคิดเลยจริงๆ การพัฒนาซอฟต์แวร์ภายในองค์กรเป็นแนวคิดใหม่ที่นี่และฉันได้ร่างหลักเกณฑ์การเขียนโค้ดฉบับร่างแรก

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

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

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

อย่างไรก็ตามคุณมีความคิดอย่างไร? คุณเชื่อว่าโค้ด "แสดงความคิดเห็น" มีประโยชน์ในที่เก็บหรือไม่?

ฉันสนใจที่จะรับฟังความคิดเห็นจากผู้อื่นในหัวข้อนี้

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

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

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

นี่คือหลักการที่ฉันได้เรียนรู้และพยายามทำตาม:

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

ซึ่งหมายความว่า:

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

สรุปแล้วไม่! หากโค้ดยังไม่พร้อมที่จะไปยังขั้นตอนถัดไป (แล้วแต่ว่าจะเหมาะกับคุณ: IntTest / QA / UAT / PreProd / Prod) ก็ไม่ควรผูกมัดกับ trunk หรือ multi-developer branch ระยะเวลา

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

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

"ไม่เคย" ไม่ค่อยเป็นคำที่ดีที่จะใช้ในแนวทางปฏิบัติ

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

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

ไม่ควรเช็คอินรหัสที่แสดงความคิดเห็นเพื่อวัตถุประสงค์ในการรักษาประวัติ นั่นคือจุดควบคุมแหล่งที่มา

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

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

หากจำเป็นฉันจะสร้างสาขาการทำงานของตัวเองเพื่อทำการเปลี่ยนแปลงบางส่วน

กรณีหนึ่งที่ฉันแสดงความคิดเห็นออกรหัส:

// This approach doesn't work
// Blah, blah, blah

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

แน่นอนฉันจะท้อใจอย่างยิ่งที่จะตรวจสอบรหัสที่แสดงความคิดเห็น อย่างไรก็ตามฉันจะไม่ห้ามมันอย่างแน่นอน บางครั้ง (ถ้าไม่ค่อยมี) ควรตรวจสอบโค้ดที่แสดงความคิดเห็นในการควบคุมแหล่งที่มา การพูดว่า "อย่าทำอย่างนั้น" เป็นการ จำกัด เกินไป

ฉันคิดว่าเราทุกคนเห็นด้วยกับประเด็นเหล่านี้:

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

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

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

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

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

Rex M กล่าวว่า 1) ตรวจสอบเฉพาะฟังก์ชันการทำงานที่สมบูรณ์ 2) [ถ้า] งานมีขนาดใหญ่เกินไปให้แบ่งเป็นงานเล็ก ๆ

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

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

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

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

ฉันคิดว่าไม่เคยเป็นเงื่อนไขที่แข็งแกร่งเกินไป

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

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

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

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

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

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

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

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

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

"กำลังตรวจสอบการเปลี่ยนแปลงบางส่วนที่อาจจะนำมาใช้หรือไม่ก็ได้" - สันนิษฐานว่าอาจมีการทดสอบหรือไม่ก็ได้ นั่นคือความลาดชันที่ลื่นไปจนถึงฐานรหัสที่มีเชือกมาก

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

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

ฉันเดาว่าคุณมาจากค่าย "รหัสดี" และเขาเป็นคนในค่าย "รหัสทำงาน"

[แก้ไข]

จากความคิดเห็นใช่ฉันเดาถูก

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

btw: บรรณาธิการที่ดีจะช่วยในการรักษาเวอร์ชันเก่า ตัวอย่างเช่นใน Emacs ฉันตั้งค่าเวอร์ชันเก่าและเวอร์ชันเก่าที่เก็บไว้เป็น 10 ซึ่งเก็บไว้ประมาณ 10 ไฟล์ล่าสุดที่บันทึกไว้ คุณอาจมองว่านั่นเป็นวิธีที่ช่วยโต้แย้งกับฝูงชนที่แก้ไข - ควบคุม - เป็นสำรอง อย่างไรก็ตามคุณจะไม่ชนะการโต้แย้ง

จากประสบการณ์ของฉันสวิตช์ของนักพัฒนาจะแสดงความคิดเห็นในโค้ด

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

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

อีกเหตุผลหนึ่งในการเช็คอินแสดงความคิดเห็นรหัส:

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

บางทีคำถามที่แท้จริงก็คือนักพัฒนาควรได้รับอนุญาตให้ตรวจสอบโค้ดที่ไม่สมบูรณ์หรือไม่?

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

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

มุมมองของฉัน: หากนักพัฒนากำลังทำงานในสาขาของตนเองหรือในพื้นที่แซนด์บ็อกซ์ของตนเองพวกเขาควรจะสามารถตรวจสอบสิ่งที่ต้องการได้ เมื่อพวกเขาตรวจสอบรหัสในสาขาที่ใช้ร่วมกัน (สาขาคุณลักษณะหรือสาขาของทีมหรือแน่นอน MAIN / ลำตัว) รหัสควรมีความบริสุทธิ์มากที่สุดเท่าที่จะเป็นไปได้ (ไม่มีรหัสแสดงความคิดเห็นไม่มี FIXME อีกต่อไป ฯลฯ )

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

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

ฉันเห็นด้วยอย่างยิ่งว่าไม่ควรตรวจสอบโค้ดที่แสดงความคิดเห็นในที่เก็บนั่นคือสิ่งที่ใช้ควบคุมซอร์สโค้ด

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

ฉันคิดว่ามันซับซ้อนโค้ดและทำให้อ่านยาก

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

ฉันคิดว่าการเช็คอินโค้ดที่แสดงความคิดเห็นในระบบควบคุมซอร์สโค้ดควรทำด้วยความระมัดระวังเป็นอย่างยิ่งโดยเฉพาะอย่างยิ่งหากแท็กภาษาที่ใช้แสดงความคิดเห็นโค้ดนั้นเขียนโดยบล็อกเช่น

/* My commented code start here
My commented code line 1
My commented code line 2
*/

แทนที่จะเป็นรายบรรทัดเช่น:

// My commented code start here
// My commented code line 1
// My commented code line 2

(คุณเข้าใจแล้ว)

เหตุผลที่ฉันจะใช้ความระมัดระวังอย่างยิ่งก็คือขึ้นอยู่กับเทคโนโลยีคุณควรระมัดระวังเกี่ยวกับเครื่องมือ diff / merge ที่คุณใช้อยู่ ด้วยระบบควบคุมซอร์สโค้ดบางอย่างและบางภาษาเครื่องมือ diff / merge อาจสับสนได้ง่าย ตัวอย่างเช่นความแตกต่าง / การรวมมาตรฐานของ ClearCase นั้นไม่ดีอย่างยิ่งสำหรับการรวมไฟล์. xml

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

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

แนวคิดในการอนุญาตให้ประวัติการควบคุมแหล่งที่มาแสดงให้เห็นถึง "วิธีการเดิม" ในการทำบางสิ่งแทนที่จะแสดงความคิดเห็นและตรวจสอบในการแสดงความคิดเห็นพร้อมกับคำอธิบายเป็นความคิดที่ดีในทางทฤษฎี

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

ถึงอย่างนั้นการมองย้อนกลับไปมากกว่า 3 เวอร์ชันโดยทั่วไปจะไม่เกิดขึ้น

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

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

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

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

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

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

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

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

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

ฉันคิดว่าโค้ดที่แสดงความคิดเห็นออกไปถือว่า "เสีย"

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

หากคุณกำลังทำการตรวจสอบรหัสเพียร์โค้ดอาจตอบคำถามของคุณ หากนักพัฒนาซอฟต์แวร์รายอื่นตรวจทานโค้ดของคุณและระบุว่า "เหตุใดจึงมีโค้ดที่แสดงความคิดเห็นออกมาซึ่งพยายามทำ" blah "แสดงว่าโค้ดของคุณล้มเหลวในการตรวจสอบโค้ดและคุณไม่ควรตรวจสอบโค้ด

โค้ดที่แสดงความคิดเห็นจะทำให้เกิดคำถามกับนักพัฒนารายอื่นดังนั้นจึงเสียเวลาและพลังงาน

คุณต้องถามคำถามว่า " ทำไม " โค้ดจึงแสดงความคิดเห็น คำแนะนำบางประการ:

หากคุณกำลังแสดงความคิดเห็นเกี่ยวกับรหัสเนื่องจากคุณ "ไม่แน่ใจในกฎทางธุรกิจ" แสดงว่าคุณอาจมีปัญหาเกี่ยวกับ "ขอบเขตการคืบคลาน" - ดีที่สุดที่จะไม่ทำให้ฐานรหัสของคุณสกปรกด้วยข้อกำหนดที่ว่า "น่าจะดี แต่เราไม่มีเวลา เพื่อนำไปใช้ "- รักษาความสะอาดด้วยโค้ดที่ชัดเจนและทดสอบสิ่งที่มีอยู่จริง

หากคุณกำลังแสดงความคิดเห็นเกี่ยวกับโค้ดเนื่องจากคุณ "ไม่แน่ใจว่าเป็นวิธีที่ดีที่สุด" ให้ตรวจสอบรหัสของคุณ! เวลาเปลี่ยนไปคุณจะดูโค้ดที่คุณเขียนวันนี้ในรอบ 2 ปีและคิดว่ามันแย่มาก! แต่คุณไม่สามารถแสดงความคิดเห็นเกี่ยวกับบิตที่คุณ 'รู้' สามารถทำได้ดีกว่านี้ แต่ตอนนี้คุณยังหาวิธีไม่ได้ ให้ใครก็ตามที่ดูแล codebase ในระยะยาวพิจารณาว่ามีวิธีที่ดีกว่าหรือไม่ - เพียงแค่เขียนโค้ดทดสอบและใช้งานได้และดำเนินการต่อ

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

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

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

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

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

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

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

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

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

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

" Scar Tissue " คือสิ่งที่ฉันเรียกว่ารหัสแสดงความคิดเห็น ในช่วงไม่กี่วันก่อนที่จะมีการใช้ระบบควบคุมเวอร์ชันอย่างแพร่หลายCode Monkeysจะแสดงความคิดเห็นของโค้ดไว้ในไฟล์ในกรณีที่จำเป็นต้องเปลี่ยนกลับฟังก์ชันการทำงาน

ครั้งเดียวที่สามารถเช็คอิน "เนื้อเยื่อแผลเป็น" ได้คือ

1. หากคุณมีสาขาส่วนตัวและ
2. คุณไม่มีเวลารวบรวมโค้ดโดยไม่มีข้อผิดพลาดและ
3. คุณกำลังจะไปพักร้อนและ
4. คุณไม่ไว้ใจ VCS ของคุณเช่นถ้าคุณใช้ Visual แหล่งที่ปลอดภัยหรือ
   [แก้ไข]
5. คุณมีข้อบกพร่องเล็กน้อยที่อาจได้รับการแนะนำอีกครั้งหากรหัสที่ไม่ถูกต้องไม่ได้ถูกทิ้งไว้เพื่อเตือนความจำ (ประเด็นดีจากคำตอบอื่น ๆ )

มีเกือบจะไม่มีข้อแก้ตัวสำหรับ # 4 เพราะมีความอุดมสมบูรณ์ของใช้ได้อย่างอิสระและมีประสิทธิภาพระบบ VCS รอบGit เป็นตัวอย่างที่ดีที่สุด

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

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

[แก้ไข] ฉันขอเพิ่มว่ามีสองสถานการณ์หลักที่ต้องแยกแยะ:

• การพัฒนาส่วนตัวไม่ว่าจะเป็นการเข้ารหัสโครงการส่วนตัวหรือเช็คอินไปยังสาขาส่วนตัว
• การพัฒนาการบำรุงรักษาโดยที่รหัสที่กำลังเช็คอินมีจุดมุ่งหมายเพื่อนำไปผลิต

แค่พูดว่า "ไม่" กับเนื้อเยื่อแผลเป็น!

ฉันไม่รู้ - ฉันมักจะแสดงความคิดเห็นในบรรทัดเดิมก่อนที่จะทำการเปลี่ยนแปลง - มันช่วยให้ฉันเปลี่ยนกลับได้ถ้าฉันเปลี่ยนใจ และใช่ฉันเช็คอิน

อย่างไรก็ตามฉันจะตัดรหัสความคิดเห็นเก่า ๆ ออกจากการเช็คอินครั้งก่อน

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

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

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

ถ้าฉันต้องย้อนกลับไปหลาย ๆ เวอร์ชันเพื่อดูการเปลี่ยนแปลงก่อนหน้านี้ซึ่งตอนนี้นำไปสู่การตีประสิทธิภาพนั่นจะน่ารำคาญมาก

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

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

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

หากนักพัฒนาได้แสดงความคิดเห็นเกี่ยวกับโค้ดบางส่วนเนื่องจากยังไม่สมบูรณ์วิธีจัดการ "ซอร์สคอนโทรล" ที่ถูกต้องในการจัดการกับสิ่งนี้คือให้นักพัฒนารายนั้นเก็บโค้ดไว้ในสาขาแยกต่างหากจนกว่าโค้ดนั้นจะพร้อมตรวจสอบ ใน.

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

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

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

ขึ้นอยู่กับระบบ VCS เพื่อช่วยนักพัฒนาในขั้นตอนการทำงานนี้ (git เป็นระบบ VCS ที่ยอดเยี่ยมระบบหนึ่งที่ทำงานร่วมกับสิ่งนี้ได้เป็นอย่างดี)