นั่งอ่านบทความเรื่อง 12 Software Architecture Pitfalls and How to Avoid Them
ทำการสรุป 12 ข้อที่ควรหลีกเลี่ยงหรือระมัดระวังสำหรับ Software architecture
ซึ่งหลัก ๆ แล้วจะพูดถึงเรื่อง
- คนที่ตัดสินใจด้าน architecture ของระบบ ควรเป็นคนในกลุ่มที่ลงมือทำ อย่าเชื่อใจหรือเชื่อมั่นคนอื่นที่ไม่รู้บริบทขององค์กร หรือ งานนั้น ๆ
- คนที่ลงมือทำ จะมีความรู้ความเข้าใจเกี่ยวกับความต้องการของระบบ และ ข้อจำกัดต่าง ๆ เป็นอย่างดี เพื่อให้รู้ ข้อดีและข้อเสียของการตัดสินใจนั้น ๆ ซึ่งปรับปลี่ยนได้ตลอด
- พูดถึงเรื่อง Quality Attribute Requirements (QARs) ของการออกแบบ architecture เพื่อให้ได้คุณภาพที่ดี ซึ่งการยกเว้นบางอย่าง อาจจะส่งผลให้เจอความล้มเหลวได้ง่าย ๆ คุณภาพต่อรองไม่ได้ ดังนั้นควรต้องกำหนก QARs ของระบบไว้ก่อนเสมอ
- อย่า copy จากที่อื่นมาใช้งาน หรือ ระมัดระวังการ resuse เพราะว่า แต่ละอย่างถูกสร้างมาเพื่อแก้ไขปัญหาที่แตกต่างกัน
- การ evaluate ที่ดีที่สุดคือ การลงมือสร้างและทดสอบ เพื่อให้ได้ feedback ที่รวดเร็วจากผู้ใช้งานจริง ๆ จะดีกว่าการออกแบบให้ perfect แต่ใช้เวลานาน ซึ่งเป็นแนวทางสู่ความล้มเหลว ดังนั้นการพัฒนาแบบ small increment เป็นสิ่งที่จำเป็นอย่างมาก เพื่อลดความเสี่ยงและสิ่งที่ไม่มีประโยชน์ออกไป
ตัวอย่างของ Quality Attribute Requirements trade-off
ลองนำแนวคิดเหล่านี้มาปรับใช้งานดูครับ
