จากหนังสือ The Productive Programmer เขียนโดยคุณ Neal Ford
ได้แนะนำวิธีการเกี่ยวกับปรับปรุง code ให้ดีขึ้นกว่าเดิม
ซึ่งคิดว่า น่าจะมีประโยชน์กับ developer และ ตัวเอง
จึงได้นำมาสรุปไว้อ่านกันหน่อย
ปล. หนังสืออาจจะเก่าไปหน่อย เนื่องจากออกมาตั้งแต่ปี 2008
แต่เนื้อหายังไม่ล้าสมัยนะครับ
โดยข้อมูลนำมาจาก 10 Ways to Improve Your Code
1. Compose method
คือการแบ่งส่วนการทำงานออกเป็น method ย่อย ๆ
ซึ่งแต่ละ method ทำงานอย่างใดอย่างหนึ่ง
และมีชื่อที่สื่อสารได้ชัดเจน
ส่งผลให้ method มีจำนวน code น้อย ๆ
และง่ายต่อการทดสอบอีกด้วย
และอาจจะพบว่ามี code จำนวนมากที่ทำงานซ้ำ ๆ
ดังนั้นก็ยุบ ย่อ code เหล่านั้นลงซะ
ดังนั้นมาปรับปรุง หรือ refactoring to compose method กันเถอะ
2. ทำการเขียน test ก่อนเขียน code เสมอ
นั่นคือ Test-Driven Development (TDD) นั่นเอง
แต่จะเน้นไปที่ Test-Driven Design หรือ การออกแบบ
ซึ่งเป็นประโยชน์ที่ได้รับจาก TDD โดยตรง
ถึงแม้ว่าจะเป็นวิธีการที่เข้มงวด
แต่ประโยชน์ที่ได้กลับมาก็คือ
code ที่เราออกแบบ
code ที่เราเขียนขึ้นมา
มันง่ายต่อการทดสอบ
รวมทั้ง code ทุก ๆ ส่วนมีการทดสอบเสมอ
ลองคิดดูสิว่า
ถ้า code ที่คุณออกแบบ
ถ้า code ที่คุณเขียนขึ้นมา
มันทดสอบได้ยาก หรือ ไม่มีการทดสอบเลย
เราจะมั่นใจได้อย่างไรว่า code เหล่านั้นมันทำงานได้
เราจะมั่นใจได้อย่างไรว่า code เหล่านั้นมันดี
เราจะมั่นใจได้อย่างไรว่า code เหล่านั้นมันไม่สร้างปัญหา
เราจะมั่นใจได้อย่างไรว่า code เหล่านั้นมันทำงานร่วมกันได้อย่างถูกต้อง
3. ใช้งาน Static Analysis Tool ซะ
ถ้าใครยังไม่ใช้ FindBugs, PMD และ Coding standard อะไรพวกนี้
แนะนำให้นำมาใช้เถอะครับ
นำมาใช้เพื่อช่วยเราตรวจสอบ code ได้มุมมองต่าง ๆ เช่น
- Code ที่อาจจะก่อให้เกิด bug
- Code ที่เขียนแย่ ๆ
- Code ที่มีรูปแบบแย่
วันนี้คุณใช้งาน Static Analysis Tool แล้วหรือยัง ?
4. ให้ความสนใจ และ ใส่ใจ กับการติดต่อสื่อสารกันระหว่าง object
แต่ละ class/object ต้องทำงานเหมือนกับ blackbox
นั่นคือ คนใช้งานรู้เพียงว่า
ต้องส่ง input อะไรเข้ามา
แล้วจะได้ output อะไรออกไป
โดยไม่ต้องรู้สถานะ หรือ ข้อมูลอะไรเกี่ยวกับ class นั้น ๆ เลย
ดังนั้นต้องระวังการใช้งานพวก Global variable และ Singleton ให้มาก ๆ
หรือลด ละ เลิก มันไปเลย
เพราะว่ามันมีหน้าที่การทำงานที่เยอะเกินไป
ทั้งข้อมูล และ สถานะของ object
ซึ่งจัดการยากมาก ที่สำคัญทดสอบยากมาก ๆ
5. YAGNI (You Ain’t Gonna Need It)
กฏเหล็กเลยก็คือ
สร้างเฉพาะสิ่งที่เราต้องการในปัจจุบันขึ้นมาเท่านั้น
สิ่งที่สร้างควรจะเรียบง่าย ไม่ซับซ้อน
เพราะว่า developer มักจะเผื่อกันทั้งหมด !!
เผื่อไว้สำหรับอนาคต
นั่นคือ วิธีการที่สร้างความซับซ้อนขึ้นมาตั้งแต่เริ่มทำงาน
มันเป็นแนวคิดที่ไม่ถูกต้องมากนัก
ให้พึงระวังเป็นพิเศษ
มีอีกแนวคิดหนึ่ง คือ
เพื่อให้เราพัฒนาระบบงานได้เร็วขึ้น
เพื่อให้เราสนใจเฉพาะส่วนงานที่สำคัญ ๆ เท่านั้น
ดังนั้น เราควรนำ framework มาใช้งาน
แต่แปลกนะ !!
เมื่อนำ framework มาใช้งาน กลับเสียเวลาในการแก้ไขมากกว่าเดิมอีก !!
แสดงว่า การนำ framework มาใช้ก็มีข้อเสียนะ
ถ้าคุณต้องการแก้ไข และ เปลี่ยนแปลง framework นั้นมาก ๆ
ดังนั้นลองกลับมาดู code ของคุณสิว่า
มันเปลี่ยนแปลงได้ง่ายหรือไม่ ?
6. Code ของทีมต้องเหมือนกัน หรือ ไปในทิศทางเดียวกันเสมอ
ลองกลับไปดู code ของระบบที่ทีมกำลังพัฒนา สิว่า
มีรูปแบบที่เหมือน หรือ แตกต่างกัน ?
ถ้าต่างคนต่างทำงาน
ผลก็คือ code แตกต่างกันแน่นอน
ดังนั้น วิธีการแก้ไข ก็คือ Pair programming นั่นเอง
แต่มักจะมีข้อถกเถียงว่า มันเสียเวลานะ !!
ตอบได้เลยว่า ใช่
แต่ …
จากการวิจัย และ ทดสอบพบว่า
Pair programming นั่นทำให้การพัฒนาช้าลงไป 15%
แต่ผลจาก Pair programming นั้นช่วยลด bug ไป 15% เช่นกัน
ลองมาทำ Pair programming กันไหมครับ ?
7. Single Level of Abstraction Principle (SLAP)
code ทุก ๆ บรรทัดในแต่ละ method ต้องอยู่ใน level เดียวกันเสมอ
นั่นคือต้องใช้ Compose method นะ
มันสำคัญจริง ๆ นะ
8. Polyglot Programming
นั่นคือ เลือกภาษา program ให้เหมาะสมกับปัญหา
ไม่ใช่ว่า ใช้ภาษา program เดียว เพื่อแก้ไขปัญหาทุก ๆ อย่าง
ดังนั้น ควรเรียนรู้ และ เข้าใจเป้าหมายของแต่ละภาษาด้วยนะครับ
เช่นการสร้าง DSL ( Domain Specific Language ) ขึ้นมาด้วยภาษา Scala
ซึ่งเป็น DSL ที่อ่าน และ เข้าใจได้ง่าย
ส่วนการทำงานด้านหลัง อาจจะเป็นภาษา Java ก็ได้
9. AntiObject ?
มันคือการเปลี่ยนมุมมองในการสร้าง object
โดยแบ่งการทำงานออกเป็นส่วนของ background และ foreground
ซึ่งทำให้เราแก้ไขปัญหายาก ๆ ได้ง่ายขึ้น
เนื่องจากให้เราแก้ไขตามสิ่งที่ผู้ใช้งานเห็น
ทำการอธิบายเพื่อให้เข้าใจง่าย ๆ ด้วยเกมส์ Pacman
เป็นเกมส์ที่ออกมาตั้งแต่ปี 1970
ต้องทำงานบนเครื่องเล่นที่มีความสามารถต่ำ ๆ ได้
ทั้งขนาดของ memory ที่น้อยมาก ๆ
ทั้งความเร็วของ CPU ที่ช้ามาก ๆ
ซึ่งเป็นปัญหาที่ยากมาก ๆ สำหรับทีมพัฒนาเกมส์
รวมทั้งในเกมส์ต้องมีการคำนวณหลายอย่างมาก ๆ
คำถามคือ
ทีมพัฒนาแก้ไขปัญหานี้อย่างไรล่ะ ?
คำตอบคือAntiObject ไงล่ะ
คำถาม ยังไงนะ ?
แต่ล่ะ object ในเกมส์จะทำงานด้วยตัวของมันเอง
แต่ล่ะ object ในเกมส์จะคิดเอง
แต่ล่ะ object ในเกมส์จะไม่สนใจ object อื่น ๆ
นั่นคือ ทำงานตามแนวคิดเหมือนกันเกมส์ Conway’s Game of Life
ดังนั้นแต่ละ cell หรือ แต่ละช่องในเกมส์ จะมีกฎการทำงานเสมอ
ซึ่งมันเปลี่ยนแนวคิด และ วิธีการทำงานไปโดยสิ้นเชิง
ดังนั้น อย่าไปยึดติดกับแนวคิดเดิม ๆ มากนัก
ลองปรับ ลองเปลี่ยน มุมมองในการคิด และ แก้ไขปัญหาบ้างนะครับ
แล้วจะพบว่ามันมีวิธีการอีกมากมาย …
