timthumb.php_
อาทิตย์ที่แล้ว ทำการ review code กับทีมพัฒนา
โดยมีการพูดคุยเกี่ยวกับ code ที่เขียนกันว่าเป็นอย่างไร
ซึ่งเรื่องหนึ่งที่ได้พูดถึงก็คือ Design pattern
ที่น่าจะเหมาะสมสำหรับการแก้ไขปัญหาที่พบเจอใน code
แต่ developer ในทีมยังไม่ค่อยรู้จักมันสักเท่าไรนัก
จึงหยุดถามตัวเองว่าแล้วไอ้ Design pattern นี่มันคือปัญหา หรือ การแก้ไขปัญหากันนะ

ถ้าถาม developer ส่วนใหญ่เรื่อง Design pattern หรือพูดชื่อไปตรงๆ เช่น
MVC, Adapter, Repository, Template method, Delegate และ Singleton เป็นต้น
หรือหนักไปเก่านั้นก็พวก SOLID, FLUID
คำตอบที่มักจะได้กลับมา ก็เช่น

  • อย่าพูดถึงมันเลย …
  • เกลียดมัน เยอะไป
  • มันคืออะไร
  • เห็นเขาว่าดีนะ แล้วยังไงหรอ
  • ไร้สาระ
  • อย่าอธิบายเลยพี่ พาทำเลยดีกว่า จะทำตามๆ กันไป

ก่อนอื่นต้องถามก่อนว่า เราสร้าง software หรือ product ต่างๆ มาเพื่ออะไร ?

ถ้าตอบแบบลูกจ้าง ก็คือ ทำตามหัวหน้าบอกสิ
แต่ถ้าตอบแบบ developer เราไม่ได้เขียนหรือสร้าง software/product นะ
แต่มันคือการแก้ไขปัญหา
โดยเริ่มตั้งแต่ทำความเข้าใจต่อ requirement
พยายามแยกออกมาเป็นส่วนหรือปัญหาย่อยๆ
เพื่อทำให้เราเข้าใจว่า จะแก้ไขมันอย่างไร
หลังจากนั้นจึงลงมือแก้ไขปัญหาย่อยๆ เหล่านั้นไปเรื่อยๆ

ดังนั้น code ทุกๆ บรรทัดที่คุณเขียนขึ้นมา เพื่อแก้ไขปัญหาจากข้างต้นล้วนๆ

เมื่อปัญหาถูกแก้ไขได้ด้วยวิธีการต่างๆ
ก็มักทำให้เกิดคำว่า Best Practice ของฉัน แต่ไม่ใช่ของคนอื่น
สำหรับการแก้ไขปัญหานั้นปัญหานี้
ยิ่งนับวันยิ่งออกมาเยอะ กลายมาเป็น Pattern หรือรูปแบบ

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

ต้องจำไว้ว่า Pattern ไม่ใช่วิธีการแก้ไขปัญหา แต่มันเพียงแนวทางที่ช่วยเหลือเรา

ถ้าเราคิดหรือเข้าใจว่า pattern นั้นคือ วิธีการแก้ไขปัญหา แล้ว
เราก็จะนั่งท่องมันแบบนกแก้วกขุนทองเลย ทั้งๆ ที่ไม่ได้รู้เลยว่าแต่ละ pattern มันเกิดขึ้นมาอย่างไร
ผลที่ได้รับคือ คุณก็จะบอกว่ามันเยอะ ยาก ไร้สาระ เลิกเถอะ …

โดยสิ่งที่ต้องเข้าใจใหม่เลย ก็คือ Pattern นั้นจะช่วย

  • ให้คุณเขียน code ที่ดีขึ้น
  • ให้คุณเขียน code ที่มีความยืดหยุ่นขึ้น
  • ให้คุณเขียน code ที่ไม่ผูกมัดกัน
  • ให้คุณเขียน code ที่อ่าน และ เข้าใจมากยิ่งขึ้น

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

ปัญหาที่ผมมักเจอก็คือ เป็นเรื่องการประยุกต์เพื่อนำไปใช้งานนั่นเอง !!!

ตัวอย่างของ Design Pattern ที่ developer ควรศึกษาไว้บ้าง

ถ้าพูดถึงหนังสือเกี่ยวกับ Design Pattern ก็ขอแนะนำ

Design-Patterns-in-RubyDesign-Patterns-Elements-of-Reusable-Object-Oriented-Softwarehfd

โดยสรุปเรื่องการนำไปใช้งาน

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

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

Design pattern be with you !!! ครับ