คุณควรปรับปรุง แทนที่ หรือเลิกใช้ระบบเดิมเมื่อใด

Question

Accepted Answer

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

## คู่มือการตัดสินใจ

```text
REFACTOR (improve in place) when:
  - Core logic is sound; it's holding business value
  - Problems are localized; you can improve incrementally

REPLACE (rewrite/migrate) when:
  - It blocks important work and can't be incrementally fixed
  - Maintenance cost > rebuild cost over a sensible horizon
  - It's a growing security or reliability liability

RETIRE (remove entirely) when:
  - Its value no longer justifies any maintenance cost
  - Usage has dwindled; a simpler path exists
```

## ระวังกับดักการเขียนใหม่

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

## ตัวอย่างรูปธรรม

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

## ข้อขัดข้อง

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

## เหตุใดจึงสำคัญ

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

การทำให้การเรียกครั้งนี้ถูกต้อง บนหลักฐาน ไม่ใช่สุนทรีย์ เป็นหนึ่งในการตัดสินใจเดิมพันสูงสุดที่บทบาท TL อาวุโสทำ