การปรับปรุงวิศวกรรมซอฟต์แวร์

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

Definition

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

Scope

หัวข้อนี้ครอบคลุมถึงวิศวกรรมย้อนกลับ (reverse engineering) และการกู้คืนการออกแบบ (design recovery); การปรับโครงสร้างโค้ดและข้อมูล; การย้ายไปยังแพลตฟอร์ม ภาษา และสถาปัตยกรรมใหม่; การห่อหุ้ม (wrapping) และกลยุทธ์การปรับปรุงระบบเก่าแบบค่อยเป็นค่อยไป; การทดสอบเพื่อรักษาพฤติกรรมการทำงานระหว่างการเปลี่ยนแปลง; และเกณฑ์การตัดสินใจสำหรับการปรับปรุงวิศวกรรมเทียบกับการบำรุงรักษาต่อเนื่องหรือการเปลี่ยนใหม่

Core questions

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

Key theories

วิศวกรรมย้อนกลับและการกู้คืนการออกแบบ

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

การปรับปรุงระบบเก่าแบบค่อยเป็นค่อยไป

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

Clinical relevance

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

History

เมื่อระบบขนาดใหญ่ที่สร้างขึ้นในช่วงทศวรรษ 1960 ถึง 1980 มีอายุมากขึ้น วิศวกรรมย้อนกลับและการปรับปรุงวิศวกรรมได้กลายเป็นประเด็นที่แตกต่างกันในช่วงปลายทศวรรษ 1980 และ 1990 ซึ่งได้รับการจัดระเบียบโดยอนุกรมวิธานของ Chikofsky และ Cross; เทคนิคเชิงปฏิบัติสำหรับการจัดการโค้ดเก่าที่ยังไม่ผ่านการทดสอบได้ถูกจัดระบบโดย Feathers ในภายหลัง

Debates

การปรับปรุงวิศวกรรมแบบค่อยเป็นค่อยไปเทียบกับการเขียนใหม่ทั้งหมด

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

Key figures

• Elliot Chikofsky
• James Cross
• Michael Feathers

Seminal works

• chikofsky1990
• feathers2004
• sommerville2015

Frequently asked questions

การปรับโครงสร้างโค้ด (refactoring) กับการปรับปรุงวิศวกรรม (reengineering) แตกต่างกันอย่างไร?

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

ทำไมไม่เขียนระบบเก่าขึ้นมาใหม่ทั้งหมด?

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