ออกแบบซอฟต์แวร์ให้อยู่รอด: คู่มือ Maintainability และการตัดสินใจ

ซอฟต์แวร์ที่ดีไม่ได้วัดกันที่ตอนเปิดตัว แต่วัดกันที่ 6 เดือนหรือ 2 ปีต่อจากนั้นว่าเรายังกล้าแก้โค้ดเดิมหรือไม่ บทความนี้จะพาคุณเข้าใจว่าทำไมการออกแบบ (Software Design) ที่ดีถึงเป็นรากฐานของ Maintainability และทำไมการตัดสินใจทางเทคนิค (Technical Decision-Making) จึงต้องทำอย่างมีกระบวนการ ไม่ใช่แค่ตามกระแส

คุณจะได้แนวคิดหลัก ตัวอย่างจริง เครื่องมืออย่าง ADR และเช็กลิสต์ที่ใช้ได้ทันทีสำหรับทีมขนาดเล็กถึงขนาดกลาง

1. ทำไม Maintainability ถึงสำคัญกว่าความเร็วในตอนแรก

Maintainability คือความสามารถในการเข้าใจ แก้ไข ทดสอบ และขยายซอฟต์แวร์โดยใช้ต้นทุนต่ำ งานวิจัยและประสบการณ์ภาคสนามชี้ตรงกันว่า ต้นทุนส่วนใหญ่ของซอฟต์แวร์ไม่ได้อยู่ที่การเขียนครั้งแรก แต่อยู่ที่การดูแลรักษา

ซอฟต์แวร์ที่ดูแลยากมักมีอาการเหล่านี้:

• แก้จุดหนึ่งแล้วพังอีกจุดหนึ่งโดยไม่คาดคิด
• ต้องอ่านโค้ดทั้งหมดเพื่อเข้าใจฟีเจอร์เล็ก ๆ
• ไม่มีใครกล้าลบโค้ดเก่า เพราะไม่รู้ว่าใครใช้อยู่
• การ deploy ต้องใช้คนเดิมเท่านั้นถึงจะทำได้

หลักการสำคัญคือ operability, simplicity, evolvability ตามที่ชุมชนวิศวกรรมซอฟต์แวร์พูดถึงบ่อย — ระบบต้องทำงานได้จริง เข้าใจง่าย และพร้อมจะวิวัฒนาการไปกับความต้องการธุรกิจ

2. หลักการออกแบบที่ช่วยให้โค้ดอยู่ได้นาน

2.1 SOLID — พื้นฐานที่ยังใช้ได้จริง

• SRP (Single Responsibility): คลาสหรือโมดูลหนึ่งควรมีเหตุผลในการเปลี่ยนเพียงอย่างเดียว ช่วยลดผลกระทบเมื่อ requirement เปลี่ยน
• OCP (Open/Closed): เปิดให้ขยาย แต่ปิดไม่ให้ต้องแก้ของเดิมบ่อย ใช้ interface และ composition แทนการแก้ if-else ยาว ๆ
• LSP (Liskov Substitution): คลาสลูกต้องแทนที่คลาสแม่ได้โดยไม่ทำให้พฤติกรรมผิดเพี้ยน
• ISP (Interface Segregation): แยก interface ใหญ่ให้เป็น interface เล็กเฉพาะทาง
• DIP (Dependency Inversion): พึ่งพา abstraction ไม่ใช่ implementation ตรง ๆ ทำให้ทดสอบและสลับเทคโนโลยีง่าย

2.2 Separation of Concerns และ Loose Coupling

แยกเลเยอร์ให้ชัด เช่น Presentation, Domain, Data/Infrastructure อย่าให้โค้ดคำนวณธุรกิจไปปนกับโค้ดเรียก API หรือโค้ดแสดงผลโดยตรง เมื่อ coupling ต่ำ การเปลี่ยนฐานข้อมูลหรือเปลี่ยน UI จะไม่ลามไปทั้งระบบ

2.3 DRY, KISS และความเรียบง่ายที่ถูกตีความผิด

DRY ไม่ได้แปลว่าห้ามซ้ำกันเลย แต่หมายถึงอย่าซ้ำความรู้ (knowledge) ที่เดียวกันในหลายที่ KISS เตือนให้เราเลือกวิธีที่เรียบง่ายที่สุดที่แก้ปัญหาได้จริงก่อน การทำ abstraction เร็วเกินไปก็เป็นหนี้เทคนิคอีกรูปแบบหนึ่ง

3. การตัดสินใจทางเทคนิคคือการจัดการ Trade-off

กฎข้อแรกของสถาปัตยกรรมซอฟต์แวร์ที่หลายคนอ้างถึงคือ "ทุกอย่างคือการแลกเปลี่ยน" (Everything is a trade-off) ไม่มีสถาปัตยกรรมที่สมบูรณ์แบบ มีเพียงสถาปัตยกรรมที่ trade-off เหมาะกับบริบทนั้นมากที่สุด

ตัวอย่าง trade-off ที่เจอบ่อย:

การตัดสินใจ	ได้อะไร	เสียอะไร
Monolith vs Microservices	Deploy ง่ายตอนแรก, transaction ง่าย	Monolith จะขยายทีมยาก, Microservices ซับซ้อนด้าน observability
Consistency vs Availability	ข้อมูลถูกต้องเสมอ	อาจตอบช้าหรือไม่พร้อมใช้งานเมื่อ partition
สร้างเอง vs ใช้ของสำเร็จรูป	ควบคุมได้เต็มที่	ต้องดูแลเองระยะยาว

คำถามที่ช่วยตัดสินใจ:

1. ปัญหานี้เป็นปัญหาสถาปัตยกรรม (ยากจะย้อนกลับ) หรือเป็น design decision (แก้ทีหลังได้)?
2. เรากำลังแก้ปัญหาของวันนี้หรือปัญหาที่จินตนาการไว้ในอีก 2 ปี?
3. ทีมมีความสามารถในการ operate สิ่งที่เราเลือกหรือไม่?

4. เครื่องมือทำให้การตัดสินใจโปร่งใส: ADR

Architecture Decision Record (ADR) คือบันทึกสั้น ๆ ที่อธิบายว่าเราตัดสินใจอะไร ทำไม และผลที่ตามมาคืออะไร รูปแบบที่นิยมมาจาก Michael Nygard ช่วยแก้ปัญหา Groundhog Day ที่ต้องถกเรื่องเดิมซ้ำ ๆ

โครงสร้าง ADR อย่างง่าย:

• Title: เช่น ADR-005: เลือก PostgreSQL เป็น primary database
• Status: Proposed / Accepted / Deprecated / Superseded
• Context: ปัญหาหรือแรงจูงใจ อะไรทำให้ต้องตัดสินใจ
• Decision: เราตัดสินใจทำอะไรอย่างชัดเจน
• Consequences: ผลดี ผลเสีย และสิ่งที่ต้องทำต่อ

แนวปฏิบัติ:

• เขียน ADR ให้สั้น อ่านจบใน 5 นาที
• เก็บไว้ใน repo ใกล้โค้ด เช่น /docs/adr/
• ทุกการตัดสินใจสำคัญต้องมี ADR ไม่ใช่แค่ประชุมแล้วจบใน Slack

5. แนวทางปฏิบัติเพื่อเพิ่ม Maintainability จริงในทีม

1. ตั้งชื่อให้สื่อความหมาย: ชื่อตัวแปร ฟังก์ชัน และไฟล์ควรอธิบายเจตนา ไม่ใช่แค่ชนิดข้อมูล
2. เขียนโค้ดให้คนอ่าน ไม่ใช่ให้คอมไพเลอร์: ทำฟังก์ชันสั้น มีทางออกเดียว หลีกเลี่ยง nesting ลึกเกิน 3 ชั้น
3. ทดสอบเป็น safety net: ไม่ต้อง 100% coverage แต่ต้องมี test สำหรับพฤติกรรมสำคัญและขอบเขตที่พังบ่อย
4. ทำ Code Review ที่เน้นการเรียนรู้: ใช้ checklist เช่น อ่านเข้าใจใน 2 นาทีไหม? มี test ไหม? มีการจัดการ error ชัดเจนไหม?
5. Refactor แบบเล็กและต่อเนื่อง: แทนที่จะรอโปรเจกต์ใหญ่ ให้ทำ Boy Scout Rule — เข้าไปแล้วทำให้ดีกว่าเดิมเล็กน้อย
6. Observability ตั้งแต่วันแรก: log, metric, trace ที่ดีช่วยให้ debug เร็ว ลดความกลัวในการแก้โค้ด

6. ข้อควรระวังและกับดักยอดนิยม

• Over-engineering: ใส่ pattern, message queue, microservices ทั้งที่ระบบยังมีผู้ใช้หลักร้อย
• Under-engineering: เขียนทุกอย่างในไฟล์เดียวเพราะคิดว่า "เดี๋ยวค่อยแก้" จนแก้ไม่ได้
• Hype-driven decision: เลือกเทคโนโลยีเพราะบทความไวรัล ไม่ใช่เพราะเข้ากับปัญหาและทีม
• Covering Your Assets: ตัดสินใจแบบกลาง ๆ เพื่อไม่ให้ใครตำหนิได้ แต่ไม่มีใครได้ประโยชน์
• ไม่มีเจ้าของการตัดสินใจ: ทุกคนเห็นด้วยแบบคลุมเครือ พอมีปัญหาจะไม่มีคนรับผิดชอบ

วิธีแก้คือทำให้การตัดสินใจมีเจ้าของ มีกรอบเวลา และมีวิธีวัดผล เช่น "เราจะลองใช้วิธีนี้ 2 sprint แล้ววัดจาก lead time และ error rate"

7. เช็กลิสต์ก่อนตัดสินใจครั้งสำคัญ

• เราเข้าใจปัญหาธุรกิจจริงหรือยัง ไม่ใช่แค่ปัญหาทางเทคนิค?
• มีทางเลือกอย่างน้อย 2 ทางพร้อมข้อดีข้อเสียหรือไม่?
• ต้นทุนการดูแลรักษาใน 12 เดือนข้างหน้าคืออะไร?
• ทีมปัจจุบัน operate ได้ไหม ต้องเรียนรู้เพิ่มเท่าไร?
• มีแผนถอยกลับ (rollback) ถ้าเลือกผิดหรือไม่?
• ได้บันทึกเป็น ADR แล้วหรือยัง?

สรุป

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

เริ่มต้นง่าย ๆ ในสัปดาห์นี้: เลือกโมดูลที่แก้บ่อยที่สุด ใส่ SRP เข้าไป แยก concern ให้ชัด แล้วเขียน ADR แรกของทีม คุณจะเห็นว่าความกลัวในการแก้โค้ดลดลง และความเร็วของทีมในระยะยาวเพิ่มขึ้นอย่างชัดเจน

แหล่งข้อมูลอ้างอิง

• Documenting Architecture Decisions - Michael Nygard (Cognitect)
• SOLID Principles - Principles of Object-Oriented Design
• Architecture Decision Records - GitHub adr-tools
• Fundamentals of Software Architecture - Mark Richards & Neal Ford (O'Reilly)
• Most Software Architecture Decisions Are Actually About Trade-offs - dev.to