Screen Shot 2559-01-06 at 10.31.16 AM
เมื่อระบบงานมีจำนวน feature มากขึ้น
Developer ก็ยิ่งเขียน code มากขึ้นเท่านั้น
ส่งผลให้ code ในระบบมีความซับซ้อนขึ้นอย่างต่อเนื่อง
ดังนั้น เราควรหยุดคิด และ พิจารณา code กันหน่อยไหม

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

ดังนั้น ย้อนกลับมาดูก่อนไหมว่า
ความเจ็บปวด และ ปัญหาที่แท้จริงมันคืออะไรกันแน่
จากนั้นจึงหาวิธีการแก้ไข
เพื่อให้ความเจ็บปวด และ ปัญหามันลดน้อยลงไป

คำถาม
แล้วเราจะกลับมาดู code และ แก้ไขเมื่อไรดีล่ะ ?
เป็นคำถามที่ตอบได้ยากมาก
แต่ว่ามีคำแนะนำดังนี้

อย่าละเลยการ refactor code ด้วยการผลัดวันประกันพรุ่ง

Developer มักจะเขียน code ให้มันทำงานได้ไปก่อน
Developer มักจะบอกว่า code มันดีอยู่แล้ว อย่าไปยุ่งกับมันเลย
Developer มักจะบอกว่าเดี๋ยวจะกลับมาแก้ไข
Developer มักจะบอกว่า …
สุดท้าย code เหล่านั้นจะเป็นอย่างไร ?
น่าคิดนะ

มาดูตัวอย่างจากหนังสือ Refactoring กันหน่อย

ต้องการสร้างระบบคำนวณเงินโบนัสของพนักงานแต่ละแผนก
ซึ่งบริษัทนี้มีเพียง 2 แผนก คือ IT กับ Sales เท่านั้น
โดยแต่ละแผนกก็มีการคำนวณที่แตกต่างกันไปตามจำนวนปีของการทำงาน

ดังนั้นเมื่อเข้าใจความต้องการแล้ว
Developer ก็จะลงมือเขียน code ทันที ดังนี้

แน่นอนว่า code ชุดนี้มันสามารถทำงานได้อย่างถูกต้องตามความต้องการ
เพียงแค่โยน employee เข้ามาเท่านั้นเอง
ดังนั้นงานเราเสร็จแล้ว !!

แต่เดี๋ยวก่อนนะ !!

บางคนอาจจะบอกว่า ถ้ามีแผนกอื่นเพิ่มเข้ามา
code ชุดนี้มันน่าจะเพิ่มยากนะ

ดังนั้นลองปรับ code ให้มันอ่านง่าย ๆ สวย ๆ หน่อยไหม ?
ด้วยการเปลี่ยนจาก if-else ไปเป็น switch-case
ซึ่งเป็นการ refactoring แบบเล็ก ๆ
เพื่อให้ developer คนอื่น ๆ อ่านง่าย เข้าใจง่าย
เขียน code ได้ดังนี้

แต่เดี๋ยวก่อนนะ !! ต่อมาบริษัทมีแผนกเพิ่มเข้ามาเป็น 10 แผนก จะทำอย่างไรดี ?

คำถาม
Developer จะยังคงใช้ switch-case ต่อไปอีกไหม ?
คำตอบ
สำหรับ developer ส่วนใหญ่ก็จะบอกว่าใช่แล้ว ใช้ต่อไป
เนื่องจาก code ก่อนหน้ามันเป็นแบบนี้
เนื่องจาก code มันเป็น standard ของเรา อย่าไปแก้ไข
เนื่องจาก code มันยังทำงานได้ดีอยู่

ดังนั้น code ที่ได้ออกมาจึงเป็นดังนี้

คำถาม
Code ชุดนี้คุณคิดว่ามันดีแล้วหรือ ?
คำตอบ
ใช่แล้ว code ชุดนี้มันดี และ ทำงานได้อย่างถูกต้องด้วย

แต่ Develoepr ลองมาดูกันหน่อยไหมว่า code ชุดนี้มันมีความซับซ้อนมากน้อยเพียงใด ?
ตอบได้เลยว่า มาก

แล้วยังจะทำกันแบบนี้อีกหรือไง ?
ดังนั้น มันน่าจะได้เวลาของการ refactor code
ก่อนที่จะเพิ่มการคำนวณ bonus ของแผนกอื่น ๆ

ถ้าปล่อยไว้มันจะกลายเป็น Legacy code ที่ใคร ๆ ก็ไม่อยากแตะต้อง !!
มันน่ากลัวมาก ๆ เลยนะ
มันจะนำมาสู่ปัญหา
มันจะนำมาสู่ความปวดหัว
มันจะนำไปสู่หายนะ
ในการดูแลรักษาต่อไป

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

ตรงนี้แหละ เราสามารถนำเอาความรู้เกี่ยวกับ design pattern มาประยุกต์ใช้ได้
เพื่อนำมาแก้ไขปัญหาตามที่เราต้องการ
มันน่าดูเข้าท่าเข้าทางกว่าเยอะนะ

ซึ่งผมแนะนำให้อ่านหนังสือ Refactoring to Patterns
เพื่อทำให้เข้าใจในการนำ design pattern มาประยุกต์เพื่อใช้งาน

โดยตัวอย่างนี้เราสามารถนำเอา Design pattern มาใช้ได้
แต่ว่าทำอย่างไรล่ะ ?
เช่น Strategy pattern, Template Method pattern เป็นต้น

ตัวอย่างของ Strategy pattern
เราจะทำการแยกส่วนการคำนวณโบนัสของแต่ละแผนกออกจากกัน
รูปแบบการทำงานจะเหมือนกัน มาดู code ดีกว่า

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

แต่ข้อเสียก็คือ จำนวนไฟล์ และ class เยอะขึ้น
ซึ่ง developer หลาย ๆ คนกลัว

จงกลัว code ที่หนึ่งไฟล์มี code หลายร้อย หลายพันบรรทัด !!

ข้อควรจำสำหรับการนำ design pattern มาใช้คือ

อย่าบังคับว่า จะต้องใช้ pattern นั้น pattern นี้เพียงอย่างเดียว
นั่นคือ อย่าผูกมัดตัวเองด้วย design pattern
มันคือการฆ่าตัวตายชัด ๆ

แต่ให้มองไปที่ความต้องการ และ ปัญหาของระบบเป็นสำคัญ
เนื่องจากการทำงานแต่ละส่วนมันแตกต่างกัน
ดังนั้นอาจจะใช้แนวทางการแก้ไขที่ต่างกัน
รวมทั้งแต่ละ pattern มันมีทั้งข้อดีและข้อเสีย
ซึ่งคนนำมาใช้งานต้องเข้าใจอย่างดีด้วย

ถ้าคุณจะหา Best Practice สำหรับปัญหานั้นปัญหานี้
บอกได้เลยว่า มันไม่มีหรอกนะครับ
มีแต่เหมาะสม และ ทำให้ code ดีขึ้นเท่านั้นเอง
และที่สำคัญคือ คนในทีมเข้าใจไหม ?