บทความเรื่อง How the Medium iOS team works effectively with legacy code
อธิบายถึงแนวทางในการทำงานกับ Legacy code
ในฝั่งของ iOS App team ของ Medium.com ว่าเป็นอย่างไรบ้าง ?
โดยแนวทางการทำงานจะอ้างอิงมาจากหนังสือ Working effectively with legacy code
มาเริ่มกันเลย
"Legacy Code is code without tests"
เริ่มจากที่มาของ iOS app ของ Medium.com นั้นมีอายุมากกว่า 10 ปีแล้ว
ซึ่ง code หลาย ๆ ส่วนตั้งแต่เริ่มต้น ยังคงถูกในงานใน app ปัจจุบัน
ดังนั้นในทุกวัน ทีมพัฒนายังต้องทำงานกับ code เก่า ๆ
โดยทีมพัฒนาทำการสรุปว่ามีแนวทางในการจัดการ code เก่า ๆ เหล่านี้อย่างไรบ้าง ?
เริ่มต้นด้วยเรื่องของการเปลี่ยนแปลง
แน่นอนว่า ยังต้องแก้ไข และ เพิ่มความสามารถต่าง ๆ เข้ามาใน app อย่างต่อเนื่อง
แถมต้องไม่ส่งผลกระทบ หรือ ส่งผลต่อระบบน้อยมาก ๆ ด้วย
หรือช่วยทีมพัฒนาสามารถส่งมอบ feature ให้ทาง business ได้อย่างสม่ำเสมอ
ยกตัวอย่างเช่นการระบบการ render ของ app
ที่ทำการ rewrite ไปบางส่วน
แต่วันดีคืนดีต้องทำการเพิ่มความสามารถใหม่ ๆ เข้าไป
ดังนั้นจำเป็นต้องไปแก้ไข code เก่า ๆ
ทำอย่างไรที่จะลดการแก้ไข code เก่า ๆ ที่มีความซับซ้อนลงไป
หนึ่งในวิธีการที่เลือกใช้จากหนังสือข้างต้น คือ Sprouts (Sprout method or Sprout class)
แนวทางที่ทีมพัฒนาใช้งานคือ
สร้างส่วนการทำงานใหม่ขึ้นมา จากนั้นค่อย embedded ส่วนใหม่เข้าไป
โดยในส่วนใหม่จะพัฒนาด้วย SwiftUI
สร้างเป็น SPM module (Swift Package Manager)
จากนั้นก็เรียกใช้งาน แล้ว render ด้วย UIKit ของระบบ render ที่สร้างเอาไว้
ซึ่งช่วยให้ง่ายต่อการเพิ่มความสามารถใหม่ ๆ และลดผลกระทบลงไป
แถมได้ใช้ technology ใหม่ ๆ อีกด้วย
ปัญหาต่อมาคือ ไม่เข้าใจ code เก่า ๆ เหล่านั้นดีพอ ก่อนที่จะแก้ไขมัน
ปัญหานี้เกิดขึ้นบ่อยมาก ๆ
ทำให้ solution ในการแก้ไขมักจะผิด หรือ สร้างความซับซ้อนเพิ่มเข้ามาได้อีก
ดังนั้นแค่ทำให้มันทำงานได้ยังไม่เพียงพอ
แต่ยังต้องปรับปรุงมันให้ดียิ่งขึ้นด้วยเสมอ
ปัญหาต่อมาคือ App ไม่มีโครงสร้างที่ชัดเจน !!
แต่การที่จะหยุดการพัฒนา เพื่อปรับปรุงโครงสร้างของ code ใหม่เป็นเดือน ๆ
น่าจะไม่ใช้แนวคิดที่ดีนัก
ดังนั้นจึงใช้แนวทาง ๆ ค่อย ๆ เปลี่ยนโครงสร้างทีละเล็กทีละน้อยแทน
โดยจะมีรูปแบบของ modular ที่กำหนด และ ตกลงกันไว้
และตกลงกันไว้ว่า จะไม่เพิ่ม code เข้าไปยัง code เดิม
ซึ่งช่วยให้การพัฒนาง่ายและรวดเร็วมากยิ่งขึ้น
ปัญหาต่อมาคือ ถ้า class มันใหญ่มากแล้ว ยังจะเพิ่ม code เข้าไปอีกหรือ ?
โดยโครงสร้าง หรือ code ของระบบงานมันอาจจะทำงานได้ดี
มี function การทำงานต่าง ๆ ครบ
แต่ว่ามันเอื้อต่อการพัฒนาต่อไปหรือไม่ ?
ดังนั้นแนวทางคือ เรื่องของ responsibility หรือ หน้าที่รับผิดชอบ
ว่ามีหน้าที่รับผิดชอบเยอะเกินไปไหม
ถ้าใช่ ก็พยายามแยกออกมาจากกัน
แต่ปัญหาต่อมาจากการเปลี่ยนแปลง ปรับปรุงสิ่งต่าง ๆ คือ
เราจะรู้ได้อย่างไร ว่ายังคงทำงานได้เช่นเดิม
ไม่ไปทำให้ code หรือ การทำงานส่วนอื่น ๆ ไม่พัง หรือ กระทบ !!
เพราะว่ามันคือ การ refactor code นะ
วิธีการที่ใช้งานประกอบไปด้วย
- Preserve signature
- Lean on the compiler
เรื่องสุดท้ายคือ To rewrite or not to rewrite
เป็นคำถามที่น่าสนใจมาก ๆ
แต่จากบทความนี้ ไม่ทำการ rewrite ทั้งหมดแน่นอน
แต่ใช้แนวทางในการทำงานร่วมกับ code เก่า ๆ
ปรับปรุง และ ลด code เก่าลงไป
จากนั้นก็เพิ่ม code ใหม่ ที่จัดการ หรือ ควบคุมได้ดียิ่งขึ้นเข้ามา
ค่อย ๆ ปรับเปลี่ยนทีละเล็กละน้อย ค่อย ๆ นำ technology ใหม่ ๆ เข้ามาใช้
แค่ให้ code มันทำงานได้ยังไม่เพียงพอ ต้องให้มันดีขึ้นด้วยเสมอ
รวมทั้งก่อนแก้ไข ต้องทำความเข้าใจให้ดีก่อนว่า code เหล่านั้นทำงานอย่างไร
Good design should be a goal for all of us, but in legacy code, it is something that we arrive at in discrete steps.
ลองนำไปประยุกต์ใช้งานกันดูครับ
ขอให้สนุกกับการ coding