วันนี้อ่านเจอคำที่น่าสนใจคือ คำว่า STUPID จึงนำมาขยายความ
ในโลกของการพัฒนาด้วย Object-Oriented Programming นั้น
มีแนวคิดเพื่อที่จะทำให้ code ที่เขียนขึ้นมานั้นมันมีคุณภาพที่ดี
เช่น SOLID, DRY(Don’t Repeat Yourself), Separation of Concern เป็นต้น
แต่มีแนวปฏิบัติกลุ่มหนึ่งที่ผิดปกติ แต่เรามักพบเจอกันมากจนเป็นเรื่องปกติ
ซึ่งสามารถรวบรวมมาอยู่ในชื่อที่เรียกว่า “STUPID”
ปล. STUPID เป็นเพียงแนวปฏิบัติที่เราควรพึงระวัง
สามารถใช้ได้ดีในบางอย่าง บางเรื่อง
STUPID ไม่ใช่กฏที่ต้องทำตามนะครับ ของแบบนี้มันบังคับกันไม่ได้
STUPID มันคืออะไร ?
ย่อมาจาก
- S = Singleton
- T = Tight Coupling
- U = Untestability
- P = Premature Optimization
- I = Indescriptive Naming
- D = Duplication
มาดูกันว่าแต่ละเรื่องมันคืออะไร อย่างไรกันบ้าง
1. Singleton
เป็น Design pattern หนึ่งที่ได้รับคงามนิยมในการใช้งานอย่างมากมาย
แต่โชคร้ายว่า developer ส่วนใหญ่ไม่เข้าใจมัน และใช้มันในทางที่ผิด
เคยเจออาการที่เรียกว่า Singleton Syndrome ไหม ?
คือไม่ว่าจะยังไง อะไร ก็ใช้ Singleton มันไปเถอะ …
ซึ่งแบบนี้มันไม่ดีแน่นอน
การใช้งาน Singleton pattern นั้นมันไม่ใช่ปัญหา
แต่มันเป็นอาการอย่างหนึ่งของปัญหา
ยกตัวอย่างเช่น
- การใช้งานตัวแปร global นั้นมันทดสอบยากมาก
- การใช้งานตัวแปร global นั้นมันจะซ่อน dependency ต่างๆ
ดังนั้นจึงอยากให้หลีกเลี่ยงมัน
ลองเปลี่ยนอะไรก็ได้มาแทน Singleton ดูสิ code คุณจะดูดีขึ้น
ยิ่งถ้าใช้ Singleton มากเท่าไร ตัวแปรที่เป็น static จะมาก
และนั่นคือการทำให้ code มันผูกติดกันมากขึ้นนั่นเอง ( Tight coupling )
2. Tight Coupling หรือ Strong Coupling
การผูกมัดของ code ที่แน่นมากๆ
แน่นอนว่า ปัญหานี้มันก็มาจาก Singleton ด้วยเช่นกัน
ดังนั้น สิ่งที่เราทำได้ก็คือ ลดการผูกมักของ code
ด้วยการแบ่งเป็น module แยกกันไป
แต่ละ module ก็ทำงานแยกกันเป็นอิสระ
ผลที่ตามมาก็คือ เมื่อคุณแก้ไข code ใน module หนึ่งแล้ว
มันจะไม่กระทบต่ออีก module หนึ่ง
ซึ่งสามารถนำแนวคิดของ Dependency Inversion Principle มาช่วยได้
สิ่งหนึ่งที่แสดงว่า code ในระบบของคุณมัน Tight coupling ก็คือ
- ยากต่อการ reuse
- ยากต่อการทดสอบ
3. Untestability
code ที่เราเขียนขึ้นมานั้น ควรที่จะทดสอบได้ง่าย
วัดง่ายๆ ว่า code คุณทดสอบยาก หรือ ง่าย ดังนี้
เมื่อไรก็ตามที่คุณบอกว่า
ฉันไม่เขียน unit test หรอกนะ เพราะว่าไม่มีเวลา
นั่นคือ คุณกำลังสร้าง code ที่ทดสอบได้ยาก
… ถ้าไม่เชื่อลองกลับไปดู code ได้เลย !!
code ที่คุณเขียนขึ้นมา โดยไม่มี unit test นั้น
มันทดสอบยาก เพราะว่า code ที่เขียนมันผูกติดกันแน่นมากๆ (Tight coupling)
4. Premature Optimozation
เรื่องนี้มันคือต้นเหตุของปีศาจ ที่ developer มักจะสร้างขึ้นมา
มันเป็นเรื่องของ ค่าใช้จ่ายที่ต้องเสียไป มากกว่าจะได้รับผลประโยชน์ที่ดีกลับมา
ในการ optimize code ตั้งแต่แรกนั้น มันจะสร้างความซับซ้อนของ code ขึ้นมาตั้งแต่แรกเริ่ม
สุดท้ายมักจบลงด้วยการได้ code ที่อ่านไม่รู้เรื่อง หรือ ทำความเข้าใจได้ยากมากๆ
และบ่อยครั้งวิธีการมันมักจะ anti-pattern ต่างๆ ไปอย่างสิ้นเชิง
ดังนั้น ขอแนะนำกฎ 2 ข้อ ในการ optimize code ตั้งแต่แรกเริ่ม มีดังนี้
- ข้อที่ 1 อย่าทำ
- ข้อที่ 2 อย่าเพิ่งทำตอนนี้
5. Indescriptive Naming
ใน code นั้นเรื่องของการตั้งชื่อที่ไม่สื่อ พบเห็นได้บ่อยมากๆ
ทั้งชื่อ file, class, function/method, variable ต่างๆ
แนะนำง่ายๆ ว่าอย่าใช้ตัวย่อนะ
จำง่ายๆ ว่า คุณเขียน code ให้คนอ่าน ไม่ใช่ให้เครื่อง นะครับ
ดังนั้น developer/programmer คือการ programming สำหรับคน นะครับ
แนำนำให้อ่านเรื่อง Clean code ครับ
6. Duplication
code ที่มันซ้ำซ้อน คือ สิ่งที่แย่มาก
ดังนั้นสิ่งที่คิดไวเสมอในการเขียน code คือ
- DRY (Don’t Repeat Yourself) อย่าทำซ้ำ
- Keep It Simple Stupid (KISS) ทำในสิ่งที่เรียบง่าย
- Once And Only Once
ให้หัดเป็นคนที่ขี้เกียจอย่างถูกทางและถูกต้อง
บางเรื่องก็ไม่ต้องขยันมากก็ได้ เช่นการเขียน code เดิมซ้ำๆ
มาถึงตรงนี้
น่าจะพอทำให้รู้แล้วว่า STUPID มันเป็นอย่างไร
ดังนั้นลองกลับไปดู code ของคุณว่ามัน STUPID ไหม
ถ้าใช่ … อย่ากลัว หรือ รู้สึกแย่ไปนะครับ
เพราะว่า คุณสามารถนำแนวคิด SOLID เข้ามาช่วยได้นะ !!
