เกือบทุกอย่างสามารถวิเคราะห์ได้ในแง่ของต้นทุนและผลประโยชน์และฉันคิดว่านี่ใช้ได้กับที่นี่
ประโยชน์ที่ชัดเจนของตัวเลือกแรกคือมันลดการทำงานในระยะสั้นและลดโอกาสของการทำลายบางสิ่งด้วยการเขียนรหัสการทำงานใหม่ ค่าใช้จ่ายที่เห็นได้ชัดคือมันจะนำเสนอรหัสที่ไม่สอดคล้องกัน เมื่อคุณทำการดำเนินการ X มันทำทางเดียวในบางส่วนของรหัสและอีกวิธีหนึ่งในส่วนต่าง ๆ ของรหัส
สำหรับวิธีที่สองคุณได้สังเกตเห็นประโยชน์ที่ชัดเจน: ความมั่นคง ค่าใช้จ่ายที่ชัดเจนคือคุณต้องงอใจที่จะทำงานในแบบที่คุณอาจทิ้งไว้เมื่อหลายปีก่อนและรหัสยังคงอ่านไม่ได้อย่างสม่ำเสมอ
สำหรับวิธีที่สามค่าใช้จ่ายที่ชัดเจนเพียงแค่ต้องทำงานให้มากขึ้น ค่าใช้จ่ายที่ชัดเจนน้อยลงคือคุณอาจทำลายสิ่งที่กำลังทำงานอยู่ นี่เป็นโอกาสโดยเฉพาะอย่างยิ่งหาก (เช่นในกรณีปกติ) รหัสเก่ามีการทดสอบไม่เพียงพอเพื่อให้มั่นใจว่าจะยังคงทำงานได้อย่างถูกต้อง ประโยชน์ที่ชัดเจนคือ (สมมติว่าคุณทำสำเร็จ) คุณมีโค้ดใหม่ที่ดีงาม นอกเหนือจากการใช้โครงสร้างภาษาใหม่คุณมีโอกาสที่จะสร้างฐานรหัสใหม่ซึ่งเกือบจะให้การปรับปรุงในตัวของมันเองแม้ว่าคุณจะยังคงใช้ภาษาตรงตามที่มีอยู่เมื่อมันถูกเขียน - เพิ่มในโครงสร้างใหม่ที่ทำให้ งานง่ายขึ้นและอาจเป็นชัยชนะครั้งสำคัญ
ประเด็นสำคัญอีกข้อหนึ่ง: ตอนนี้ปรากฏโมดูลนี้มีการบำรุงรักษาน้อยที่สุดเป็นเวลานาน (แม้ว่าโครงการโดยรวมจะได้รับการดูแล) ซึ่งมีแนวโน้มที่จะบ่งบอกว่ามันเขียนได้ค่อนข้างดีและปราศจากข้อผิดพลาด - มิเช่นนั้นอาจมีการบำรุงรักษาเพิ่มขึ้นในระหว่างกาล
นั่นนำไปสู่คำถามอื่น: แหล่งที่มาของการเปลี่ยนแปลงที่คุณทำอยู่ตอนนี้คืออะไร หากคุณกำลังแก้ไขข้อผิดพลาดเล็ก ๆ ในโมดูลที่โดยรวมยังคงเป็นไปตามข้อกำหนดที่ดีซึ่งก็มีแนวโน้มที่จะบ่งบอกว่าเวลาและความพยายามในการปรับโครงสร้างทั้งโมดูลนั้นมีแนวโน้มที่จะสูญเปล่าไปมาก - ตามเวลาที่ใครบางคน อีกครั้งพวกเขาอาจอยู่ในตำแหน่งเดียวกับที่คุณอยู่ตอนนี้โดยรักษารหัสที่ไม่เป็นไปตามความคาดหวัง "ทันสมัย"
อย่างไรก็ตามอาจเป็นไปได้ว่าข้อกำหนดนั้นเปลี่ยนไปและคุณกำลังทำงานกับโค้ดเพื่อให้ตรงกับข้อกำหนดใหม่เหล่านั้น ในกรณีนี้โอกาสที่ดีที่การพยายามครั้งแรกของคุณจะไม่เป็นไปตามข้อกำหนดปัจจุบัน นอกจากนี้ยังมีโอกาสมากขึ้นอย่างมากที่ความต้องการจะได้รับการแก้ไขสองสามรอบก่อนที่พวกเขาจะมีเสถียรภาพอีกครั้ง นั่นหมายความว่าคุณมีแนวโน้มที่จะทำงานสำคัญในโมดูลนี้ในระยะเวลาอันใกล้ (และค่อนข้างมาก) และมีแนวโน้มที่จะเปลี่ยนแปลงตลอดเวลาที่เหลือของโมดูลไม่ใช่เฉพาะในพื้นที่ที่คุณรู้ ตอนนี้ ในกรณีนี้การปรับโครงสร้างโมดูลใหม่ทั้งหมดมีแนวโน้มที่จะได้รับผลประโยชน์ที่จับต้องได้ในระยะเวลาอันใกล้
หากข้อกำหนดมีการเปลี่ยนแปลงคุณอาจต้องพิจารณาประเภทของการเปลี่ยนแปลงที่เกี่ยวข้องและสิ่งที่ขับเคลื่อนการเปลี่ยนแปลงนั้น ตัวอย่างเช่นสมมติว่าคุณกำลังแก้ไข Git เพื่อแทนที่การใช้ SHA-1 ด้วย SHA-256 นี่เป็นการเปลี่ยนแปลงข้อกำหนด แต่ขอบเขตมีการกำหนดไว้อย่างชัดเจนและค่อนข้างแคบ เมื่อคุณจัดเก็บและใช้ SHA-256 อย่างถูกต้องแล้วคุณไม่น่าจะพบกับการเปลี่ยนแปลงอื่น ๆ ที่มีผลต่อส่วนที่เหลือของรหัสฐาน
ในอีกทางหนึ่งแม้ว่ามันจะเริ่มเล็กและไม่ต่อเนื่องการเปลี่ยนอินเทอร์เฟซผู้ใช้ก็มีแนวโน้มที่จะเกิดบอลลูนดังนั้นสิ่งที่เริ่มต้นเมื่อ "เพิ่มกล่องกาเครื่องหมายใหม่ลงในหน้าจอนี้" จบลงเช่น: "เปลี่ยน UI คงที่นี้ เพื่อสนับสนุนเทมเพลตที่ผู้ใช้กำหนดฟิลด์ที่กำหนดเองชุดรูปแบบสีที่กำหนดเอง ฯลฯ "
สำหรับตัวอย่างก่อนหน้านี้มันอาจเหมาะสมที่สุดที่จะลดการเปลี่ยนแปลงและความผิดพลาดในด้านความมั่นคง สำหรับหลังการเปลี่ยนโครงสร้างใหม่อย่างสมบูรณ์มีแนวโน้มที่จะจ่ายมากขึ้น