ใครช่วยอธิบายข้อดีของการลบ (หรือเก็บ) รหัสที่ไม่ได้ใช้

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

คะแนนของฉันที่ไม่ลบนั่นคือ:

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

ใครช่วยอธิบายข้อดีของการลบ (หรือเก็บ) รหัสที่ไม่ได้ใช้

นี่คือสาเหตุบางประการที่ควรลบรหัสที่ไม่ได้ใช้:

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

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

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

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

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

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

@suspectus ทำงานได้อย่างยอดเยี่ยมในการนำเสนอเหตุผลในการลบรหัส ฉันต้องการระบุหัวข้อย่อยของคุณสำหรับการเก็บรหัส

• เขียนโค้ดแล้วและใช้ความพยายาม

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

• โค้ดอาจได้รับการทดสอบในสภาพแวดล้อมที่เป็นจริง

ฉันขอโทษฉันไม่รู้ว่าคุณหมายถึงอะไร

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

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

• รหัสอาจถูกใช้ในอนาคต

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

• เมื่อลบผู้เขียนอาจรู้สึกไม่สบายใจ

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

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

เขียนโค้ดแล้วและใช้ความพยายาม

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

โค้ดอาจได้รับการทดสอบในสภาพแวดล้อมที่เป็นจริง

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

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

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

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

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

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

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

รหัสอาจถูกใช้ในอนาคต

หากเป็นเช่นนั้นคุณจะพบได้ใน SCM ของทีมที่คุณเลือก

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

เมื่อลบผู้เขียนอาจรู้สึกไม่สบายใจ

ดังนั้น?

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

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

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

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

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

รหัสที่ตายแล้วทำให้รหัสของคุณเป็นมลพิษ

Dead code ลดความเข้าใจและความสามารถในการอ่าน

รหัสที่ดีที่สุดจะถูกนำมาใช้ใหม่เสมอและหากคุณมีรหัสที่ตายแล้วจะช่วยลดการนำกลับมาใช้ใหม่

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

รหัสที่ตายแล้วหรือมีการแสดงความคิดเห็นเป็นเหมือนสัญญาณบอกทางเท็จที่สร้างความสับสนให้กับผู้คนเท่านั้นดังนั้นหลีกเลี่ยงค่าใช้จ่ายทั้งหมด

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

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

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

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

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

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

• รหัสที่ไม่ได้ใช้เป็นพื้นที่ค้นหาที่ใหญ่กว่าสำหรับทั้งคุณในการอ่านและสิ่งอื่น ๆ ที่โดยทั่วไปจะสแกนโค้ดของคุณ ตัวอย่างเช่นคอมไพเลอร์, IDE, ค้นหาในไฟล์, การดีบัก, การวิเคราะห์แบบคงที่, การตรวจทานอื่น ๆ , การรวมไฟล์, การตรวจสอบจาก VCS เป็นต้นซึ่งจะทำให้กระบวนการเหล่านั้นช้าลงและเพิ่มสัญญาณรบกวนที่สำคัญ
• รหัสที่ไม่ได้ใช้ไม่ใช่รหัสตายเสมอไป อาจดำเนินการในบางสถานการณ์ สิ่งนี้ไม่เพียง แต่นำเสนอเวกเตอร์สำหรับจุดบกพร่องและปัญหาด้านประสิทธิภาพเท่านั้น แต่ยังเป็นปัญหาด้านความปลอดภัยอีกด้วย ในแง่ของประสิทธิภาพสิ่งนี้สามารถแสดงออกในรูปแบบที่ไม่คาดคิดเช่นการดาวน์โหลดที่ใหญ่ขึ้น
• รหัสที่ไม่ได้ใช้จะทำให้เกิดรหัสที่ไม่ได้ใช้ หากคุณลบการเรียกใช้ฟังก์ชันแล้วค้นหาการใช้ฟังก์ชันนั้นเพื่อดูว่าจำเป็นหรือไม่คุณอาจเห็นการจับคู่จากรหัสที่ไม่ได้ใช้ก่อนหน้านี้และถือว่าคุณสามารถเก็บไว้ได้ ยิ่งคุณมีรหัสที่ไม่ได้ใช้มากเท่าไหร่ก็ยิ่งมีการกระโดดมากขึ้นเพื่อตรวจสอบว่าไม่มีการใช้รหัสหรือไม่
• รหัสที่ไม่ได้ใช้มักจะต้องได้รับการดูแล ให้บอกว่า A และ B ขึ้นอยู่กับ C จาก B เหล่านั้นไม่ได้ใช้ คุณเปลี่ยน C แล้ว B จะไม่คอมไพล์เนื่องจากคุณได้ลบสมาชิกออกจากโครงสร้างใน C ที่ B ต้องการตอนนี้คุณต้องแก้ไข B หรือลบออกจากการคอมไพล์ คุณควรจะลบมันออกไป

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

เพื่อตอบสนองคะแนนของคุณ ...

• เขียนโค้ดแล้วและใช้ความพยายาม

แต่มักจะต้องได้รับการบำรุงรักษา นอกจากนี้ยังจะแสดงในสิ่งต่างๆเช่น find ในไฟล์

• โค้ดอาจได้รับการทดสอบในสภาพแวดล้อมที่เป็นจริง

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

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

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

• รหัสอาจถูกใช้ในอนาคต

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

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

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

• เมื่อลบผู้เขียนอาจรู้สึกไม่สบายใจ

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

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

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

การสนทนานี้มีอายุหลายปีแล้ว แต่ฉันเพิ่งเจอมัน ...

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

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

แน่ใจหรือว่ารหัสไม่ได้ใช้?

ยังไม่เพียงพอที่จะตรวจสอบโค้ดที่ยังรวบรวม ใน C ++ หากคุณลบเมธอดที่กำหนดโดยนัยที่ "ไม่ได้ใช้" ออกไปเช่นoperator=คุณจะไม่ได้รับข้อผิดพลาดของคอมไพเลอร์คลาสจะเริ่มใช้การใช้งานเริ่มต้น (อาจไม่ถูกต้อง) อย่างเงียบ ๆ ใน Java หรือ C # อาจใช้โค้ดผ่านการสะท้อนกลับ ในภาษาเชิงวัตถุการสืบทอดสามารถมีบทบาท (ปัจจุบันอาจเรียกคลาสพื้นฐาน) ในเกือบทุกภาษาอาจมีการใช้ฟังก์ชันอื่นที่มากเกินไป

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

ลบรหัสที่ไม่ได้ใช้อย่างจริงจัง

คุณจ่ายเพื่อรักษารหัส:

• แก้ไขงานสร้างที่เสียหาย (เวลาวิศวกรรม) เมื่อเร็ว ๆ นี้เรามีห่วงโซ่ที่ซับซ้อนของ#includeเปลี่ยนแปลงที่โดยนำเสนอการโอเวอร์โหลดใหม่ให้กับโค้ดที่ไม่ได้ใช้ซึ่งนำไปสู่ความปวดหัวพอสมควรสำหรับวิศวกรทุกคนในทีมนักพัฒนาหลายสิบคน
• ในทรัพยากรเครื่องเกี่ยวกับการทดสอบ (สมมติว่าคุณมีการทดสอบตัวเองแบบต่อเนื่อง) เมื่อเร็ว ๆ นี้ทีมของเราได้ตรวจสอบการทดสอบที่ช้าที่สุดทั้งหมดของเราและหลาย ๆ การทดสอบนั้นใช้รหัสที่ไม่ได้ใช้ วิศวกรที่ทำการทดสอบในพื้นที่หรือเป็นส่วนหนึ่งของการผสานรวมอย่างต่อเนื่องกำลังรอการทดสอบเกี่ยวกับโค้ดที่ไม่ได้ใช้
• ในแง่ของความสามารถในการอ่าน (เวลาวิศวกรรมอีกครั้ง) ไฟล์ส่วนหัวของคุณแสดงถึง API หากพวกเขามีฟังก์ชันที่ไม่มีใครอยากใช้ แต่ทุกคนต้องอ่านเส้นโค้งการเรียนรู้ของโค้ดของคุณนั้นยากกว่ามาก
• ในการค้นหาโค้ด (วิศวกรรมอีกครั้ง) คุณจะทำความสะอาดบ้านฮาร์ดไดรฟ์หรือ Google ไดรฟ์ของคุณหรือไม่? ยิ่งคุณค้นหาโดเมนมากเท่าใดโดเมนนั้นก็ยิ่งมีความสำคัญมากขึ้นเท่านั้นที่จะต้องมีเนื้อหาที่เกี่ยวข้องเพื่อหลีกเลี่ยงสิ่งที่ผิดพลาด (หรือคุณใช้การค้นหาที่ซับซ้อนมากขึ้นเช่นเครื่องมือค้นหาเว็บ)

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