Refactor คือการจัดโค้ดให้ดีขึ้น โดยไม่เปลี่ยนพฤติกรรมของระบบ

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

Refactor คือการ ปรับโครงสร้างภายในของโค้ดให้ดีขึ้น โดยที่ พฤติกรรมของระบบยังเหมือนเดิม ผู้ใช้ยังใช้งานได้เหมือนเดิม ฟีเจอร์ยังทำงานแบบเดิม แต่ภายในโค้ดจะอ่านง่ายขึ้น แก้ไขง่ายขึ้น และรองรับการเปลี่ยนแปลงในอนาคตได้ดีขึ้น

ทำไมการ refactor จึงสำคัญ

ในงานพัฒนาซอฟต์แวร์จริง การ refactor ไม่ใช่งานหรูหราที่ค่อยทำทีหลังเมื่อมีเวลา แต่เป็นทักษะสำคัญที่ช่วยให้ทีมทำงานได้เร็วและปลอดภัยขึ้น

หากโปรเจกต์เต็มไปด้วยโค้ดก้อนใหญ่ ฟังก์ชันยาวหลายร้อยบรรทัด ชื่อตัวแปรไม่ชัดเจน และมี logic ซ้อนกันหลายชั้น การเพิ่มฟีเจอร์ใหม่เข้าไปทันทีมักทำได้เร็วแค่ในระยะสั้น แต่จะทำให้การดูแลระบบในวันต่อ ๆ ไปยากขึ้นเรื่อย ๆ

โปรแกรมเมอร์ที่มีประสบการณ์จึงมักยอมใช้เวลาเล็กน้อยเพื่อจัดระเบียบโค้ดก่อนลงมือเพิ่มของใหม่ เพราะรู้ดีว่าการลงทุนตรงนี้จะช่วยลดปัญหาในอนาคตได้มาก

ตัวอย่างของการ refactor ที่เห็นภาพชัด

ลองนึกถึงกรณีที่มีโค้ดคำนวณราคาซ้ำอยู่หลายจุดในระบบ เช่น 5 ตำแหน่ง หากวันหนึ่งต้องเพิ่มเงื่อนไขส่วนลดใหม่ นักพัฒนาอาจต้องไล่แก้ทั้ง 5 จุด และยังมีโอกาสลืมบางตำแหน่ง

แต่ถ้า refactor โค้ดให้เหลือจุดคำนวณกลางเพียงจุดเดียว เช่น calculateFinalPrice() การเปลี่ยนกติกาในอนาคตจะง่ายขึ้นมาก แก้ครั้งเดียว และลดความเสี่ยงจากความไม่สอดคล้องกันของระบบ

นี่คือประโยชน์สำคัญของการ refactor: ลดความซ้ำซ้อน และทำให้การเปลี่ยนแปลงเกิดขึ้นได้อย่างปลอดภัยกว่าเดิม

สิ่งที่มักทำในการ refactor

การ refactor ไม่จำเป็นต้องเป็นงานใหญ่เสมอไป หลายครั้งเป็นเพียงการปรับเล็ก ๆ ที่ส่งผลดีมาก เช่น

• แยกฟังก์ชันที่ยาวเกินไปออกเป็นส่วนย่อย
• ตั้งชื่อตัวแปรหรือฟังก์ชันให้สื่อความหมายชัดเจนขึ้น
• ลบโค้ดที่ซ้ำกัน
• แยก logic ที่ปนกันอยู่ให้ออกเป็นคนละส่วน
• จัดโครงสร้างโค้ดให้รับผิดชอบหน้าที่ชัดเจนขึ้น

การเปลี่ยนแปลงเล็ก ๆ เหล่านี้ช่วยให้โค้ดอ่านง่ายขึ้น เข้าใจง่ายขึ้น และลดโอกาสที่นักพัฒนาจะตีความผิดเมื่อต้องกลับมาแก้ในภายหลัง

วิธี refactor ที่ดีควรทำอย่างไร

หลักสำคัญของการ refactor คือ ทำเป็นก้าวเล็ก ๆ ไม่ใช่รื้อทั้งระบบในครั้งเดียว

แนวทางที่ดีคือค่อย ๆ ปรับทีละจุด เช่น

• เปลี่ยนชื่อให้ชัดขึ้นหนึ่งตำแหน่ง
• แยกฟังก์ชันออกมาหนึ่งก้อน
• ลบ duplication ออกหนึ่งชุด
• รันทดสอบทุกครั้งหลังแก้ไข

เหตุผลที่ควรทำแบบนี้ เพราะเป้าหมายของ refactor คือทำให้โค้ดดีขึ้นโดย ไม่เปลี่ยนผลลัพธ์ของระบบ ถ้าปรับครั้งละเล็กน้อยและมีการทดสอบประกอบ จะช่วยลดโอกาสสร้างบั๊กใหม่โดยไม่ตั้งใจ

สัญญาณว่าโค้ดควร refactor

หากพบอาการต่อไปนี้ในโปรเจกต์ นั่นอาจเป็นสัญญาณว่าโค้ดควรได้รับการปรับปรุงแล้ว

• อ่านโค้ดแล้วต้องใช้เวลานานกว่าจะเข้าใจ
• แก้จุดหนึ่งแล้วรู้สึกกลัวว่าจะพังอีกหลายจุด
• มี if ซ้อนกันหลายชั้นจนตาม flow ยาก
• ฟังก์ชันเดียวทำหลายหน้าที่เกินไป
• มีโค้ด copy-paste กระจายอยู่ทั่วโปรเจกต์

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

มือใหม่ควรเริ่ม refactor อย่างไร

สำหรับคนที่เพิ่งเริ่มต้น ไม่จำเป็นต้องรอให้มีช่วงเวลาพิเศษหรือ sprint ใหญ่เพื่อทำ refactor

วิธีง่ายที่สุดคือ เมื่อจำเป็นต้องแก้ฟีเจอร์เดิม ให้ใช้โอกาสนั้นปรับโค้ดบริเวณที่แตะให้ดีขึ้นเล็กน้อย เช่น

• เปลี่ยนชื่อที่อ่านยากให้ชัดขึ้น
• แยกส่วนที่ซ้ำออกมาเป็นฟังก์ชันเดียว
• ตัด logic ที่ปนกันให้เป็นระเบียบขึ้น

แนวคิดนี้ช่วยให้คุณไม่ต้องแบกรับงาน refactor ก้อนใหญ่ในอนาคต และทำให้คุณภาพของโปรเจกต์ดีขึ้นแบบค่อยเป็นค่อยไป

สรุป

Refactor ไม่ใช่การเสียเวลา และไม่ใช่การเขียนใหม่เพราะไม่ชอบโค้ดเดิม แต่คือการลงทุนเล็ก ๆ เพื่อทำให้โค้ดอ่านง่าย แก้ง่าย และรองรับการเปลี่ยนแปลงได้ดีขึ้น โดยที่พฤติกรรมของระบบยังคงเหมือนเดิม

เมื่อทำอย่างสม่ำเสมอ การ refactor จะช่วยให้การเพิ่มฟีเจอร์ใหม่เร็วขึ้น ลดโอกาสเกิดบั๊ก และทำให้โปรเจกต์ไม่กลายเป็นกับดักของโค้ดเก่าที่ไม่มีใครกล้าแตะ

สุดท้ายแล้ว เป้าหมายที่ดีอาจไม่ใช่การทำให้ทั้งระบบสมบูรณ์แบบในวันเดียว แต่คือการทำให้โค้ดที่เราแตะวันนี้ ดีขึ้นกว่าตอนที่เราเจอมัน