ว่าด้วยเรื่องของ 4 Rules of Simple Design หรือกฎ 4 ข้อสำหรับการออกแบบที่เรียบง่าย
ซึ่งคิดโดยคุณ Kent Beck ในช่วงปี 90
เป็นแนวคิดพื้นฐานของการออกแบบ software
หัวใจหลักของกฎนี้ก็คือ นำทางให้เราทำให้เล็ก และ พาไปสู่การ refactoring
ดังนั้น มาดูรายละเอียดของกฎทั้ง 4 ข้อกันดูว่าเป็นอย่างไร
กฏ 4 ข้อประกอบไปด้วย
- Test Pass
- Express Intent
- No Duplication (DRY)
- Small
การนำกฏนี้ไปใช้งานจะต้องเรียงตามลำดับนะครับ
1. Test Pass
สิ่งแรกที่ควรจะต้องทำนั่นคือ ต้องทดสอบระบบงานให้ผ่านทั้งหมด
ลองคิดดูว่า
ถ้าคุณไม่สามารถทดสอบ และ ตรวจสอบ ระบบที่คุณพัฒนาทั้งหมดว่ามันทำงานได้ถูกต้องหรือไม่
แล้ว คุณจะมั่นใจในสิ่งที่คุณออกแบบ และ พัฒนาได้อย่างไร
ดังนั้น ควรที่จะต้องทำก่อนเสมอ ใช่ไหม !!
ในปัจจุบันเรามีเครื่องมือมากมายสำหรับการทำ Automated test
แต่กฏข้อนี้เน้นที่ Test Pass ไม่ใช่ Automated Test Pass นะ
เนื่องจากคำว่า Test Pass มันหมายความว่า
เราจะทำการตรวจสอบความถูกต้อง พิสูจน์ว่าระบบยังทำงานได้ตามที่คาดหวัง
และมันจะช่วยให้เราง่ายต่อการเปลี่ยนแปลงสิ่งต่าง
เพราะว่า ถ้าเปลี่ยนแปลงอะไรแล้ว ให้ทำการทดสอบ
เราจะรู้ได้ทันทีว่ามันกระทบส่วนไหนบ้าง
ดังนั้น เรื่องเวลาในการทดสอบจะสำคัญมากๆ
นั่นคือ คุณจำเป็นต้องมี Automated test เข้ามาใช้นั่นเอง
เพื่อเพิ่มความเร็วในการทดสอบ และ feedback
คำถามยอดนิยม
การทดสอบที่บอกว่าต้องเร็วเนี่ย มันต้องเร็วเท่าไรจึงจะดี ?
คำตอบง่ายๆ คือ
เร็วกว่าเดิม
2. Express Intent
บ่อยครั้งแค่ไหนที่เหล่า developer ต้องไปพบเจอ หรือทำการสร้าง code
ที่มีชื่ออารมณ์นี้ process_transaction()
แต่เมื่อเข้าไปดูในรายละเอียดกลับพบว่า
การทำงานมันไม่เป็นไปตามชื่อเลย แปลกไหมนะ ?
มันเป็นกรณีที่สุดตริงกระดิ่งแมวมากๆ นั่นคือ ปัญหาหลักของการพัฒนาเลย
ลองคิดดูว่า ถ้า developer กลับมาแก้ไขแล้วจะเกิดอะไรขึ้น ?
เมื่อชื่อ method กับสิ่งที่ทำงานจริงมันไม่ไปด้วยกัน
นั่นคือที่มีของสิ่งเล็กๆ ที่เรียกว่า Bug
คุณสมบัติหนึ่งของ code ที่มีคุณภาพสูง คือ
เมื่อต้องกลับมาแก้ไขแล้ว จะต้องใช้เวลาในการหาส่วนที่แก้ไขได้อย่างรวดเร็ว
นั่นคือ เรื่องชื่อจะสำคัญมากๆ ใช่ไหม
ถ้าชื่อมันไม่สื่อ ก็ยากที่คุณจะทำงานกับมัน
ดังนั้น แก้ไขเรื่องชื่อซะ แล้วชีวิตจะดีขึ้นมาก
ลองกลับไปสังเกตสิ่งที่ developer หรือคุณทำดูสิ
ว่ายิ่งนับวันใน class, method มักจะมีส่วนการทำงานที่ไม่ได้เกี่ยวข้องกันมาอยู่ด้วยกัน
ส่งผลให้การตั้งชื่อนั้นยากมากๆ
นั่นคือ สัญญาณที่ไม่ดีของ code หรือ ระบบที่เรากำลังพัฒนานะครับ
ได้เวลาที่ต้อง Refactoring กันได้แล้ว
3. No Duplication (DRY)
เป็นกฎที่น่าสนใจ และ สำคัญมากๆ … แต่แปลกนะเรามักจะทำตรงข้ามเสมอ
คนส่วนมักคิดว่ากฎข้อดีมันหมายถึง code ที่ซ้ำซ้อน
แต่จริงๆ แล้ว กฏข้อนี้หมายถึง Knowledge duplication นะ
โดยกฏข้อนี้มักจะอธิบายด้วยคำว่า DRY (Don’t Repeat Yourself) นั่นคือ
Every piece of knowledge should have one and only one representation.
นั่นหมายความว่าสิ่งที่คุณคิด พูด ทำ ออกมานั้นจะต้อง Once and Only Once เท่านั้น
ดังนั้น แทนที่จะสนใจเพียง code duplication
ให้กลับไปถามตัวเองว่า สิ่งที่เรากำลังจะทำมันคือ Knowledge ที่มีอยู่ในระบบแล้วหรือไม่ ?
4. Small
ถ้าคุณทำตามกฏทั้ง 3 ข้อแล้ว ในข้อนี้คือ ผลที่ตามมา
เชื่อไหมล่ะ ?
ถ้าไม่เชื่อลองทำดูสิ …
วิธีการง่ายๆ ลองถามตัวเองก่อนสิว่า
1. มี code ส่วนไหนที่ไม่ถูกใช้งานบ้างหรือเปล่านะ ?
บ่อยครั้งเราจะพบว่า มี code หลายๆ ส่วนในระบบงาน
มันไม่ถูกเรียกใช้งานเลย แล้วทำไมมันยังอยู่ในระบบล่ะ
ดังนั้น ถ้าไม่มีใครใช้ก็ควรลบมันออกไปซะ
2. มีอะไรที่มันซ้ำซ้อนไหม ?
ถ้ามี แสดงว่าได้เวลาที่ต้องทำการ refactoring แล้วนะ ง่ายมากๆ
โดยสรุปแล้ว
จะเห็นได้ว่า กฏทั้ง 4 ข้อนั้นมันเรียบง่ายจริงๆ
แต่แปลกนะ มักจะมีคนแหกกฏ หรือ ไม่สนใจมันเลย !!
สิ่งที่สำคัญมาก สำหรับการนำกฎหล่านี้ไปใช้งานก็คือ
การค่อยๆ ทำไปทีละขั้นตอนเล็กๆ step-by-step
ส่วนที่ต้องทำบ่อยๆ ก็คือ
- แก้ไขเรื่องการตั้งชื่อให้มันตรงหน้าที่การทำงาน
- ทำการขจัดส่วนที่มันซ้ำซ้อน ทั้ง code และ knowledge
ดังนั้น กลับมาสู่เรื่องพื้นฐานหรือสามัญกันครับ
แปลกนะ !! เรื่องพื้นฐานที่มักถูกมองข้ามไป
