เราวัดความสามารถในการบำรุงรักษาได้อย่างไร

บริบท: ฉันเป็นนักพัฒนาองค์กรในร้าน MS ทั้งหมด

ใครช่วยแนะนำวิธีที่ดีในการวัดความสามารถในการบำรุงรักษาโค้ดหรือแอพพลิเคชั่นอย่างเป็นกลาง ?

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

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

ฉันกำลังดูการวัดโค้ด VS2010แต่ฉันสงสัยว่าใครมีคำแนะนำอื่น ๆ

ข้อแม้ที่มีความสามารถในการบำรุงรักษาวัดคือคุณกำลังพยายามทำนายอนาคต ความครอบคลุมของรหัส, การนับบั๊ก, LOC, ความซับซ้อนของวัฏจักรนั้นเกี่ยวข้องกับปัจจุบันทั้งหมด

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

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

การวัดที่ฉันใช้หรือคิดว่าฉันใช้นี่คือ:

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

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

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

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

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

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

การบำรุงรักษานั้นไม่สามารถวัดได้จริงๆ มันเป็นทัศนะส่วนตัวของแต่ละบุคคลตามประสบการณ์และความชอบของเขา

สำหรับรหัสที่ให้มากับแนวคิดของการออกแบบที่สมบูรณ์แบบ

จากนั้นสำหรับส่วนเบี่ยงเบนของรหัสจริงจากที่สมบูรณ์แบบนั้นลดค่า 100 โดยบางหมายเลข โดยสิ่งที่แน่นอนขึ้นอยู่กับผลกระทบของวิธีการที่ไม่สมบูรณ์แบบที่เลือก

ตัวอย่าง:

ส่วนหนึ่งของรหัสจะอ่านและนำเข้ารูปแบบข้อมูลบางส่วนและอาจแสดงข้อความแสดงข้อผิดพลาดหากมีสิ่งผิดปกติ

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

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

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

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

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

ฉันพบว่ามาตรวัดรหัส Visual Studio นั้นค่อนข้างดีสำหรับการจัดทำเมตริก "การบำรุงรักษา" อย่างรวดเร็ว 5 ตัวชี้วัดหลักถูกจับ:

• ความซับซ้อนของวัฏจักร
• ความลึกของมรดก
• ชั้น Couling
• Lines of Code (ต่อวิธีต่อชั้นเรียนต่อโครงการแล้วแต่อะไรก็ตามขึ้นอยู่กับระดับการหมุนของคุณ)

ดัชนีการบำรุงรักษาเป็นสิ่งที่ฉันพบว่ามีประโยชน์ มันเป็นดัชนีคอมโพสิตตาม:

1. ขนาดโดยรวม (บรรทัดของรหัส)
2. # ของคลาสหรือไฟล์
3. # ของวิธีการ
4. Cyclomatic Complexity สูงกว่า 20 (หรือ 10 - กำหนดได้ 10 คือความชอบของฉัน)
5. การทำสำเนา

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

ดูกระดาษสีขาวสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการคำนวณ

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

ความซับซ้อนของวงจรคือการวัดจำนวนเส้นทางที่มีอยู่ในรหัส ควรทดสอบแต่ละเส้นทาง (แต่อาจไม่ใช่) สิ่งที่มีความซับซ้อนสูงกว่าประมาณ 20 ควรแบ่งเป็นโมดูลขนาดเล็กกว่า โมดูลที่มีความซับซ้อนทางไซน์ของ 20 (หนึ่งสามารถทำซ้ำนี้กับ 20 if then elseบล็อกต่อเนื่อง) จะมีขอบเขตบนของ 2 ^ 20 เส้นทางในการทดสอบ

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

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

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

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

หนี้สินทางเทคนิคจำนวนมหาศาลที่ไม่เคยได้รับการแก้ไข

หนี้ทางเทคนิคที่เกี่ยวกับ "ตามเหตุการณ์" เป็นอย่างไร

ฉันเขียนโค้ดเส็งเคร็งและเร่งการผลิต

คุณสังเกต - ถูกต้อง - มันไม่สามารถบำรุงรักษาได้

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

"หนี้ทางเทคนิค" ถูกกำจัดโดยการเปลี่ยนแปลงทางกฎหมายที่ทำให้ล้าสมัยทั้งหมด

ตัวชี้วัด "การบำรุงรักษา" ไปจาก "ไม่ดี" เป็น "ไม่เกี่ยวข้อง" เนื่องจากข้อควรพิจารณาภายนอก

จะวัดได้อย่างไร?

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

แบบสอบถาม

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

• คุณใช้เวลาเท่าไรในเดือนที่แล้วกับโครงการ X (ประมาณ) [0% ... 100%]
• คุณจะให้คะแนนสถานะของรหัสฐานอย่างไรในแง่ของการบำรุงรักษา [แย่จริง ๆ ไม่ดีเป็นกลางเป็นกลางดีดีจริง ๆ ]
• คุณจะให้คะแนนรหัสฐานที่ซับซ้อนอย่างไรเมื่อเปรียบเทียบกับความซับซ้อนของโครงการ [วิธีซับซ้อนเกินไปถูกต้องง่ายเกินไป]
• บ่อยครั้งที่คุณรู้สึกว่าถูกบดบังในการแก้ปัญหาเนื่องจากความซับซ้อนของฐานรหัสมากเกินไป? [ไม่เลยสักครั้งนาน ๆ บ่อย ๆ ]

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

ฉันสามารถนึกถึงสองวิธีในการดูการบำรุงรักษา (ฉันมั่นใจว่ามีหวังมากกว่าที่คนอื่น ๆ สามารถหาคำจำกัดความที่ดีได้

การดัดแปลงโดยไม่เข้าใจ

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

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

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

maintainabilty1 = K1 . (Code Coverage)/(Coupling of Code) * (Complexity of API)

ดัดแปลงด้วยความเข้าใจ

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

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

ดังนั้นบางทีเราสามารถหาข้อวัดนี้ได้:

maintainability2 = K2 . (Size of doc)/(Time to write doc)

ฉันมักจะพบว่าวิธีแก้ปัญหา "สั้นที่สุดเทียบเท่า" มักจะบำรุงรักษาได้มากที่สุด

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

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

นอกจากนี้เรายังสามารถยอมรับได้ว่าควรลบ abstractions ที่ไม่ได้ใช้: คลาส, ฟังก์ชันที่ไม่ต้องการอีกต่อไปคือรหัสตายดังนั้นควรลบออก การควบคุมเวอร์ชันจะจดจำได้หากเราจำเป็นต้องกู้คืน

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

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

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

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

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