การปรับปรุงโค้ดเก่าให้ทันสมัยต้องใช้โบราณคดีก่อน

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

นี่คือเหตุผลว่าทำไม “โบราณคดี” จึงมาก่อน “การเปลี่ยนแปลง” ดูที่ไฟล์บิลด์ก่อน จากนั้นจึงดูการขึ้นต่อกัน จากนั้นจึงดูสภาพแวดล้อมที่กำลังรันอยู่ จากนั้นจึงทดสอบ คำสั่งซื้อไม่สามารถย้อนกลับได้ build.xml ยังคงอยู่ แต่ไม่มี pom.xml สัญญาณดังกล่าวเพียงพอที่จะบ่งชี้ว่าโครงการอยู่ในยุคมด สามารถคอมไพล์โค้ดได้หรือไม่ การทดสอบสามารถทำงานได้หรือไม่ และสามารถสร้างผลิตภัณฑ์ขึ้นมาใหม่ได้หรือไม่นั้นเป็นหลักฐานแรก ส่วนที่มีประโยชน์ที่สุดของโมเดลที่นี่ไม่ใช่การเขียนโค้ดใหม่สำหรับโค้ดเก่าในทันที แต่เพื่อระบุหลักฐานเหล่านี้จากกองชิ้นส่วน

ต้องปักหมุดสภาพแวดล้อมก่อนด้วย โค้ดเก่ามักมาพร้อมกับ JVM เก่า คอนเทนเนอร์เก่า และสมมติฐานทางสถาปัตยกรรมเก่า โยนมันลงบนเครื่องในปัจจุบันโดยตรง โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมข้ามสถาปัตยกรรม และง่ายต่อการผสมสัญญาณรบกวนใหม่เมื่อเกิดปัญหา: โค้ดเสียหายโดยธรรมชาติ หรือเป็นการจำลอง การมิเรอร์ และห่วงโซ่เครื่องมือที่ทำให้เกิดปัญหา หากคุณไม่สามารถบรรลุ “โค้ดเดียวกันสามารถทำซ้ำได้อย่างเสถียรในสภาพแวดล้อมเดียวกัน” ในขั้นตอนนี้ การดำเนินการปรับปรุงให้ทันสมัยในภายหลังทั้งหมดจะเป็นเพียงการคาดเดา

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

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

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