หลังจากทำการอธิบายการ Refactoring ด้วยวิธี Constructor Overloading ไปแล้ว
เราไปดูวิธีการอื่นๆ บ้างว่ามีอะไรอีก

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

ซึ่งวิธีการนี้ เป็นวิธีการหนึ่งในการ Refactoring code ชื่อว่า Extract Method

ผมเชื่อว่า developer ทุกๆ คนทำใช่ไหม ?

Extract method คืออะไร

มันคือวิธีการหนึ่งในการทำ Refactoring code ที่ง่ายสุดๆ
และสามารถทำได้บ่อยสุดๆ เท่าที่ต้องการ
เพียงแค่พิจารณาว่า code ใน method ต่างๆ มันยาว
หรือมี code ส่วนไหนที่ต้องการ comment เพื่ออธิบายหรือไม่
ถ้ามีลองแยก code ออกไป method ใหม่เท่านั้นเอง

สิ่งที่ควรให้ความใส่ใจก็คือ

  • Method จะต้องสั้น
  • ชื่อ method ต้องสั้นกระชับ
  • ชื่อ method ต้องสื่อถึง code ที่อยู่ใน method

ดังนั้นชื่อที่ดีสำคัญมากๆ  ควรให้เวลากับมันหน่อยนะ
บ่อยครั้งพบว่า developer จะเสียเวลาไปกับการคิดชื่อนานมาก
สุดท้ายได้ชื่อห่วยแตกออกมาว่าไหม ?

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

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

ตัวอย่างแบบโง่ๆ

จะพบว่า code ใน method printData() มีการทำงาน 2 ชุด
แถมใน code มีการ comment ชุด code ให้ด้วย
สบายเลยงานนี้ …

ว่าแต่จะ comment code ไปทำแมวอะไรล่ะ  ?
ดังนั้น เราสามารถแยกด้วยการ Extract method ออกมาได้ดังนี้
คือสร้าง method ชื่อว่า printDetails() มา

ผลที่ได้คือ code อ่านเข้าใจขึ้นไหม ?
เราไม่ต้องมี comment ใน code แล้วใช่ไหม ?

ตัวอย่างก่อนหน้ามันง่ายไปหน่อย

มาดูตัวอย่างนี้บ้าง ก็ง่ายอีกนั่นแหละ

จะพบว่า code ใน method printData() มีการคำนวณอยู่ด้วย
ซึ่ง code ชุดนี้ก็ไม่น่าอยู่ใน mehtod นี้ใช่ไหม ?
ถ้าใช่ เราควร extract method ออกมาใช่ไหม ?
ชื่อ method ว่าอะไรดีล่ะ ?
แบบนี้ดีกว่าไหม  ?

ผมเชื่อว่า developer ทุกคน เคารพในชื่อของ method

และ code ต้องเป็นไปตามชื่อ method
และเชื่อว่าแต่ละ method ต้องมีการทำงานอย่างใดอย่างใดอย่างหนึ่ง
นั่นคือเคารพในแนวคิด Single Responsibility Principle (SRP)

แต่ถ้าตั้งชื่อ method ประมาณว่า processXXX, manageXXX, delegateXXX
แบบนี้ก็ไม่ไหวนะครับ หน้าที่รับผิดชอบมันกว้างไป

มาถึงตรงนี้น่าจะพอเห็นแล้วว่า Extract method นั้นทำอย่างไร
และก็มีข้อดีพอสมควรนะ
แต่มันน่าจะมีข้อดี หรือ มีคุณค่าอะไรอีกไหมล่ะ  ?

1. ช่วยอธิบายว่า คุณกำลังทำอะไร

เหตุผลหนึ่งในการออกแบบของ Object Oriented นั้น
จะอนุญาตให้เราทำการอธิบายทำงานใน code ได้ละเอียดและชัดเจนกว่า
การเขียนแบบ Structural/Procedural นะ (แต่เรามักเขียนแบบไหนนะเออ ?)

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

หรือถ้าทำการ extract method ใหม่ๆ ไปแล้ว
พบว่ารายละเอียดของ code มันไม่น่าจะอยู่ใน class นี้
แสดงว่า ถึงเวลาต้องนำ method นั้นออกไปที่อื่นแล้วล่ะ

2. ทำให้ code อ่าน และ ทำความเข้าใจง่ายขึ้น

ผลที่ตามมาจากการ extract method หลักๆ เลย ก็คือ code จะอ่านง่าย
เพราะว่า ในแต่ละ method จะมี code ที่มีรายละเอียดเพียงเรื่องเดียวเท่านั้น
และควรที่จะอยู่ใน abstraction ชั้นเดียวกันเท่านั้นนะ

บ่อยครั้งพบว่า ถ้า method ใดเริ่มมี code มากกว่า 10 บรรทัด
แสดงว่า code เริ่มมีการทำงานมากกว่า 1 อย่างแล้วล่ะ
ถึงเวลาที่คุณจะเริ่ม extract method ได้แล้วนะ !!

3. ช่วยหา code ที่มันทำงานผิดได้ง่าย

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

ตัวอย่างเช่น การจัดการระบบบางอย่างมีขั้นตอนดังนี้

พบว่ามีการทำงานหลายขั้นตอน
ดังนั้น จึงทำการ extract method ออกไป ชื่อว่า openAndMaximize()

สิ่งที่ได้จากการ extract method ก็คือ
พบว่า error ที่เกิดขึ้นอยู่ตรงไหนกันแน่
ซึ่งช่วยลดเวลาในการหาจุดผิด และ แก้ไขได้รวดเร็วขึ้น

จากที่ผมเขียน code มาบ้างเล็กน้อย

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

คุณจะเขียน code ที่เข้าใจง่าย หรือ จะสร้าง code ที่ซับซ้อน ไม่รู้เรื่องขึ้นมา
ก็เลือกเอากันเองนะครับ …

ปล. ถ้าส่วนไหนที่เรา refactoring code ไม่มี test แนะนำให้สร้าง test เฉพาะส่วนนั้นขึ้นมาครับ
เนื่องจากถ้า refactoring code แบบไม่มี test แล้ว ก็ตัวใครตัวมันครับ !!!

Reference Website
Refactoring :: Extract Method