ปรับระบบเก่าให้ทันสมัยก่อน และสร้างบันไดความเข้ากันได้

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

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

จากนั้นก็ถึงคราวเลือกสะพาน เป้าหมายของบริดจ์นั้นเจาะจงมาก: ปลายด้านหนึ่งเชื่อมต่อกับซอร์สโค้ดเก่า และปลายอีกด้านเชื่อมต่อกับเครื่องใหม่ ในที่สุดโปรเจ็กต์นี้ก็ตกไปอยู่ที่ Java 8 และ Gradle 7.6 ซึ่งเพิ่งติดอยู่กับข้อจำกัดของทั้งสองด้าน: Java 17 ไม่เต็มใจที่จะคอมไพล์ซอร์สโค้ดของ Java 1.5 อีกต่อไป และ Java 6 ไม่สามารถทำงานในสภาพแวดล้อมดั้งเดิมของ ARM64 หากบริดจ์ไม่ถูกต้อง การปรับปรุงให้ทันสมัยจะติดอยู่ในห่วงโซ่เครื่องมือ หากสะพานถูกต้อง การโยกย้ายครั้งต่อไปจะสามารถก้าวไปข้างหน้าทีละขั้นตอน

สิ่งที่มีประโยชน์ที่สุดในที่นี้คือการปล่อยให้โมเดลขนาดใหญ่จัดการและแปล สามารถช่วยแปลตรรกะของ Ant เป็น Gradle แมปไดเร็กทอรีกลับไปเป็นเลย์เอาต์เก่า และย้ายการกำหนดค่าที่ซ้ำซ้อนและเชิงกลเหล่านั้นออกไป ตัวอย่างเช่น ชี้ไดเร็กทอรีซอร์สโค้ดไปยังพาธเก่าอย่างชัดเจน และเพิ่มงานที่กำหนดเองเพื่อรันการทดสอบ main() แบบเก่า:

java {
    sourceCompatibility = JavaVersion.VERSION_1_5
    targetCompatibility = JavaVersion.VERSION_1_5
}
sourceSets {
    main {
        java {
            srcDirs = ['java']
        }
    }
}
tasks.register('runLegacyTest', JavaExec) {
    mainClass.set(project.findProperty('mainClass'))
    classpath = sourceSets.main.runtimeClasspath
}

ความสำคัญของการกำหนดค่านี้คือการทำให้กฎของโลกเก่าชัดเจน สิ่งที่ลำบากที่สุดในโปรเจ็กต์เก่าๆ มักไม่ใช่การขาดความสามารถ แต่ความสามารถนั้นซ่อนอยู่ในนิสัย การทดสอบจะดำเนินการผ่านรายการ main() ซอร์สโค้ดจะถูกวางไว้ในไดเร็กทอรีเก่า และบิลด์จะถูกเขียนโดยสมมติว่าเป็นเส้นทางในยุค Ant Copilot สามารถประหยัดเวลาได้ที่นี่ แต่ช่วยประหยัดเวลาในการแปล ไม่ใช่เวลาในการตัดสิน

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

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

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