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

"พี่ครับ... Refactor กันไหม? โค้ดชุดนี้เริ่มอ่านยากแล้ว"

เมื่อไม่กี่วันก่อน น้อง Junior ในทีมเดินมาถามผมด้วยแววตามุ่งมั่น แต่สิ่งแรกที่ผมทำ ไม่ใช่การตอบตกลง แต่คือการ "เบรก" ความคิดนั้นทันที

ไม่ใช่เพราะผมไม่อยากให้โค้ดดีขึ้น แต่เพราะผมรู้ว่า... ถ้าเราวู่วาม "หายนะ" อะไรจะตามมาหลังจากนั้น

วันนี้ผมจะมาแชร์มุมมองในฐานะคนที่เคยเจ็บมาก่อนว่า ทำไมการ Refactor ถึงไม่ใช่ทางออกของโค้ดที่ไม่ดี และทำไม Tech Lead หลายคนถึงเบรกหัวทิ่มเมื่อคุณเสนอไอเดียนี้

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

ในอุดมคติการ Refactor คือการปรับโครงสร้างโค้ดให้ดีขึ้น

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

ฟังดูแล้วมีแต่ข้อดีใช่ไหมครับ? แล้วทำไม Senior หรือ Lead ถึงชอบห้าม?

คำตอบคือ: "Software ในโลกความจริง ซับซ้อนกว่าในตำราเสมอ"

เครดิตรูปภาพจาก MonkeyUser

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

Developer หลายคน (รวมถึงผมในอดีต) มักจะทนไม่ได้เวลาเห็นชื่อตัวแปรแปลกๆ หรือเห็น Logic ที่เขียนทับซ้อนกันแบบ Spaghetti Code เราจะคันไม้คันมืออยากแก้ให้มันเป็นระเบียบ เป็น Design Pattern ที่สวยงาม

แต่เราลืมไปว่า ภายใต้ความเละเทะนั้น มี Business Logic ที่ซับซ้อนซ่อนอยู่

ผมจำแม่นเลยสมัยเป็น Middle Level ผมเพิ่งเรียนรู้ Design Pattern ใหม่มาแบบสดๆ ร้อนๆ ตอนนั้นไฟแรงมาก ผมเพิ่งเข้าทำงานที่ใหม่วันแรก ตอนนั้นได้เปิดโค้ดดูปุ๊บ อุทานในใจเลยว่า "ทำไมมันเละแบบนี้(วะ)"

โค้ดอ่านยาก เทสก็ไม่ได้ Document ก็ไม่มี... ด้วยความที่บริษัทเป็น Software house เล็กๆ ที่ไม่ได้มี Senior จริงจัง ผมตัดสินใจ "รื้อ" ครับ ผมแก้ Codebase ครั้งใหญ่ให้เป็นท่าที่ผมถนัด เพราะเชื่อมั่นสุดหัวใจว่า "แบบนี้ดีกว่าชัวร์"

ผลลัพธ์เหรอครับ? แม้โค้ดจะสวยขึ้น Performance ดีขึ้น แต่ระบบพังพินาศ

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

สิ่งที่ผมทำพลาดไป คือผมไปแตะต้องระบบโดยที่ไม่มี Test Coverage ที่ดีพอ และที่สำคัญ ผมไม่เข้าใจบริบทของ Business

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

บทเรียนที่ผมได้คือ:

"โค้ดที่สวยแต่อ่านง่าย กับ โค้ดที่ทำงานได้แต่รก... ในมุมธุรกิจ โค้ดที่ทำเงินได้คือผู้ชนะครับ"

ถ้าเราแก้โค้ดจนสวย แต่ลูกค้าใช้งานไม่ได้ บริษัทเสียหาย นั่นคือความผิดพลาดที่ไม่น่าให้อภัยครับ

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

การ Refactor ไม่ใช่ Hero Task ที่ทำคนเดียวเงียบๆ แต่มันคือ Team Effort ถ้าคุณอยาก Refactor จริงๆ นี่คือ 3 ขั้นตอนที่ Tech Lead อยากเห็นจากคุณ:

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) รับรู้ตรงกัน

ถ้าทุกวันนี้คุณ Refactor โดยที่ PM ไม่รู้, Lead ไม่รู้, QA ไม่รู้... นั่นคือสัญญาณอันตรายครับ

เครดิตรูปภาพจาก Nutrient

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

ถ้ายัง Refactor ไม่ได้ จะทำยังไงกับ Legacy Code? แทนที่จะรื้อโค้ด ผมแนะนำให้เริ่มที่ "Documentation" ครับ

การทำ Document ช่วยลดความอีหยังวะของโค้ดได้โดยไม่ต้องเสี่ยงแก้โค้ด:

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

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

ก่อนจะเริ่ม Refactor ครั้งถัดไป ผมอยากให้ลองถามตัวเองดูครับว่า "สิ่งที่เรากำลังจะทำ มันคุ้มค่ากับความเสี่ยงของทีมจริงหรือเปล่า?"

การเขียนโค้ดดีเป็นเรื่องสำคัญครับ แต่การ "บริหารจัดการความเสี่ยง" และ "การสื่อสาร" สำคัญยิ่งกว่าในการก้าวขึ้นมาเป็น Senior หรือ Lead

อยาก Refactor? เชิญครับ... แต่วางแผนให้ดีก่อนนะครับ