Refactor หรือสร้างใหม่?

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

Legacy System ควรเปลี่ยนเมื่อไร?
ระบบเก่าที่ยังทำงานได้ ไม่ได้แปลว่าควรเก็บไว้ และระบบที่ดูล้าสมัย ไม่ได้แปลว่าควรรื้อทิ้ง คำถามที่ยากคือเส้นแบ่งอยู่ตรงไหน

ซื้อระบบใหม่ หรือปรับปรุงระบบเดิม?
กับดักต้นทุนจม กับกับดักการสร้างใหม่ทั้งหมด เลือกอย่างไรให้ซื่อสัตย์ต่อความจริง

AI สร้างระบบได้ แต่ใครจะดูแลอีก 10 ปี?
ระบบที่สร้างเสร็จในสองสัปดาห์ต้องอยู่กับธุรกิจอีกหลายปี บทความนี้ชวนคิดเรื่องการดูแลรักษา ความเป็นเจ้าของความรู้ และวันที่คนเขียนมันจากไป

เมื่อ AI ทำให้ Technical Debt โตเร็วกว่าที่คิด
ความเร็วในวันนี้มีราคาที่ทบต้นในวันหน้า บทความนี้ชวนมองว่า AI เร่งทั้งการสร้างและการสะสมหนี้ทางเทคนิคไปพร้อมกันอย่างไร
