Design Smells — Software ของคุณมีกลิ่นหรือเปล่า ?
อันนี้ก็เป็นบทความแรกของผมนะครับ ผิดพลาดตรงไหน อยากติตรงไหนก็เต็มที่ได้เลยครับ ยินดีครับ จะได้นำไปปรับปรุงสำหรับบทความต่อๆไป เนื้อหาส่วนใหญ่ของบทความนี้คือตัดมาจากหนังสือของ Uncle Bob ที่ชื่อว่า Agile Software Development Principles, Patterns and Pratices นะครับผม
เนื่องจากตอนนี้ผมเรียนด้าน IT หนักไปทาง Programming นี้แหละครับ ก็เขียนโปรแกรมมาได้สักพักนึงแล้วครับ
มีความรู้สึกว่าการเขียนโปรแกรมให้มันทำงานได้เนี่ย โอเคเราทำได้แล้วหละ แต่พอกลับมานั่งอ่าน Code ของเรา OMG โคตรจะอ่านไม่รู้เรื่องเลยครับ 555+ จะแก้ Code บางส่วน หรือจะมาเพิ่ม Feature ให้กับโปรแกรมของเราแต่ละทีเนี่ย ใช้เวลานานมาก จนบางทีนั่งเขียนใหม่เริ่มจากศูนย์ ยังง่ายกว่า 555+ ใครที่ยังเป็นโปรแกรมเม่อฝึกหัด พึ่งเริ่มต้นแบบผมน่าจะเจอปัญหานี้นะครับ ยังไงฝากติดตามบทความ Series นี้ด้วยนะครับผม
เอาหละครับเรามาเข้าเรื่องกันดีกว่า คือเราจะรู้ได้ไงหละว่า Code ของเรามันจะต้องมีปัญหา มันต้องยุ่งยากแน่ๆ ถ้าเราต้องกลับมาแก้ไข ต้องมานั่งอ่านมัน มายุ่งกับมันอีกในอนาคต??
ในหนังสือของ Uncle Bob เรียกปรากฏการณ์ นี้ว่า “Design Smells” ครับผม มี 7 อย่าง ดังนี้
Rigidity (ความไม่ยืดหยุ่น)
เวลากลับมาเปลี่ยนแปลง Code สมมติว่าคุณเปลี่ยนแปลง Code ใน Class นึง คุณต้องไปเปลี่ยนแปลง Code ใน Class อื่นๆ หรือใน Module อื่นๆ เพื่อที่จะทำให้โปรแกรมของคุณทำงานได้ปกติ (ผ่านทุก Test) หรือเปล่า พูดง่ายๆก็คือ Code ของคุณ depend on classes อื่นๆมากแค่ไหนนั่นเอง (Dependencies)
Fragility (ความเปราะบาง)
อันนี้เป็นปรากฏการณ์ที่คุณเปลี่ยนแปลง Code ในที่เดียว แต่ไป Break code (Run test ไม่ผ่าน)ใน Class อื่นๆ Module อื่นๆ ที่ไม่เกี่ยวข้องกันเลยด้วย ยกตัวอย่าง คือเปลี่ยนแปลง Code ใน class ที่เกี่ยวข้องกับ Business logic แต่พอ Run test ไปเจอ Error หรือ Warning ที่ UI Class เป็นต้น
Immobility (ความพิการ)
อันนี้คือถ้า Module ที่เราเขียนขึ้น สามารถนำไปใช้ใน System อื่นๆ — เราสามารถ Reuse Module นี้ได้หรือเปล่า ? ถ้าคำตอบคือได้ แต่เราต้องแก้ไขเยอะ หรือต้องลากเอา Module อื่นๆที่เกี่ยวข้องกับ Module ตัวนี้ไปใส่ในระบบใหม่นั้นด้วย อันนี้ก็ Design Smell
Viscosity (ความหนืด)
“ It is easy to do the wrong thing, but hard to do the right thing ”
มนุษย์เราเนี่ยไม่ว่าจะอาชีพไหนๆ เวลาเจอปัญหา เรามักจะแก้ด้วยวิธีการที่ง่ายที่สุด สบายที่สุด ก่อนเสมอ
Programmer ก็เหมือนกัน ยกตัวอย่าง ลูกค้าบอกให้เราเปลี่ยนระบบตรงนั้นตรงนี้ เราก็มักจะแก้แบบขอไปที คือแก้ให้มัน Run ผ่าน ให้มันใช้ได้ไปก่อน แต่ไม่ได้นึกถึงเรื่องของ Design เลยนั่นเอง พอทำแบบนี้ไปบ่อยๆ Code มันก็ยุ่งเหยิง พันมั่วกันไปหมด มันจะถึงจุดหนึ่งที่กลับมาแก้ไขอะไรไม่ได้แล้ว แก้ตรงนี้เจอปัญหาตรงโน้น บลาๆๆ สุดท้ายต้องรื้อทำใหม่กันเลยทีเดียว
Needless Complexity (ความยุ่งยากที่ไม่จำเป็น)
อันนี้ขอเรียกว่าการ “Design เพื่อวันพรุ่งนี้” เกิดขึ้นเมื่อ system ของคุณมี module หรือ class ที่ไม่มีประโยชน์ ไม่จำเป็นต้องใช้ในตอนนี้
Developers มักจะคิดถึงอนาคตว่าโปรแกรมต้องมีการแก้ไขในอนาคตแน่ๆ เลยพยายามทำให้ System ง่ายต่อการแก้ไข เช่นใช้ Abstract classes, Interfaces หรือ Design Patterns เกินความจำเป็น อันนี้อาจจะดู Cool ในตอนแรก แต่พอนานไปมันกลับเพิ่มความยุ่งยากให้กับระบบนั่นเอง
วิธีการแก้คือ Design ให้ดี เพื่อแก้ปัญหาใน Cycle นี้ก่อน ปัญหาอื่นๆค่อยว่ากันที่ Next Cycle
Needless Repetition (การซ้ำซากที่ไม่จำเป็น)
ถ้าคุณ Ctrl V + Ctrl C บ่อยๆ เวลาคุณนั่ง Code นั้นแหละครับใช่เลย
แล้วมันเป็นปัญหายังไงหละ ขอยกตัวอย่างแล้วกัน สมมุติผมต้องการติดต่อไปยัง Database ก่อนจะ Connect คือต้องใส่ ip, user, password และก็ database name ที่เราต้องการจะติดต่อซะก่อน
มี 20 modules ที่ใช้ code ชุดนี้ ตอนแรกมันก็ไม่มีปัญหาอะไรครับ แต่ลองนึกถึงตอนที่เราจะย้ายไปติดต่อกับ server เครื่องอื่น หรือฐานข้อมูลอื่นๆ มันเท่ากับว่าคุณต้องแก้ไขข้อมูลชุดนี้ใน 20 ที่นั้นเอง
วิธีการแก้ปัญหาคืออาจจะสร้าง Configuration File หรือ สร้าง Class ขึ้นมานั้นเอง
Opacity (ความไม่ชัดเจน)
อันนี้คือปรากฏการณ์ที่ Code ของคุณยากที่จะเข้าใจ วิธีการแก้ปัญหาคือตอน Code ให้คิดซะว่าเรากำลังเขียนหนังสือให้เด็กประถมอ่าน แล้วก็ Refactoring Code บ่อยๆครับ
คราวนี้เราก็รู้จักกันคร่าวๆแล้วนะครับ สำหรับ 7 หายนะ ที่จะทำให้ระบบของคุณ ยากที่จะ maintain หรือ improve ในอนาคต ในบทความต่อๆไปผมจะพูดถึงเรื่อง SOLID Principles แล้วก็ Design Patterns ซึ่งเป็นหลัก เป็นแบบที่นำมาใช้เพื่อแก้ปัญหาเหล่านี้ครับผม
“ Happiness Only Real When Shared ”
ปล. ที่เริ่มเขียน Blog เพราะไปดูหนังเรื่องนึงแล้วเจอ Quote นี้ ผมก็เลยจะลองดูครับว่ามันจริงหรือเปล่า
Reference:
Robert cecil martin. (2002). Agile Software Development, Principles, Patterns, and Practices. (1st ed.). England: Pearson.
Fanpage ครับ : https://www.facebook.com/imkrish.developer/
