Screen Shot 2558-05-08 at 10.47.16 AM
ตามแนวคิด TDD (Test-Driven Development) นั้น
การ refactoring นั้นถือได้ว่าเป็นสิ่งที่มีประโยชน์อย่างมากมาย
เนื่องจาก ถ้าขาดการ refactoring แล้ว
จะทำให้ code ในระบบของเรานั้นมี technical debt เพิ่มมากขึ้นเรื่อยๆ
สุดท้ายถ้ามีมากขึ้นเรื่อยๆ จนต้องโยน code ชุดนี้ไป
และต้อง rewrite ระบบเดิมขึ้นมาใหม่

คำถาม
เราต้อง refactor code เท่าไรดี ถึงจะพอล่ะ ?
เราจะรู้ได้อย่างไรว่าต้องหยุดเพิ่ม refactor code ?
เราจะรู้ได้อย่างไรว่า สามารถเพิ่ม feature ใหม่ๆ เข้าไปได้ ?

เป็นคำถามที่มักโดนถามบ่อยมากๆ
ซึ่งคำตอบมันมีหลากหลายเช่นกัน

ในช่วงแรกๆ จะตอบไปว่า ก็ใช้ความรู้สึกของตัวเองนะ

ถ้ารู้สึกว่า code มันมีปัญหา
ถ้ารู้สึกว่า เพิ่ม feature ใหม่ๆ เข้าไปยาก
ถ้ารู้สึกว่า code มันมีความซับซ้อนแล้ว
มันช่างเป็นคำตอบที่เลื่อนลอยมากๆ เลยนะ ..

บางคนอาจจะตอบด้วย การใช้ metric ต่างๆ

เพื่อใช้ตัดสินใจทำการ refactor code เช่น

  • Coding standard
  • Duplication code
  • Complexity

สามารถใช้ Code climate ได้นะครับ ง่ายและสะดวกดี
จะทำการแจ้งกลับมาเมื่อ code เริ่มมีปัญหา !!

แต่ว่าค่าจาก metric เหล่านี้
มันจะมาช่วยให้การ design ของระบบดีขึ้นได้อย่างไร ?
ผมคิดไม่ออกเลย …

คำถาม
แล้วจะอธิบายให้มันเข้าใจง่ายๆ และ ชัดเจนอย่างไรดีล่ะ ?
คำตอบ
ในทุกระบบนั้น code ส่วนใหญ่
มักจะได้รับความเจ็บปวดจากการ refactor code น้อยๆ
มากกว่า code ที่ทำการ refactor มากๆ

ดังนั้น ถ้าคุณไม่มั่นใจว่า refactor code พอหรือยัง
นั่นอาจจะบอกได้ว่า คุณต้องการการ refactor อีกนะ !!

โดยคำตอบนี้มันก็ เป็นแนวคิดที่ดีเลยนะ

แต่ว่า มีอะไรที่มันจับต้องได้มากกว่านี้ไหมล่ะ ?

มาลองคิดกันหน่อยสิ !!
ถ้าเราทำการพัฒนาด้วยแนวคิด TDD หรือ Test-First
ถ้าเราใช้งาน version control เช่น Git สำหรับบันทึกการเปลี่ยนแปลงต่างๆ ของ code
ดังนั้น

คำถาม
เราสามารถดูได้ไหมว่ามี commit ไหนบ้างที่เราทำการ refactor code นะ ?
คำตอบ
ได้สิ ถ้าเราใช้ git สามารถดูได้ว่าแต่ละ commit ทำการเปลี่ยนแปลงไฟล์อะไรบ้าง
ด้วยคำสั่ง
$ git log –dirstat

เราสามารถตั้งข้อสมมุติฐานได้ว่า
ถ้าใน commit นั้นๆ ไม่ทำการเปลี่ยนแปลง code ของ test
แสดงว่า น่าจะทำการ refactor code นะ !!

แต่จากการทดสอบด้วยสมมุติฐานข้างต้น พบว่า
มีหลาย commit ที่ทำการ refactor code
แต่ต้องทำการแก้ไขทั้ง code test และ production code เช่น
การเปลี่ยนชื่อ
การเพิ่มตัวอย่างต่างๆ เข้าไป
ดังนั้น สิ่งที่เราต้องการเพิ่มคือ

เราจะรู้ว่าการเปลี่ยนแปลงเหล่านี้ คือ การ refactoring ได้อย่างไร ?

ถ้าลองคิดดูแล้ว
การจะไปตรวจสอบว่ามีอะไรเปลี่ยนแปลงจาก code คงยากน่าดู
ดังนั้น ถ้าใส่คำว่า refactoring เข้าไปใน commit message ล่ะ
น่าจะง่ายกว่านะ !!

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

แล้วมีแนวคิดอื่นๆ อีกหรือไม่นะ ?

ถ้าจะเพิ่มความน่าเชื่อถือของการ refactor code
น่าจะเพิ่มเรื่องจำนวนของ test ด้วยดีไหม ?
เช่น ถ้า commit ครั้งนั้น ไม่ได้เพิ่มจำนวนของ test case
แสดงว่าน่าจะทำการ refactor code นะ

แต่การพัฒนาต้องมั่นใจว่า
ทุกๆ ครั้งที่จะเพิ่ม feature ใหม่เข้าไป
จะต้องเขียน test ด้วยเสมอนะ

จะนับจำนวนการ refactor จากการ commit ก็ต่อเมื่อ
ทุกๆ test case จะต้องผ่านทั้งหมดเท่านั้น
และถ้าจำนวน test ที่ผ่านครั้งล่าสุด ไม่เปลี่ยนแปลงครั้งก่อนหน้า
จะนับว่า commit นั้นคือการ refactor code นั่นเอง

แนะนำให้ลองไปใช้วิเคราะห์ code ของคุณดูนะครับ !!
ปล. ถ้าไม่เขียน test ก็ตัวใครตัวมันนะครับ

สุดท้ายแล้ว

แนวคิดของการวิเคราะห์ code ว่าทำการ refactor หรือไม่
อาจจะไม่ถูกต้องมากนัก
แต่ว่าเป็นแนวคิดที่จะเก็บข้อมูลพฤติกรรมต่างๆ
ที่เกิดขึ้นใน code ของระบบของเรา
เพื่อใช้ในการวิเคราะห์ และ ช่วยบอกเราว่า
code ที่พัฒนาอยู่นั้นเป็นอย่างไร มีหนี้ที่กำหลังจะเกิดหรือไม่
เพื่อให้เรารู้ได้ทันที ไม่ต้องรอทำการ review code เลย

Reference Website
http://blog.mattwynne.net/2013/07/24/how-much-should-i-refactor/
http://www.infoq.com/presentations/Technical-Debt-Process-Culture