บทความเรื่อง Detecting Refactoring Diligence ได้อธิบาย
เกี่ยวกับการตรวจดูว่า
- เราทำการ refactoring code อยู่ในรูปแบบไหน
- เราระมัดระวังใรการ refactoring code ดีหรือไม่
ซึ่งเป็นแนวคิดที่น่าสนใจ จึงนำมาเขียนสรุปนิดหน่อย
ผมเชื่อว่านักพัฒนาส่วนใหญ่รู้จักคำว่า Refactoring
และคิดว่าน่าจะทำการ refactor code อยู่เป็นประจำ (Continuous Refactoring)
เพื่อปรับปรุงให้ code ที่มันแย่ๆ ดูดีขึ้นมา
ทำให้ code ที่เราสร้างขึ้นมานั้นแย่น้อยลง
หรือมีอัตราความแย่ของ code ต่ำลงไป
ทำให้เราสามารถทำนายได้ว่า ถ้าเพิ่ม code ไปแล้วจะดีขึ้นหรือแย่ลง
ตัวอย่างเช่น
ถ้าเราเพิ่ม code เข้าไปยัง method ที่มีอยู่แล้ว
ผลก็คือ method นั้นก็จะยาวขึ้น
ถ้าเราเพิ่ม method ใหม่เข้าไปยัง class ที่มีอยู่แล้ว
ผลก็คือ class นั้นมีจำนวน method สูงขึ้น
ทั้งสองเหตุการณ์ นี้มันทำให้เกิดผลกระทบมากต่อระบบมาก
กล่าวคือ
ถ้า method มันยาว หรือ มีการทำงานเยอะแล้ว
จะพบว่า method นั้นมีหน้าที่ความรับผิดชอบ หรือ การทำงาน
หลายหลายหน้าที่ ซึ่งมันทำให้เกิด code ที่ซับซ้อน ไร้ระเบียบ วุ่นวาย
ส่งผลทำให้ยากต่อการดูแลรักษา แก้ไข และ เพิ่มเติม
ส่งผลให้การพัฒนาช้าลงไปมา
ส่งผลให้ค่าใช้จ่ายในการพัฒนาสูงขึ้น
สังเกตไหมว่า มันง่ายมากๆ สำหรับการดูว่า code นั้นมันแย่ลง
แต่เราจะรู้ได้อย่างไรว่า code เรามันดีขึ้นกว่าเดิม หลังจากที่ทำการ refactor แล้ว
ใช้อะไรมาวัดหรือ ?
แนวคิดหนึ่งที่น่าสนใจก็คือ ประวัติจำนวน method ของแต่ละ class
โดยปกติเราจัดเก็บ code ไว้ใน Source control อยู่แล้ว
ดังนั้น ถ้าเรานำประวัติการเปลี่ยนแปลงต่างๆ ของ code มาวิเคราะห์
น่าจะทำให้เกิดประโยชน์มากกว่า ปล่อยไว้อย่างนั้นเฉยๆ
ถ้าเรานำประวัติของจำนวน method ของแต่ละ class
มาวิเคราะห์น่าจะมีประโยชน์อะไรบ้างอย่าง
ตัวอย่างเช่น
ถ้าจำนวน method ของ class A เป็นดังนี้
[ 135, 89, 14, 2, 1, 1, 1, 1, 1 ]
จากตัวอย่างนี้ หมายความว่าอย่างไร ?
เริ่มต้น class A มีจำนวน method ถึง 135 method
จากนั้นจำนวน method ก็ลดลงมาเรื่อยๆ จากการ refactor code
จนเหลือเพียง 1 method รวมทั้งถ้านำข้อมูลจำนวนบรรทัดของ method มาดูด้วย
แล้วพบว่า ใน 1 method นั้นไม่ได้เพิ่ม code เข้าไปใน method เลย
นั่นแสดงว่า
นักพัฒนาในทีมนั้นทำการ refactor code
โดยยึดถือแนวคิดเรื่อง Single Responsibility Principle (SRP)
เนื่องจากใน class มีเพียง 1 method และ ไม่ทำการเพิ่ม code เข้าไปเลย
ทำให้ class A นั้นมีหน้าที่การทำงานเพียงอย่างเดียว
หรือความซับซ้อนต่ำมาก น่าจะเป็น code ที่ดีใช่ไหม ?
จุดที่น่าสังเกตคือ
ในช่วงเริ่มต้นนั้น class A มีจำนวน method ถึง 135 method
นั่นอาจะแสดงให้เห็นว่าทีมทำการ refactor code ด้วยการ extract code ไปยัง method ใหม่เรื่อยๆ
แต่เมื่อเวลาผ่านไป ทีมพัฒนาเห็นว่า method ต่างๆ นั้น
มันไม่ควรอยู่ใน class A หรือบาง method ไม่น่าจะเกี่ยวข้องหรือเป็นหน้าที่ของ class A
จึงได้ทำการ refactor code ด้วยวิธีย้ายไปยัง class ใหม่
ส่งผลให้จำนวน method น้อยลงเรื่อยๆ
แนวคิดนี้ ไม่ใช่นำมาเพื่อจับผิดทีมพัฒนา
แต่นำมาใช้เพื่อแสดงให้ทุกคนในทีมเห็นว่า
มีอะไรเกิดอะไรขึ้นบ้างของ code
เพื่อนำมาวิเคราะห์ เพื่อหาประโยชน์จากตัวเลขเหล่านี้
สุดท้ายคือการนำมาปรับปรุง code ของเรานั่นเอง
และนี่ก็เป็นอีกหนึ่งแนวคิด แนวทาง
ในการวิเคราะห์ code ของระบบ
เพื่อหาทางปรับปรุงกันต่อไป ลองนำไปใช้กันดูนะครับ
