สิ่งเล็ก ๆ ที่เรียกว่า Legacy code นั้น
มักเป็นสิ่งที่ไม่มีใครชอบ
แต่แปลกนะว่า มักจะมีคุณค่า หรือ สร้างรายได้ให้กับองค์กร !!
จำนวนของ Legacy code นั้นมักมีจำนวนมากมาย
เกินกว่าที่เราจะจัดการมันได้
ดังนั้นเราจะตัดสินใจอย่างไรว่า
- code ส่วนไหน ต้องทำการ refactor ?
- code ส่วนไหน ไม่จำเป็นต้อง refactor ?
- ถ้าระบบงานมันทำงานได้ดีอยู่แล้ว จะต้องทำการ refactor หรือไม่ ?
ยิ่งกว่านั้นการ refactor code มันมีความเสี่ยง และ ค่าใช้จ่ายสูง
ดังนั้น เราต้องการมีตัวช่วยหน่อยสิว่า เมื่อไรควรที่จะ refactor ดี
1. เมื่อ code ส่วนนั้นสำคัญ และ ยากต่อการดูแลรักษา
ระบบงานส่วนใหญ่นั้น มักจะยาก และ เสี่ยงมาก ต่อการ refactor !!
ดังนั้นจึงมีความคิดว่า
ถ้าระบบงานมันทำงานได้ดีบน production server แล้ว
เราก็ไม่ควรไปแก้ไข หรือ แตะต้องมัน
ไม่เช่นนั้น งานจะเข้าตัวเอาได้ !!
อะไรที่มันทำงานได้อยู่แล้ว อย่าไปยุ่งกับมันเลย !!
แต่เมื่อเวลาผ่านไป code เหล่านั้น เริ่มเป็นภาระให้ลูกหลาน
เช่นต้องทำการแก้ไข และ เพิ่มเติมอยู่ตลอดเวลา
ทำให้ codeมันเริ่มน่ากลัวขึ้นเรื่อย ๆ รวมทั้งใช้เวลามากขึ้นเรื่อย ๆ
ดังนั้น ได้เวลาทำการ refactor code ชุดนั้นซะ
แต่จะมั่นใจได้อย่างไร ว่า refactor แล้วระบบจะไม่พัง
ก็ทำการเพิ่มชุดของการทดสอบไปด้วยนั่นเอง
2. ใน code ชุดนั้นมีคนที่รู้เพียงคนเดียว
ถ้ามีคนที่รู้ และ เข้าใจ code ชุดนั้นเพียงคนเดียว
มันจะทำให้เกิดปัญหาเมื่อคนคนนั้นไม่อยู่ ไม่ว่าง หรือ ลาออกไป
คุ้น ๆ ไหมว่า ในทุก ๆ องค์กรมักจะเกิดเหตุการณ์แบบนี้เสมอ !!
คนเหล่านั้น มักจะถูกเรียกว่า Expert หรือ Hero หรือ Leader
และมักจะมีงานอยู่ในมือจำนวนมาก
สิ่งที่กลุ่มคนเหล่านี้ถือครอง จะไม่มีใครกล้าแตะต้องเลย
ใครมีปัญหาอะไร มาหาคนกลุ่มนี้ได้เลย เขาช่วยได้เสมอ
ผลทำให้การแก้ไข และ ดูแล code ส่วนนี้
จะใช้เวลาที่ยาวนาน
จะใช้ค่าใช้จ่ายที่สูงมาก
เพราะว่าต้องรอให้ Expert ว่างมาทำ
ดังนั้นได้เวลาสำหรับการ refactor code เหล่านั้นแล้ว
เพื่อให้คนอื่น ๆ เข้าใจ และ สามารถดูแลต่อไปได้
และพยายามหลีกเลี่ยงสถานการณ์ดังกล่าวไว้เสมอ
3. เมื่อคุณเรียนรู้มากขึ้น รู้ว่าโครงสร้างที่ดีกว่าเดิมเป็นอย่างไร
ความเข้าใจต่อ requirement
ความเข้าใจต่อ ระบบงาน
มันจะเปลี่ยนแปลงอยู่ตลอดเวลา
นั่นหมายถึง เรามีโอกาสที่จะเปลี่ยนแปลงการออกแบบ และ โครงสร้าง ให้ดีขึ้น
และเหมาะสมกับการเปลี่ยนแปลงนั้น ๆ
นั่นคือ เราได้ทำการ refactor code อยู่ตลอดเวลา
ส่งผลให้เราทำการดูแล code ให้มัน CLEAN
และมีคุณภาพที่ดีอยู่อย่างสม่ำเสมอ
4. เมื่อทำการแก้ไข Bug หรือ Bug-Driven Development
สิ่งเล็ก ๆ ที่เรียกว่า Bug มันคือ
สิ่งที่บอกว่า การออกแบบของเรามันผิดพลาดตรงไหน
Bug ที่เกิดขึ้นใน code มักมีสาเหตุมาจาก
ปัญหาของ development process นั่นเอง
Bug มักจะเกิดมาจาก ขาดการทดสอบ
หรือ code ชุดนั้นไม่มีชุดของการทดสอบ
สาเหตุหลักของการไม่มีชุดทดสอบ คือ มันทดสอบได้ยาก หรือ ทดสอบไม่ครบ
นั่นมันบ่งบอกว่า code ที่สร้างขึ้นมามันยากนะสิ !!
ดังนั้น ให้ทำการ refactor code ชุดนั้นซะ
เพื่อทำให้มันง่ายต่อการเขียน test
จากนั้นก็สร้างชุดการทดสอบขึ้นมา
จากนั้นให้ทำการแก้ไข Bug เหล่านั้นซะ
เพื่อให้ชุดการทดสอบนั้นผ่านทั้งหมด
และทำแบบนี้ไปเรื่อย ๆ
มันส่งผลให้ Legacy code มันดีขึ้น ลดความเสี่ยงลงไปเรื่อย ๆ
คุณเริ่มทำได้เลยนะ …
5. เมื่อทำการเพิ่ม feature ใหม่ ๆ เข้าไปใน Legacy code
มันคือวิธีการที่ถูก และ ความเสี่ยงน้อยสุด ๆ
เมื่อเราต้องการเพิ่ม feature ใหม่ เข้าไปยัง Legacy code
ก่อนอื่น ให้ทำการพิจารณาก่อนว่า
Legacy code ชุดนั้นมันง่ายต่อการเพิ่ม feature หรือไม่ ?
ถ้าตอบว่า มันยากนะ
ให้ทำการ refactor code ชุดนั้นก่อน
หลังจากนั้นจึงทำการเพิ่ม feature ต่อไป
แล้ว Legacy code มันจะน่ากลัวน้อยลง
ปล. ห้ามทำการ refactor code และ เพิ่ม feature พร้อมกันโดยเด็ดขาด
Do one thing at a time นะครับ
สุดท้ายแล้ว
มาทำให้ Legacy code มันไม่น่ากลัว
มาทำให้ Legacy code มันดูแลรักษาได้ง่ายขึ้น
มาให้ให้ Legacy code มันทำงานด้วยได้ง่าย
ดังนั้นมาทำ Refactor กันครับ
แต่ค่อย ๆ ทำ ให้มันดีขึ้นอย่างต่อเนื่อง
