หลายๆ คนบอกว่า Refactoring
มันคือสิ่งที่ทำให้เสียเวลาไปโดยเปล่าประโยชน์
- เนื่องจากไม่รู้ว่าจะทำอะไร
- เนื่องจากไม่รู้ว่าจะทำอย่างไร
- เนื่องจากไม่รู้ว่าตัวเองไม่รู้อะไร
- เนื่องจากไม่รู้ว่าจะเปิด code ส่วนไหนมา refactor นะ
- เนื่องจากเราไม่ต้องการแก้ไข code อะไรนะ
- เนื่องจากเราไม่ต้องการเสียเวลาไปทั้งวันเพื่อ refactor code นะ
อย่างแรกที่ developer ต้องเข้าใจ ปละ ปฏิบัติคือ The Boy Scout Rule
มันก็ดีหรอกนะ แต่มันเสียเวลามากไปหรือเปล่านะ
มันไม่ค่อยสมเหตุสมผลเท่าไรนะ !! ว่าป่ะ ?
มาดูตัวอย่างในการ refactoring ที่สมเหตุสมผลกันหน่อย
การทำงานกับ Legacy Code
เมื่อเราเข้าไปแก้ไข code ของ Legacy code
แนะนำให้ยึดหลักของ Boy Scout Rule นั่นคือ
ก่อนแก้ไข หรือ เพิ่ม feature เข้าไปใน code
ให้ทำการตั้งคำถามกับตัวเองก่อนว่า
- Code มันพร้อมที่จะเพิ่ม feature ใหม่เข้าไปไหม ?
- ในการแก้ไขครั้งนี้ ต้องแก้ไข code กี่จุด ?
ถ้าคุณตอบคำถามข้อแรกว่า ไม่ เพิ่มยากมาก
ถ้าคุณตอบคำถามข้อที่สองว่า หลายจุดเลยนะ
นั่นหมายถึงว่า คุณต้องทำการ Refactoring code ได้แล้วนะ
เพื่อทำให้ code ที่มีอยู่ มันง่ายต่อการเพิ่ม code ชุดใหม่เข้าไป
คำถาม
แล้วจะแก้ไขให้ code มันอยู่ในรูปแบบไหนดีล่ะ ?
คำตอบ
ถ้าต้องการเพิ่ม code ใหม่เข้าไป
มันจะส่งผลกระทบกับระบบเดิมให้น้อย หรือ ไม่มีเลย
นั่นคือการเคารพในแนวคิดของ OCP (Open/Closed Principle) นั่นเอง
เมื่อเราคิดว่า code ชุดใหม่มันสามารถเพิ่มเข้าไปได้ง่าย
เมื่อเราคิดว่า code ชุดใหม่มันไม่กระทบกับของเก่า
ให้เริ่มเขียน code ชุดใหม่เข้าไปใน Legacy code ได้เลย
โดย code ชุดใหม่ที่เพิ่มเข้าไปนั้น
ควรที่จะทำการ refactoring แบบเล็กๆ อย่างต่อเนื่อง
ซึ่งนั่นก็คือ ขั้นตอนหนึ่งในแนวคิด TDD (Test-Driven Development)
ประกอบไปด้วย Red-Green-Refactor นั่นเอง
แต่ก่อนอื่นแนะนำเขียน code ให้มันทำงานได้ก่อน (Make it work)
จากนั้นทำให้ code มันดีขึ้น (Make it better)
ให้มันดีขึ้นเรื่อยๆ ที่ละเล็กละน้อย อย่างต่อเนื่อง
หัวใจสำคัญก็คือ Small และ Continuous Refactoring
และทำอย่างสม่ำเสมอ เพื่อทำให้ระบบมันดีขึ้นอย่างต่อเนื่อง
