คุณ Martin Fowler ได้ทำการเขียนสรุปเรื่อง Rule Of Simple Design ขึ้นมา
ซึ่งเขียนในบทความ BeckDesignRules
เห็นว่าน่าสนใจเลยเอามาแปลอีกครั้งหนึ่ง ดังนี้

คุณ Kent Beck คือ ผู้สร้าง Extreme Programming (XP) ในช่วงปี 1990 ที่เราหลายๆ คนรู้จักกัน
และได้แนะนำ Rule of Simple Design ขึ้นมา
ซึ่งประกอบไปด้วย 4 ข้อดังนี้

  • Runs all the tests
  • Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies
  • States every intention important to the programmer
  • Has the fewest possible classes and methods

และทางคุณ Martin Fowler เรียกสั้นๆ ดังนี้

  • Passes the tests
  • Reveals intention
  • No duplication
  • Fewest elements

จากกฎทั้ง 4 ข้อนั้น ได้ทำการเรียงตามลำดับความสำคัญจากสูงไปน้อย
นั่นแสดงว่า Passes the tests สำคัญสุดๆ นะ
ลองคิดตามดูสิ ถ้า test ทั้งหมดไม่ผ่านนะ จะทำอย่างอื่นต่อไปได้อย่างไร
ซึ่งมันคือ หัวใจของกฎนี้เลยนะ

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

ต่อมาให้ทำ Reveals intention มันคืออะไรนะ ?

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

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

จากนั้นคือ No duplication

เป็นกฎที่แจ่มมากๆ เนื่องจาก code ที่เราสร้างขึ้นมานั้น
ไม่ควรจะซ้ำซ้อนกัน หรือ ทำงานเดิมๆ ในหลายที่
นั่นคือต้องยึดแนวคิดพวก

  • DRY (Don’t Repeat Yourself)
  • SPOT ( Single Point Of Truth )
  • OAOO ( Once and Only Once )

ดังนั้น นักพัฒนาทุกๆ คน ควรที่จะดู code ที่พัฒนาว่า
มี code ส่วนไหนที่มันซ้ำซ้อนหรือไม่
ทั้ง code ที่ซ้ำซ้อน และ ความรู้ที่ซ้ำซ้อน
เมื่อพบแล้ว ให้ทำการลดความซ้ำซ้อนนั้นลงซะ
มันง่ายๆ มาก นะ
แล้วมันจะทำให้การออกแบบระบบของคุณดีขึ้นเรื่อยๆ

มาถึงข้อสุดท้ายคือ Fewest elements

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

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

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

มาดูการเรียงลำดับความสำคัญของกฎทั้ง 4 ข้อ

sketch

คำอธิบาย
จากรู้เราจะเห็นว่า Reveals intension และ No duplication มันมีความสำคัญเท่าๆ กันเลยนะ

คำถามจึงเกิดขึ้นว่า แล้วลำดับควรเป็นอย่างไรดีล่ะ ?

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

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

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

จะเห็นได้ว่า Rule of Simple Design มันเข้าใจได้ง่ายมากๆ

แต่บสงคนก็บอกว่า มันทำยากมากๆ ( ทำยาก กับ ไม่ทำ มันต่างกันมากนะ )
โดยที่กฎนี้มันสามารถนำไปใช้เพื่อปรับปรุง code ให้ดีขึ้น
ไม่จำกัดในภาษาโปรแกรมใดๆ เลยนะ
ดังนั้น อย่าลืมนำไปใช้งานกันนะครับ !!!

Simple not Easy …
แต่คุณสามารถ Practice Practice Practice …. Practice

ปล.
ซึ่งผมเคยอธิบายไว้ในบทความเรื่อง สูงสุดคืนสู่สามัญด้วย 4 Rules of Simple Design