ทำไม method สั้นๆ จึงดีกว่า !!

ในการ review code ของทีม ในขั้นตอนแรกๆ ของการวิเคราะห์เลยก็คือ
เรื่อง ชื่อ ( naming ) ว่าสื่อสารได้รู้เรื่องหรือไม่
ต่อจากนั้นมาดูว่า method หรือ function ที่พัฒนาขึ้นมามันยาวหรือสั้นเพียงใด
เนื่องจาก สิ่งที่เคยพบเจอมาก็คือ method ที่มี code จำนวนมากๆ นั้น
เมื่อทำการแก้ไขในแต่ละครั้ง พบว่าต้องลงแรงกายและแรงใจสูงมาก
ดังนั้น คุณคิดว่า method ที่มันยาวๆ จะดีไหมล่ะ ?

สิ่งที่มักจะบอก และพาทำก็คือ

จะทดสอบ method ที่คุณสร้างอย่างไรดี ?
ชื่อ method คืออะไร ?
แล้วสิ่งที่ทำงานใน method มันเป็นไปตามชื่อที่ตั้งไว้หรือไม่ ?
สุดท้าย ใน method ทำงานกี่อย่างกันแน่ ?
ถ้ามันทำงานมากกว่า 1 อย่างแล้ว สามารถแยกออกไปเป็นอีก method ได้หรือไม่ ?
ถ้ามีข้อสงสัย แยกมันออกมาเถอะครับ !!

แล้วแนวปฏิบัติสำหรับ method ที่ดีมีอะไรบ้าง

จากหนังสือ Clean code บอกไว้ว่า
Functions should do one thing, They should do it well. They should do it only.

กฏ 4 ข้อของ Sandi Metz บอกไว้ว่า

1. จำนวน LoC (Line of Code) ของ class ไม่ควรเกิน 100 บรรทัด
2. จำนวน LoC ( Line of Code) ของแต่ละ method ไม่ควรเกิน 5-7 บรรทัด
3. จำนวน parameter ที่ส่งเข้าไปใน method ไม่ควรเกิน 4 parameter หรือถ้าเป็น object ส่งเข้าไปก็ไม่ควรเยอะมากนัก
4. ใน controller หรือผู้เรียกใช้งาน ควรสร้าง object เดียวเท่านั้น เพื่อเรียกใช้งานส่วนต่างๆ ให้ทำงานตามที่ต้องการ

Curly’s Law :: Do One Thing
หมายถึง ตัวแปร, method หรืออะไรก็ตาม ควรมีความหมายเพียงอย่างเดียวเท่านั้น เสมอไป
โดยแนวคิดนี้เป็นแนวคิดหลักของการพัฒนา software สมัยใหม่ ดังต่อไปนี้

• Don’t Repeat Yourself (DRY)
• Once and Only Once (OAOO)
• Single Point of Truth (SPOT)

ถ้าปฏิบัติตามแนวคิดนี้แล้ว จะช่วยลดสิ่งที่ซ้ำซ้อนลงไปได้อย่างมาก
โดยแนวคิดนี้ มันจะนำพาไปสู่แนวคิด Single Responsibility Principle ( SRP ) ซึ่งหมายความว่า
class, method ควรจะมีเหตุผลเดียวเท่านั้นที่จะเปลี่ยนแปลง
ตัวอย่างเช่น

class Employee {
  public Money calculateMoney() {}
  public void save() {}
  public Report generateReportHourly() {}
}

คำอธิบาย
เป็นตัวอย่างที่ไม่เคราพหรือละเมิดแนวคิดของ SRP เนื่องจาก class Employee นั้น
สามารถเปลี่ยนแปลงได้ด้วย 3 เหตผล คือ

1. สูตรการคำนวนเงินเปลี่ยน
2. โครงสร้างของฐานข้อมูลเปลี่ยน
3. รูปแบบของรายงานเปลี่ยน

ดังนั้น ควรแยกทั้ง 3 ส่วนการทำงานออกจากกัน เพื่อเคารพแนวคิด SRP
ส่งผลทำให้แต่ละ class, method มีหน้าที่ทำงานที่ชัดเจน เข้าใจง่าย และแน่นอนว่าดูแลรักษาง่ายด้วย
และสามารถอ่านต้นฉบับเรื่อง SRP ได้จาก ObjectMentor::SRP ครับ

พอพูดถึงเรื่อง SRP ก็ทำให้นึกถึง OCP ( Open Closed Principle ) ถ้าเอามาใช้สำหรับการเพิ่ม method ใหม่
โดยไม่ไปแก้ไข code เดิมที่มีอยู่ น่าจะช่วยลดความเสี่ยงของการเพิ่มและแก้ไข code ได้พอควรนะ

Method ที่มันสั้นๆ มีข้อดีอะไรบ้าง

1. Testability
จากสิ่งที่ผ่านมาพบว่า จำนวน LoC ของ method มันสัมพันธ์กับจำนวน test case ที่ต้องทดสอบ
หรือทำการตรวจสอบการทำงานของ method นั้นๆ

ยิ่ง method มีจำนวน LoC มากจำนวน test case ยิ่งสูงมากขึ้นไป
ดังนั้น ถ้าต้องการลดจำนวน test case  จะต้อง extract code ออกมาเป็น method ย่อยๆ
เพื่อทำให้แต่ละ method ทำงานอย่างใดอย่างหนึ่งเท่านั้น
ซึ่งช่วยให้ลด dependency ของ code ลงไปอีก

ส่งผลให้มี

• จำนวน test case น้อยลง
• เวลาและแรงกายที่ลงไปในการสร้าง test case ลดลง
• การทดสอบใช้เวลาลดลง

ถ้าอยากรู้ ก็ลองให้เทียบกับ method ที่ยาวๆ นะครับ แล้วน่าจะพอทำให้เห็นความแตกต่าง

2. Cohesion
ในแต่ละ class ควรมี method ทำงานที่สอดคล้องกัน
ยิ่งค่า cohesion ยิ่งสูง ยิ่งดีมากเท่านั้น
โดยค่านี้จะมีความสัมพันธ์กับจำนวน LoC ของ method คือ
ยิ่งมีจำนวน LoC สูงมากๆ จะส่งผลให้เกิดการเปลี่ยนแปลงเมื่อมี requirement เพิ่มเข้าในในอนาคต

ดังนั้น ยิ่ง method สั้นเท่าไร หรือมีการทำงานเดียวกัน มากเท่าไร
ก็จะช่วยการเปลี่ยนแปลง code จาก requriement ในอนาคตได้นั่นเอง

3. Coupling หรือ DRY  
ใน method ที่ยาวๆ มักก่อให้เกิด code ที่ซ้ำซ้อน
แน่นอนว่า ส่งผลต่อการ maintain code ต่อไปอย่างแน่นอน
ดังนั้น คุณยังจะเขียนแต่ละ method ให้ยาวๆ อีกหรือ ?

4.  Understandability
ลองวัดดูว่าระหว่าง method ที่สั้น กับ ยาว นั้น
คุณใช้เวลาในการทำความเข้าใจกับ code ใน method นั้นๆ  เท่าไร
แล้วคุณจะได้คำตอบด้วยตัวเอง …

สุดท้ายแล้ว

เรามาดูกันว่า ค่าใช้จ่ายต่างๆ ในการพัฒนางานขึ้นมา ประกอบด้วยอะไรบ้าง

คำอธิบาย
ค่าใช้จ่ายในการดูแลรักษา มักจะสูงกว่า การพัฒนาเสมอ

แล้วไอ้ค่าใช้จ่ายในการดูแลรักษา มันมาจากอะไรบ้าง

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

แล้วมีวิธีการอื่นๆ บ้างไหม ?
วิธีการที่ขอแนะนำเลยก็คือ ให้ทีมพัฒนามาคุยกันแบบ face-to-face
เพื่อช่วยกันลดค่าใช้จ่าย เรื่องการทำความเข้าใจกับระบบและ code ของระบบ
ซึ่งช่วยลดค่าใช้จ่ายในส่วนของการดูแลรักษาลง
และจะช่วยทำให้

• ทุกๆ คนเข้าใจใน code ต่างๆ
• ส่งผลให้จำนวน defect ที่มาจากการดูแลรักษาลดน้อยลงไป
• แต่ละคนในทีมสามารถแลกเปลี่ยน code หรือสลับกันเขียนได้
• ทุกๆ คนเป็นเจ้าของของ code
• ทำให้การพัฒนาเป็นไปอย่างราบรื่น

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

ดังนั้นมาเริ่มเขียน code ให้มีชื่อที่สื่อถึงสิ่งที่กำลังทำ
และแต่ละ method ควรที่จะสั้นๆ กันครับ …