ในการปรับปรุงระบบเก่าให้ทันสมัย Copilot จะจัดระเบียบหลักฐานก่อน

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

แก้ไขฉากก่อน แล้วการกระทำที่ตามมาจะมีความหมาย สิ่งที่มีค่าที่สุดในขั้นตอนนั้นไม่ใช่การดำเนินการให้เสร็จสิ้นใน IDE แต่เป็นกล่องที่สามารถเรียกใช้ซ้ำๆ ได้: JDK เก่า เครื่องมือบิลด์เก่า ทางเข้าเก่า และคำสั่งทดสอบเก่า ล้วนถูกล็อคไว้ใน Docker คำสั่งดังต่อไปนี้ไม่สวยงาม แต่ใช้งานได้:

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

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

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

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

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