เมื่อระบบงานมีจำนวน 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 ดีขึ้นเท่านั้นเอง
และที่สำคัญคือ คนในทีมเข้าใจไหม ?
