คำนวณค่าใช้จ่ายของรหัสที่ไม่ดี

ฉันกำลังมองหาข้อโต้แย้งเพื่อโน้มน้าวให้ฝ่ายบริหารลงทุนในความพยายามในการปรับโครงสร้างใหม่

เราบันทึกการทำงานโดยใช้ Jira และเชื่อมโยงทุก svn-commit กับการเรียก jira

ความคิดของฉันคือการทำต่อไปนี้:

• ตรวจดูพื้นที่ของรหัสด้วยตนเองซึ่งมีการใช้งานที่แย่มาก แต่มักจะใช้: ทั้งจาก User-POV และ Developer-POV (แก้ไขข้อผิดพลาด)
• รับ svn-commits ซึ่งมี JIRA-Issues
• กรองปัญหาตามเกณฑ์บางอย่าง (ประเภทปัญหารุ่น prio ฯลฯ ... )
• คำนวณเวลา / ความพยายามที่ใช้กับข้อบกพร่องเหล่านี้
• ประเมินความพยายามและความเสี่ยงของการปรับโครงสร้างใหม่
• แสดงตัวเลขและขอความพยายามแก้ไข

คุณคิดยังไงกับสิ่งนี้? การวัดเช่นนี้จะมีประโยชน์และ / หรือน่าเชื่อถือไหม ข้อดีข้อเสียคืออะไร

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

IMHO เพื่อสร้างกรณีที่น่าเชื่อถือคุณจะต้องมีสิ่งต่อไปนี้เพื่อแสดงว่ามันแย่แค่ไหน:

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

และเพื่อให้เป็นกรณีสำหรับการ refactoring คุณจะต้อง:

• การประมาณเวลาในการปรับโครงสร้างและใช้ 3 อันดับแรกของสิ่งเลวร้ายเหล่านี้
• ค่าใช้จ่ายโดยประมาณสำหรับการดำเนินการ (อัตรารายชั่วโมงเช่นเดียวกับที่ใช้ด้านบน

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

• น้อยกว่า n เหตุการณ์การสนับสนุนเพิ่มเติม
• เหตุการณ์เหล่านี้จะไม่มีอีกต่อไปสำหรับสิ่งเหล่านี้ (แม้จะดีกว่า!)

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

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

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

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

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

ฉันกำลังเปลี่ยนอินเทอร์เฟซสาธารณะหรือไม่?

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

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

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

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

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

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

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