ในการพัฒนา software นั้น มักมีสิ่งที่เราไม่ต้องการเกิดขึ้นมาเสมอ นั่นก็คือ Technical Debt หรือ หนี้ทางเทคนิค
เพราะว่า นักพัฒนาไม่ได้ทำตามแนวปฎิบัติของการเขียน code ที่ดี
รวมทั้งไม่มีการทำ Refactoring code และ Code review อยู่อย่างเสมอ
แต่เราจะรู้ได้อย่างไรว่าสิ่งที่พัฒนาอยู่มันเริ่มมีปัญหาแล้ว
ดังนั้น เรามาดูสัญญาณเตือน ที่จะบอกว่า ทีม คุณต้องทำการ Refactoring code แล้วนะ !!!
อ้างอิงมาจากบทความเรื่อง 14 Code Refactoring smells you can easily sense and What you can do about it?
ในบทความทำการอธิบายเกี่ยวกับสัญญาณเตือนต่างๆ
เพื่อช่วยบอกว่า ทีมควรจะเริ่มทำการ Refactoring code ได้แล้วนะ มีดังต่อไปนี้
1. ทีมใช้เวลานั้นการพัฒนาแต่ละ feature นานกว่าที่คิดหรือวางแผนไว้มาก
2. เกิด bug จำนวนมาก หลังจากที่ทำการส่งมอบงาน
3. คุณภาพของงานตกลงไปเรื่อยๆ
4. ทีมรู้สึกท้อแท้ สิ้นหวัง มากขึ้นเรื่อยๆ เมื่อต้องทำการแก้ไข code
5. ทีมรู้สึกกลัวหรือไม่กล้า เมื่อต้องไปแตะ code ในส่วนใดส่วนหนึ่ง
6. สมาชิกในทีมรู้สึกว่างานในส่วนที่ตัวเองทำมันสบายมากๆ
7. ทีมรู้สึกท้อแท้ สิ้นหวัง เมื่อต้องทำการประเมินเวลาในการแก้ไข code
8. ทีมเกิดความคิดว่า เราเขียน code ขึ้นมาใหม่ดีกว่า ไปทำงานอยู่บน code เดิม หรือ Legacy code
9. แก้ไข bug แล้วไปทำให้เกิด bug ใหม่ๆ ขึ้นมาอีก
10. ทีมต้องการเวลาในการพัฒนาเพิ่ม สำหรับทำการ Refactoring code
11. ทีมใช้เวลาในการ debug ระบบงาน สูงมากๆ
12. ถ้าคุณไปอ่าน code จะพบว่า code มันอ่าน และ ทำความเข้าใจยากมาก
13. ทำการเปลี่ยนแปลงสิ่งที่เหมือนเดิม ซ้ำๆ กันในหลายๆ จุด นั่นบอกว่า code ของระบบมีความซ้ำซ้อน
14. มี functional test เยอะไปหมด เช่น UI Test แต่พวก unit test และ integration test น้อยมากๆ
มันสะท้อนว่า ระบบงานนั้นออกแบบมาไม่ดีเท่าไร
เพราะว่า code มันจะยากต่อการทดสอบด้วย unit test และ integration test
ดังนั้น เมื่อทีมคุณอยู่ในสถานการณ์ดังกล่าวแล้ว สิ่งที่ทีมควรต้องทำก็คือ
1. ทีมควรที่จะหยุด และมานั่งคุยกันว่าปัญหามันอยู่ตรงไหน และส่งผลอย่างไร
2. หาต้นเหตของปัญหา ว่ามาจากไหนกัน
ถ้าทีมไม่สามารถแก้ไขปัญหาเองได้แล้ว ทางเลือกสุดท้ายก็คือ จ้างผู้ชำนาญการมาช่วยแนะนำ
เพื่อให้ feedback และความเห็นต่างๆ ได้
3. ทำการระบบจุดที่มีปัญหามากๆ เพื่อจะได้ทำการ Refactoring code ต่อไป
4. วางแผนที่จะทำการ Refactoring code
5. เริ่มลงมือทันที
แต่ถ้าเป็นมุมมองของฝ่าย manager ทั้งหลาย มักจะมองว่า
การทำ Refactoring code นั้นเป็น overhead
ไม่ควรลงทุนไปกับมันหรอกนะ เอาเวลาและความสนใจไปที่การพัฒนาของใหม่ๆ เถอะนะ
แต่ในความเป็นจริง คุณจำเป็นต้องลงทุนเพื่ออนาคตที่สดใส
และเป็นการปรับปรุงคุณภาพของทีมให้ดีขึ้นอีกด้วย
สุดท้ายมันจะส่งผลให้ทีมพัฒนางานออกมาได้ดี เร็วขึ้นอีกด้วย
แล้วการ Refactoring code มันสามารถวางแผนทำอย่างไรได้บ้าง
ทีมสามารถที่จะเลือกหรือวางแผนการ Refactoring code ได้หลายแบบขึ้นอยู่กับทีม
เช่น Refactor Sprint/Iteration, ทำกันทุกๆ อาทิตย์ ทุกๆ วัน หรือ ทุกๆ ชั่วโมง
แต่ถ้าเป็นผมแนะนำให้ทำจนกลายเป็นนิสัยไปเลย
โดยจะต้องทำการสอนและแนะนำแนวปฏิบัติต่างๆ เช่น
- Test-Driven Development (TDD) ซึ่งมันบังคับให้คุณเขียน unit test และ refactoring code อยู่เสมอ
- ทำการ Refactoring code มันคือกิจกรรมที่ต้องเกิดขึ้นอยู่บ่อยๆ หรือ ตลอดเวลา บน code เล็กๆ ไปเรื่อยๆ อย่างสม่ำเสมอ
- แนะนำ และ แบ่งปัน ในเรื่องวิธีการ Refactoring code ในรูปแบบต่างๆ กันภายในทีม
ผลที่ตามมาก็คือ
code ของคุณจะมีคุณภาพที่ดีอยู่ตลอดเวลา และ จะดีขึ้นเรื่อยๆ อีกด้วย
จะทำให้คุณไม่ต้องมาเสียเวลาทำการ Refactoring code แบบใหญ่ๆ อีกต่อไป
ยอมรับเถอะว่า การ Refactoring code แบบใหญ่ๆ มันยาก เยอะ และ ทำให้ทีมรู้สึกท้ออย่างมาก
รวมไปถึงผลลัพธ์ที่ออกมานั้นก็ไม่ได้ดีดังคาดหวังอีกด้วย
บางครั้งจนอยากจะเขียนใหม่ง่ายกว่านะ สุดท้ายก็ไม่มีอะไรดีขึ้นอยู่ดี
ดังนั้นลองมองกลับที่ทีมของคุณ
ว่ากำลังเผชิญกับสัญญาณเตือนต่างๆ เหล่านี้หรือไม่
ถ้าใช่ ก็ถึงเวลาที่คุณควรต้องทำการ Refactoring code ได้แล้วนะครับ
ปล่อยไว้นาน มันจะกลับมาทำร้ายคุณเอง
… สร้างโดยทีม เพื่อทำร้ายทีม ..
