ปรับปรุงระบบเก่าโดยไม่ต้องรื้อทำใหม่ทั้งหมด

ทำไม big-bang rewrite ถึงเสี่ยง

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

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

แนวทาง strangler: ค่อยๆ ให้ของใหม่เข้ามาแทน

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

วางตัวกลางไว้หน้าระบบ เช่น reverse proxy หรือ API gateway ที่ตัดสินว่า request ไหนไประบบเก่า ไหนไประบบใหม่ เริ่มจากส่วนที่แยกออกง่ายและเห็นผลชัด เช่น หน้าค้นหาสินค้า หรือหน้าสถานะคำสั่งซื้อ ไม่ใช่ส่วนที่ผูกกับทุกอย่างอย่างการคิดราคา

หา seam และวางชั้น API

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

จากนั้นวางชั้น API ครอบระบบเก่า เพื่อให้หน้าจอใหม่ แอปมือถือ หรือระบบอื่นเรียกผ่านชั้นนี้แทนการเข้าฐานข้อมูลตรงๆ ชั้น API จะซ่อนความยุ่งเหยิงด้านหลัง และเปิดทางให้เปลี่ยนด้านหลังภายหลังโดยผู้เรียกไม่ต้องรู้

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

• ไล่ดูการพึ่งพาระหว่างโมดูลและฐานข้อมูลที่ใช้ร่วมกัน
• เลือกส่วนแรกที่แยกง่ายและเห็นผลต่อผู้ใช้ชัด
• เขียนเทสต์บันทึกพฤติกรรมปัจจุบันก่อนเปลี่ยน
• วางชั้น API หรือ gateway เป็นประตูเดียว

การย้ายข้อมูลอย่างระวัง

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

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

การเปลี่ยนที่ย้อนกลับได้ ถูกกว่าการเปลี่ยนที่ต้องถูกต้องตั้งแต่ครั้งแรก

รันระบบเก่าและใหม่คู่กัน

ช่วงที่สองระบบอยู่ด้วยกันคือช่วงที่เสี่ยงที่สุด และมักยาวกว่าที่คาด ใช้ feature flag เปิดฟีเจอร์ใหม่ให้ผู้ใช้กลุ่มเล็กก่อน แล้วค่อยๆ ขยาย ถ้ามีปัญหาก็สลับกลับได้ในไม่กี่นาที โดยไม่ต้อง deploy ใหม่

ควรมี monitoring ที่เทียบสองฝั่ง เช่น ยอดคำสั่งซื้อ จำนวน error เวลาตอบ และกำหนดวันปิดระบบเก่าเป็นเป้าหมายจริง ไม่เช่นนั้นทั้งสองระบบจะอยู่คู่กันไปตลอดและต้นทุนดูแลเพิ่มเป็นสองเท่า