5 สัญญาณว่า FiveM Script ของคุณต้องการ Refactor

Script ที่ใช้งานได้ไม่ได้แปลว่า script นั้นดี ในโลกของ FiveM development มี script จำนวนมากที่ "ทำงานได้" แต่กำลังสะสมปัญหาที่จะระเบิดออกมาในอนาคต

ถ้าคุณเคยรู้สึกว่า "แก้ bug นึงแล้วเกิด bug ใหม่" หรือ "กลัวจะแตะโค้ดเดิมเลย" — นั่นคือสัญญาณแรกแล้ว

---

สัญญาณที่ 1: แก้ที่เดียวต้องแก้หลายที่

สัญญาณที่ชัดที่สุดของ script ที่ต้องการ refactor คือเมื่อคุณต้องการเปลี่ยนแค่สิ่งเดียว แต่ต้องไปแก้หลายจุดในโค้ด

ตัวอย่างคลาสสิกใน FiveM: ระบบ permission ที่เขียนซ้ำไว้ในทุก script แยกกัน พอนายแบนระดับ permission หรือเปลี่ยนชื่อ group เพียงครั้งเดียว ต้องเปิดไฟล์ทีละไฟล์แล้วแก้ทีละจุด

นักพัฒนาเรียกปัญหานี้ว่า "code duplication" — ความซ้ำซ้อนที่สะสมมาจากการ copy-paste โดยไม่คิดถึงอนาคต สิ่งที่ควรทำคือรวม logic นั้นไว้ที่เดียว แล้วให้ทุกส่วนของระบบเรียกใช้จากจุดเดียวกัน

---

สัญญาณที่ 2: ไม่มีใครกล้า "แตะ" โค้ดเดิม

ในทีมพัฒนา FiveM หลายทีม มักมีไฟล์หนึ่งที่ไม่มีใครกล้าแก้ — มันทำงานได้ แต่ไม่มีใครรู้ว่าทำไม และถ้าแตะแล้วจะเกิดอะไรขึ้น

ความรู้สึกนี้เรียกว่า "fear of code" และมันเป็นอาการของ script ที่ซับซ้อนเกินจำเป็น ไม่มี structure ชัดเจน หรือไม่มีการจัดระเบียบ dependency ระหว่างส่วนต่างๆ

Script ที่ดีควรเป็นอะไรที่ "อ่านแล้วเข้าใจได้ภายใน 10 นาที" ถ้าแค่จะเปลี่ยนข้อความแสดงผลหรือปรับ cooldown เวลายังต้องนั่งอ่านโค้ดนาน 1 ชั่วโมง — มันถึงเวลา refactor แล้ว

---

สัญญาณที่ 3: Performance ลดลงโดยไม่รู้สาเหตุ

เซิร์ฟเวอร์ lag โดยไม่มีคนเพิ่มขึ้น — นี่คือสัญญาณอันตราย และมักมาจาก script ที่ทำงานซ้ำซ้อนโดยไม่จำเป็น

ปัญหาที่พบบ่อยใน FiveM คือ loop ที่ไม่เคย sleep — script ที่ตรวจสอบทุกอย่างทุก tick โดยไม่มีเงื่อนไขหยุดพัก, event ที่ถูก register ซ้ำหลายครั้ง, หรือการดึงข้อมูลจาก database ทุกครั้งที่มีการกระทำเล็กน้อย

เมื่อ script เติบโตขึ้นโดยไม่มีการ review architecture — performance debt สะสมเงียบๆ จนถึงจุดที่ผู้เล่นสังเกตเห็นได้เอง

---

สัญญาณที่ 4: Feature ใหม่ใช้เวลานานผิดปกติ

ถ้าการเพิ่ม feature เล็กน้อยต้องใช้เวลาหลายวัน ทั้งที่ฟังดูง่ายมาก — นั่นไม่ใช่ feature ที่ยาก แต่เป็น codebase ที่ต้านทานการเปลี่ยนแปลง

สาเหตุหลักคือ tight coupling — แต่ละส่วนของ script ผูกพันกันแน่นจนเปลี่ยนส่วนหนึ่งโดยไม่กระทบส่วนอื่นแทบเป็นไปไม่ได้ ต้องระวังทุกก้าว และ "ระวังทุกก้าว" คือสิ่งที่ทำให้การพัฒนาช้าลงโดยไม่จำเป็น

Script ที่มี architecture ดีจะให้ความรู้สึกตรงข้าม — เพิ่ม feature ใหม่รู้สึก "ง่าย" เพราะแต่ละส่วนแยกกันชัดเจน

---

สัญญาณที่ 5: Bug เดิมกลับมาซ้ำๆ

แก้ bug แล้ว ผ่านไปสองสัปดาห์ bug เดิมกลับมา — วนซ้ำแบบนี้หลายรอบ

ปัญหานี้ไม่ใช่แค่ว่าแก้ไม่ถูกจุด แต่เป็นสัญญาณว่า root cause ยังอยู่ และการแก้ที่ผ่านมาเป็นแค่การปิดอาการ ไม่ใช่การรักษาโรค

Refactoring ที่แท้จริงไม่ใช่การเขียนใหม่ทั้งหมด — มันคือการหา root cause แล้วจัดระเบียบโค้ดให้ bug ประเภทนั้นเป็นไปไม่ได้โดยธรรมชาติ

---

เมื่อไหร่ควร Refactor?

Refactoring ที่ดีที่สุดคือก่อนที่จะ "จำเป็น" ถ้ารอจนถึงจุดที่ script ทำงานไม่ได้ การแก้จะยากและเสี่ยงกว่ามาก

สัญญาณทั้ง 5 ข้อนี้เป็นเครื่องมือ early warning — ถ้าเห็นแค่ข้อเดียวก็ควรเริ่มวางแผน ถ้าเห็น 3 ข้อขึ้นไปในเวลาเดียวกัน ถือว่าเร่งด่วน

---

สรุป

สัญญาณ	ความหมาย
แก้ที่เดียวต้องแก้หลายที่	Code duplication สูง
ไม่กล้าแตะโค้ดเดิม	Complexity ไม่มี structure
Performance ลดโดยไม่รู้สาเหตุ	Hidden overhead สะสม
Feature ใหม่ใช้เวลานาน	Tight coupling
Bug เดิมกลับมา	ยังไม่แก้ root cause

Script ที่ดีไม่ใช่แค่ script ที่ทำงานได้ — มันคือ script ที่ทีมของคุณรู้สึก "สบายใจ" ที่จะแก้ไขและพัฒนาต่อ