ไม่มากก็น้อยไป สำหรับการพัฒนา

นั่งอ่านหนังสือ Real World Software Development ไปนิดหน่อย
พบรูปแบบของ code ที่น่าสนใจ นั่นก็คือ ไม่มากก็น้อยไป
จึงทำการสรุปไว้

เริ่มด้วย God Interface

นั่นคือใน interface หนึ่ง ๆ มี method จำนวนมาก
คำถามที่น่าสนใจคือ interface นี้จำเป็นต้องมี method เยอะแบบนี้ไหม ?
บ่อยครั้งจะเป็นแนวทางที่ขัดแย้งกับแนวคิด Interface Segregation Principle (ISP) 

[gist id="1687dc7b7c3bd5486b05e9e13fac1915" file="1.java"]

ดังนั้นน่าจะต้องแยกออกเป็นกลุ่ม ๆ  ตามกลุ่มงานเดียวกัน
ยกตัวอย่างเช่นการอ่านและการแก้ไขข้อมูลเป็นต้น
แต่บ่อยครั้งจะพบว่า ก็แยกกันเกินไป
อาจจะทำให้เกิด Low Cohesion อีก
หาความพอดีได้ไหมเนี่ย
ยกตัวอย่างเช่น

[gist id="1687dc7b7c3bd5486b05e9e13fac1915" file="2.java"]

ต่อมาก็เรื่องของ God Class

เรื่อง class ที่ทำมันไปหมดทุกอย่าง
ขัดแย้งกับแนวคิด Single Responsibility Principle (SRP) อย่างมาก
ทำให้ code ที่เขียนออกมา มันขัดแย้งกับ code ที่ดีอย่างมาก
ผลที่ตามมาคือ เข้าใจยาก ดูแลรักษายาก

เรื่องของการโยน Exception ออกมาก็น่าสนใจ

ทำไมโยน exception ออกมาตัวเดียวแบบนี้
แบบนี้ก็มักง่ายไปหน่อย หรือ น้อยไปหน่อยไหม ?
จะทำการจัดการ exception แบบนี้ต่อไปอย่างไรดี ?

[gist id="1687dc7b7c3bd5486b05e9e13fac1915" file="3.java"]

หรือลองจัดการด้วยการ Notification pattern ก็ดูดีขึ้นนะ

[gist id="1687dc7b7c3bd5486b05e9e13fac1915" file="4.java"]

อีกเรื่องที่น่าสนใจคือ การเขียน Test หรือ Automation Test

แนะนำให้เขียน
เพื่อเพิ่มความเชื่อมั่นที่มีต่อระบบ
เพื่อลดปัญหาหรือหาปัญหาจากการเปลี่ยนแปลงต่าง ๆ
เพื่อให้เข้าใจระบบมากยิ่งขึ้น

พบว่าปัญหาที่เจอคือ ไม่เขียน Test หรือเขียนแล้วไม่ช่วย
แต่กลับทำร้ายให้แย่กว่าเดิม เพราะว่า เขียนเพียงให้มี แต่ไม่ได้ทำให้มันดี

ในหนังสือเล่มนี้มีอีกหลายเรื่องที่น่าสนใจ
ไว้เอามาสรุปไว้อีกรอบ ไปอ่านต่อก่อน