ฉันจะใช้วิธีการใดเพื่อลดโอกาสที่จะแนะนำบั๊กใหม่ ๆ ในแอพที่ซับซ้อนแบบเก่า?

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

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

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

เริ่มเขียนแบบทดสอบสำหรับชิ้นส่วนที่คุณกำลังทำอยู่ คุณสามารถลองเวิร์กโฟลว์ที่มีลักษณะดังนี้:

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

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

คุณอาจพบว่าการทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกโดย Michael Feathers มีประโยชน์

ผมชอบที่จะทำตามลุงบ๊อบมาร์ติน 's ลูกเสือกฎ :

"เมื่อคุณมีมรดกที่ยุ่งเหยิงขนาดใหญ่สิ่งที่คุณต้องทำคือ ... สิ่งที่คุณต้องทำคือหยุดทำสิ่งยุ่งเหยิงและเริ่มทำความสะอาดมัน

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

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

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

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

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

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

เคล็ดลับอีกประการหนึ่ง เมื่อแมลงปรากฏตัวและหลังจากใช้ผ้าพันแผลอย่าหยุดอยู่แค่นั้น!

ถามห้า whys ใช้เม็ดสีแดงและดูว่ารูกระต่ายลึกไปและแก้ไขสาเหตุ (และเส้นทางลงที่นั่น)

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

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

// old code
...

if (!File.ReadAllText("c:\patch_control.txt").Contains("StrangeUIBugFix=0"))
{
    // new code goes here
    ...
}

// old + new code
int someValue = 
    IsEnabled("StrangeUIBugFix") ? a + b :  // new code
    a * b; // old code

สิ่งหนึ่ง: Never change any existing code if you are not sure what effect change would have on complete application.