Screen Shot 2558-08-23 at 9.36.19 AM
หลังจากที่กลับไปอ่าน blog พบว่า
ยังไม่เคยอธิบายเรื่อง KISS (Keep It Simple Stupid) เลย
ดังนั้นลองมาทำความรู้จัก และ การนำไปใช้งาน
ตามแนวคิดนี้กันหน่อยสิ

แนวคิดต่าง ๆ ที่น่าสนใจ สำหรับนักพัฒนา

  • SOLID
  • DRY (Don’t Repeat Yourself)
  • YAGNI (You Aren’t Gonna Need It)
  • Boy Scout Rule

มาถึงเรื่อง KISS กันบ้าง มันคืออะไร ?

มันหมายถึง ให้เราทำอะไรก็ตามที่มันเรียบง่าย
แต่เชื่อเถอะว่า มันไม่ง่ายเลย !!

ตัวอย่างเช่น
Code ที่มันเขียนง่าย ๆ มักจะอ่านง่าย
Code ที่มันเขียนง่าย ๆ มักจะเข้าใจง่าย
Code ที่มันเขียนง่าย ๆ มักจะมี Bug น้อย
Code ที่มันเขียนง่าย ๆ มักจะดูแลรักษาในอนาคตได้ง่าย

และคุณอาจจะคิดว่า ฉันก็ทำแบบนี้อยู่นะ !!
แต่ลองกลับไปดู code ที่คุณเขียนสิ ….
ทำไมถึงเขียนให้มันซับซ้อนได้ขนาดนั้น ?

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

จากที่บอกไปแล้วว่า เรียบง่าย มันไม่ง่ายเลย !!

เนื่องจากมันต้องเริ่มจากความคิด
คุณต้องมีความรู้ใน business domain ของระบบที่กำลังพัฒนา
คุณต้องมีความรู้ในเรื่องการเขียน code ที่ดี
คุณต้องมีความรู้ใน framework ที่นำมาใช้งาน
คุณต้องมีความรู้ในเครื่องมือที่นำมาใช้งาน
รวม ๆ คือ คุณต้องมีประสบการณ์

ตามคำที่คุณ Martin Fowler กล่าวไว้ว่า

Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.

ลองคิดเล่น ๆ กันหน่อยสิว่า
ในชีวิตการพัฒนา software นั้น
คุณเคยเห็น code ที่มันอ่านง่าย เข้าใจง่าย มากน้อยเพียงใด ?
คำตอบ อาจจะมาก หรือ น้อย ก็เป็นได้
แต่คิดว่า ส่วนใหญ่จะตอบว่าไม่มากเท่าไรนะ !!

บางคนอาจจะบอกว่า code ของเราอ่านง่าย ทำความเข้าใจได้ง่ายนะ
ลองให้เวลามันช่วยพิสูจน์สิ
เช่นอีกสัก 1 เดือน 6 เดือน หรือ 1 ปี กลับมาอ่าน
แล้วคุณจะค้นหาคำตอบได้ด้วยตัวเอง …

อธิบายไปไม่เห็นภาพ มาลองดูตัวอย่างการนำ KISS มาใช้ดีกว่า

มาเขียน code ที่มันเรียบง่ายกันบ้างสิ
เริ่มด้วยการเขียน code น้อย ๆ ( แต่เข้าใจง่ายนะ )

ลองคิดดูสิว่า
Code ยิ่งน้อย เวลาอ่านก็น้อย
Code ยิ่งน้อย เข้าน่าจะเข้าใจได้ง่ายขึ้น
Code ยิ่งน้อย เวลาในการ debug ก็น้อยตาม (ไม่เขียน test ใช่ไหม ?)
เช่น ถ้ามี bug คุณอยากไปหา bug ใน code 10 บรรทัด หรือ 100, 1000 บรรทัด ?

ตัวอย่างเช่น การตรวจสอบข้อมูลว่าเป็นตัวเลขหรือไม่ ?

คำถาม
คุณมีวิธีการแก้ไขปัญหานี้อย่างไร ?
คำตอบ
ค้นหาจาก google สิ เดี๋ยวก็มี link ไปยัง stackoverflow เองแหละ
จากนั้นก็หาวิธีการที่คน vote ให้เยอะ ๆ หรือเอาที่เราสบายใจเลย

แต่เดี๋ยวก่อนนะ นั่นมันคือวิธีการ หรือแนวคิด KISS หรือไม่ ?
ไม่น่าจะใช่นะ …

โดยปกติการแก้ไขปัญหามันจะมี 2 ทางง่าย ๆ คือ

  1. ใช้ Regular expression สิ ง่ายจะตาย
  2. วน loop เพื่อตรวจสอบข้อมูลแต่ละตัวอักษรว่าเป็นตัวเลขหรือไม่

การใช้งาน Regular expression มันง่ายมากนะ
แต่ปัญหาหลัก ๆ คือ นักพัฒนา และ ทีมพัฒนา มีความรู้เรื่องนี้ไหม ?
ถ้าไม่รู้อะไรเกี่ยวกับมันเลย นั่นคือ ปัญหา !!
แทนที่วิธีการนี้มันจะเรียบง่าย กลับกลายเป็นสิ่งที่ยากยิ่ง
แถมสร้างความซับซ้อนขึ้นมาอีก

หรือจะใช้แบบที่ 2 คือ วน loop ตรวจสอบข้อมูลไปเลยสิ ง่ายจะตาย !!

แต่ก่อนอื่นให้ลองพิจารณาว่า
ภาษาโปรแกรม และ framework ที่เราใช้งานมันมีหรือไม่ ?
อย่าไปลงทุนสร้างในสิ่งที่มีอยู่แล้วนะครับ
ไม่เช่นนั้น คุณอาจจะสร้าง code ที่ทำงานผิดพลาดขึ้นมาอีกก็ได้
Less is More นะ

รวมทั้งเรื่องอื่น ๆ เช่น พวก Date Time, การจัดรูปแบบข้อมูล และ Security เป็นต้น

ขอสรุปคำแนะนำในการเขียน code ไว้ดังนี้

  • ลดขอบเขตการทำงานของตัวแปร (variable) ให้แคบที่สุด
  • จำไว้ว่า Global variable มันแย่มาก
  • อย่าใชังานตัวแปรซ้ำแล้วซ้ำอีก มันงงมากมาย
  • แต่ละ method/function ควรมีขนาดเล็ก
  • เรื่องชื่อต่าง ๆ มันสำคัญมาก ๆ

และห้ามลืมพวก DRY, YAGNI และ SOLID ด้วยนะครับ

อยาก KISS มากขึ้นไหม ?

แนะนำให้อ่านหนังสือ Clean Code : A Handbook of Agile Software Craftsmanship เลยครับ
จากนั้น ก็ ฝึก ฝึก และ ฝึก

สุดท้ายขอฝากไว้ว่า

จงเขียน code ที่มันอ่านได้ง่าย เข้าใจง่าย
ลองให้เพื่อน ๆ และ ทีมช่วยกัน review ได้
เพื่อจะได้รับ feedback ที่ดีกลับมา สำหรับการปรับปรุงให้ดีขึ้น

ให้กำลังใจตัวเองด้วย เช่น
เมื่อคุณไปอ่าน code ของคนอื่นแล้วไม่รู้เรื่อง
อย่าเพิ่มกล่าวโทษตัวเองว่า
ทำไมตัวเราโง่อย่างนั้น โง่อย่างนี้
code แค่นี้ก็อ่านไม่รู้เรื่อง

แต่ให้ถามตัวเราเองดีกว่า ว่าเรายังขาดความรู้เรื่องอะไร
จากนั้นก็ทำการศึกษา เพื่อพัฒนาตัวเราเองให้ดีขึ้น