หลังจากที่ไปเรียนวิชา Working Effectively with Legacy code มา
พบว่าสิ่งหนึ่งที่สำคัญมากๆ ในการอยู่ร่วมกับ Legacy code คือ การ refactoring code
ซึ่งมิใช่การ rewrite code นะครับ

ก่อนที่จะทำการ refactor พวก Legacy code นั้น
เราควรที่จะมองไปที่ code เหล่านั้นก่อนเสมอ
ว่าส่วนไหนที่มีปัญหาบ้าง และ ส่วนไหนไม่มีปัญหา
อย่าลงมือ refactor code ทันทีที่ได้รับมอบหมายล่ะ เดี๋ยวจะซวย !!

Developer ส่วนใหญ่

มักจะมองไปที่ code  ณ จุดที่ต้องการแก้ไขเท่านั้น (Local area of code)
ซึ่งนั่นเป็นสิ่งที่อันตรายพอสมควรนะครับ
มันเป็นการมองภาพของ code ที่คับแคบเกินไป

เนื่องจากยังมีมุมมองอื่นๆ อีก นั่นคือการมองจากภาพรวมของ code
ว่าปัจจุบัน code มันมีสถานะเป็นอย่าง
ว่าปัจจุบันมันมีข้อมูล เช่นการแก้ไข การใช้งาน ความซับซ้อน อย่างไรบ้าง

ผมมั่นใจว่า developer ทุกๆ คนใช้  Version Control System (VCS) นะ
เช่น Git, Subversion และ Mercurial HG เป็นต้น
ถ้า developer คนไหนไม่ใช้ ก็ไปหามาใช้นะครับ !!

ดังนั้นสิ่งที่อยากจะแนะนำก็คือ การนำข้อมูลจาก Version Control System
มาช่วยวิเคราะห์  เพื่อทำให้คุณทำการ refactor code ได้ดียิ่งขึ้น

การ Refactoring นั้นเกิดขึ้นอยู่ตลอดเวลา

มันอยู่รอบๆ ตัวคุณ developer ทั้งหลาย
ดังนั้น developer ควรให้ความสำคัญมากๆ

โดยการ refactoring นั้น มีอยู่ 2 แนวทาง คือ

  1. ทำการ refactoring อยู่บ่อยๆ ในทุกๆ วัน
  2. ทำการ refactoring แบบใหญ่ หรืออาจจะมี  phase/iteration/sprint ของการทำ refactoring เลย

แต่ถ้าคุณเข้าใจคำว่า refactoring จะรู้และเข้าใจว่า
ทางที่คุณต้องเป็นไปก็คือ ทำการ refactoring อยู่ตอลอดเวลา หรือ ในทุกๆ วัน
เนื่องจากคุณต้องทำความเข้าใจกับ code และทำการเปลี่ยนแปลงมัน
ถ้าพบว่า code อยู่ในสถานะที่ไม่ดี ก็ต้อง refactor code ซะ ง่ายมาก
ทำแบบนี้ซ้ำๆ ไปเรื่อยๆ จะพบว่า code ของคุณมันดีกว่าเดิมแน่นอน

แต่ในการ refactoring นั้นควรที่จะทำแบบค่อยเป็นค่อยไป
code หลายส่วนที่เราเข้าไป refactoring นั้น มักจะ

  • แลดูว่าน่ากลัว
  • มีความซับซ้อนสูง
  • มีจำนวนบรรทัดเยอะในแต่ละ method
  • ทำการ refactoring ไปแล้วจะได้อะไร

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

ข้อมูลแรก คือ ความถี่ของการเปลี่ยนแปลง

Screen Shot 2557-11-23 at 11.48.02 AM

เป็นข้อมูลที่สามารถดึงมาจาก Version Control System ได้
เพื่อใช้ดูความถี่ของไฟล์ที่ทำการเปลี่ยนแปลง
กราฟเรียงตามการเปลี่ยนแปลง หรือ จำนวน commit/checkin  จากน้อยไปมาก (ซ้ายไปขวา)

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

ดังนั้นถ้าเราต้องเข้าไป refactoring สิ่งที่เรียกว่า Legacy code
ส่วนที่คุณควรจะเข้าไปทำก็คือ ไฟล์ที่อยู่ทางขวามือ
นั่นคือไฟล์ที่ทำการแก้ไขบ่อยๆ นั่นเอง

แต่โชคไม่ดีเท่าไร ไฟล์ที่มีการเปลี่ยนแปลงบ่อยๆ มันมีหลายรูปแบบรวมกัน เช่น

  • เป็นไฟล์เกี่ยวกับ configuration
  • เป็นไฟล์ทำหน้าที่เป็น Factory object

มันก็เป็นข้อจำกัดของการดูข้อมูลในรูปแบบนี้

เราต้องการข้อมูลเพิ่มเติมอีกอย่างก็คือ ขอเรียงตามลำดับไฟล์ที่น่ากลัวได้ไหม ?
เพื่อให้มันรู้ดำรู้แดงไปกันเลย !!

ข้อมูลต่อมาคือ ความถี่ของการเปลี่ยนแปลง กับ ความซับซ้อน

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

แสดงดังรูป

Screen Shot 2557-11-23 at 7.53.03 PM

จากกราฟจะเห็นได้ว่า

1. ไฟล์ที่อยู่ฝั่งขวาบน นั่นคือ
ไฟล์ที่ต้องได้รับความสนใจเป็นอันดับต้นๆ
เนื่องจากมีการเปลี่ยนสูง และ ก็มีความซับซ้อนที่สูงด้วย
โดยไฟล์ในกลุ่มนี้เกิดขึ้นมาด้วยหลายเหตุผล
สาเหตุหลักๆ เลยก็คือ Center of condition
นั่นคือมีการตรวจสอบเงื่อนไขต่างๆ เพื่อแยกการทำงาน
เราจะเจอ if-else if – else  เพียบ
ยิ่งนับวันมันมีแต่จะโตขึ้นเรื่อยๆ ความซับซ้อนก็เพิ่มขึ้นเรื่อยๆ
ส่งผลให้การ refactoring ในส่วนนี้ยากมากๆ หรือ ใช้ค่าใช้จ่ายที่สูงตามมา

2. ไฟล์ที่อยู่ฝั่งซ้ายล่าง นั่นคือ
ไฟล์ที่มีจำนวนการแก้ไขต่ำ และมีความซับซ้อนต่ำ
ทำให้เห็นว่า ถ้าไฟล์ใดที่มีความซับซ้อนต่ำ จะทำให้จำนวนการแก้ไขต่ำลงไปด้วย
เพราะว่าแต่ละไฟล์มีการทำงานอย่างใดอย่างหนึ่งไปเลย
นั่นคือ เคารพในแนวคิด SRP (Single Responsibility Principle)
ทำให้ code ในส่วนนี้จะทำงานกับมันง่ายมาก

3. ไฟล์ที่อยู่ฝั่งซ้ายบน นั่นคือ
ขอเรียกว่ากลุ่มไฟล์ของ Cowboy programmer
ซึ่งมันมักจะเกิดขึ้นมาพร้อมกับความซับซ้อน ไม่ได้สนใจอะไร แค่ทำให้เสร็จ
แล้วก็ไม่มีใครมาแก้ไขเลย

4. ไฟล์ที่อยู่ฝั่งขวาล่าง นั่นคือ
ส่วนนี้เป็นส่วนที่น่าสนใจเอามากๆ
ในส่วนนี้มักจะเรียกว่า ไฟล์พื้นฐานของระบบ เช่น configuration ต่างๆ
ซึ่งทำการเปลี่ยนแปลงบ่อยๆ

ไฟล์ในส่วนนี้มักจะกลายเป็นส่วนของ abstraction layer ใหม่
หมายความว่า เมื่อมีการเพิ่ม code เข้ามาในส่วนนี้แล้ว
พบว่าทีมมักจะทำ refactor code เช่น ทำการ extract ออกไปเป็น method/class
ส่งผลให้เกิดการเปลี่ยนแปลงบ่อยๆ และความซับซ้อนก็ต่ำอยู่เช่นเดิม

โดยสรุปแล้ว

การนำข้อมูลในมุมมองต่างๆ ของ code มาช่วยนั้น
ทำให้เราเห็นว่า code ส่วนไหนที่มีปัญหาใหญ่
ที่ต้องได้รับการ refactoring ในกลุ่มแรกๆ
ไม่ใช่การเดาด้วยความรู้สึกส่วนตัวนะครับ

ซึ่งสิ่งเหล่านี้จะเรียกว่า Empirical Refactoring