Refactor Code ไม่ใช่ทางออกของทุกสิ่ง: เมื่อความหวังดีอาจกลายเป็นหายนะของทีม

Refactor คืออะไรกันแน่?

• ✅ โค้ดอ่านง่ายขึ้น (Readability)
• ✅ ลดความซับซ้อน (Complexity)
• ✅ รองรับฟีเจอร์ใหม่ในอนาคต (Scalability)
• ✅ แก้ Bug ได้ง่ายขึ้น (Maintainability)

กับดักของคำว่า "Code ดี"

ปัญหาใหม่... ไฉไลกว่าเดิม

• โค้ดที่ผมคิดว่า "รก" จริงๆ แล้วมันคือ Logic ที่เขียนดัก Case ประหลาดๆ ของลูกค้าเอาไว้ ถึงแม้จะเขียนด้วยท่าที่แปลกมากๆ ก็ตาม
• พอผมไป Refactor ให้ "คลีน" Logic พวกนั้นหายไป
• ผลคือ: ระบบใช้งานไม่ได้ กระทบ UAT และเกือบกระทบ Production จริง

แล้วจะ Refactor ยังไง ให้ดูเป็น "มืออาชีพ"

1. Communicate (บอกทีมก่อนเสมอ) ห้ามแอบทำ! คุณต้องคุยกับ Tech Lead หรือ PM (Project Manager) ก่อนเสมอ เพราะการแก้โค้ดกระทบ Timeline และความเสี่ยงของโปรเจกต์
2. Plan (วางแผนและประเมินผลกระทบ) เรามีเวลาทำจริงๆ ไหม? อย่าลืมว่าการแก้ 1 จุด อาจต้องให้ QA Retest ใหม่ทั้งระบบ (Regression Test)

• Refactor ไม่ใช่งาน 5 นาทีเสร็จ
• ต้องรวมเวลา Code Design + Implementation + QA Testing เข้าไปในแผนด้วย

3. Formalize in Sprint (ทำให้เป็นงานจริงจัง) เลิกนิสัย "แอบแก้ตอนว่าง" แต่จงสร้าง Ticket หรือ Task เข้าไปใน Sprint เลย

• ระบุ Scope ให้ชัดว่าจะแก้อะไร
• ระบุเหตุผลว่าแก้แล้ว Business ได้อะไร (เช่น ลดเวลา Deploy, ลด Bug ในอนาคต)
• ทำให้ทุกคน (PM, QA, Dev) รับรู้ตรงกัน

แล้วจะทำอย่างไรในเมื่อ Code มันห่วย

1. High-level: เขียนภาพรวมว่า Module นี้ทำงานยังไง เชื่อมกับใครบ้าง
2. Low-level: อธิบาย Function/API ที่ซับซ้อน
3. Inline Comment: อันนี้สำคัญมาก ตรงไหน Logic ประหลาดๆ ให้ Comment แปะไว้เลยว่า "ทำไมถึงเขียนแบบนี้" (เช่น // Hack fix for old API legacy...) พร้อมแปะลิงก์ Jira Ticket อ้างอิง

คิดแบบ Leader ก่อนที่จะ Refactor