ค่าเริ่มต้นคือ refactoring การเขียนใหม่จะมีเหตุผลก็ต่อเมื่อระบบเดิมไม่สามารถพัฒนาต่อให้ตอบโจทย์ความต้องการในต้นทุนที่ยอมรับได้อีกต่อไป และคุณยังส่งมอบคุณค่าได้ในระหว่างที่ทำ สัญชาตญาณ "เราต้องเขียนใหม่" ส่วนใหญ่จริง ๆ แล้วเป็นปัญหา tech debt ที่ไม่ได้บริหารจัดการ ซึ่ง refactoring ทีละน้อยแก้ได้ด้วยความเสี่ยงน้อยกว่ามาก
| สัญญาณ | เอนไป refactor | เอนไป rewrite |
|---|---|---|
| architecture พอดีกับความต้องการ | ใช่ | ไม่ |
| test/spec coverage | ต่ำหรือสูง | สูงพอที่จะยืนยันความเท่าเทียม |
| ship แบบ incremental ได้ | ใช่ | ยาก ต้องทำทีเดียวใหญ่ |
| ทีมเข้าใจโค้ด | ใช่ | ไม่ และผู้เขียนเดิมจากไปแล้ว |
การตัดสินใจ refactor-เทียบ-rewrite เป็นหนึ่งในการตัดสินใจที่มี leverage สูงที่สุดที่ Tech Lead ทำ ตัดสินผิดไปทางเขียนใหม่ คุณอาจแช่แข็งการส่งมอบหนึ่งปีและยังล้มเหลว; ตัดสินผิดไปทาง refactor คุณเสีย velocity อย่างช้า ๆ การวางกรอบเป็นการตัดสินใจด้านต้นทุนและความเสี่ยง ไม่ใช่การตัดสินใจด้านรสนิยม คือสิ่งที่แยกวิจารณญาณระดับ senior ออกจากความชอบส่วนตัว