บทนำ: บทความนี้ให้อะไรกับคุณ

ซอฟต์แวร์ที่ดีไม่ได้วัดกันแค่ว่า "ทำงานได้" แต่วัดกันว่า "ทำงานได้ต่อไปอีก 2 ปีโดยทีมอื่นยังแก้ได้ไหม" บทความนี้จะพาคุณเชื่อมโยงสามเรื่องที่แยกกันไม่ได้คือ การออกแบบซอฟต์แวร์ (software design), ความสามารถในการดูแลรักษา (maintainability) และการตัดสินใจเชิงเทคนิค (technical decision-making) โดยอธิบายแบบไม่ใช้ศัพท์เทคนิคฟุ่มเฟือย มีตัวอย่าง หลักการ และเครื่องมือที่เอาไปใช้ได้ทันที

คุณจะได้:

• เข้าใจว่าทำไมโค้ดที่ดูแลยากถึงแพงกว่าที่คิด
• หลักการออกแบบที่พิสูจน์แล้วอย่าง SOLID, Separation of Concerns และ Modularity
• เทคนิคประจำวันที่เพิ่ม maintainability โดยไม่ต้องรื้อระบบ
• วิธีตัดสินใจเชิงเทคนิคให้โปร่งใส ตรวจสอบได้ด้วย ADR

ทำไมการออกแบบถึงกำหนดชะตาของซอฟต์แวร์

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

ผลที่ตามมา:

• เพิ่มเวลาเข้าใจโค้ดใหม่
• เพิ่มความเสี่ยงเมื่อต้องเพิ่มฟีเจอร์
• เพิ่มต้นทุนการทดสอบ

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

หลักการออกแบบที่ช่วยให้ดูแลได้จริง

1. SOLID Principles

แนวคิดจาก Robert C. Martin หรือ Uncle Bob ที่เป็นแกนของ Object-Oriented Design:

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

การทำตาม SOLID ไม่ได้ทำให้โค้ดเร็วขึ้นทันที แต่ทำให้ต้นทุนการดูแลลดลงอย่างมีนัยสำคัญ โดยเฉพาะในโปรเจกต์ขนาดใหญ่และอยู่ยาว

2. Separation of Concerns และ Modularity

• แยกสิ่งที่ต่างเหตุผลออกจากกัน เช่น แยก Business Logic ออกจาก UI และ Data Access
• ทำเป็นโมดูลเล็กที่พัฒนา ทดสอบ และ deploy แยกกันได้ เช่น MVC, Clean Architecture, Hexagonal Architecture
• แต่ละโมดูลควรมีขอบเขตชัดเจน สื่อสารผ่าน API ที่นิยามไว้ ไม่แอบเรียกภายในกันเอง

3. Operability, Simplicity, Evolvability

แนวคิดที่หลายทีมใช้ประเมินสถาปัตยกรรมสมัยใหม่:

• Operability: ระบบต้องสังเกตได้ มี log, metric, trace ที่ดี
• Simplicity: ถ้าอธิบายให้เพื่อนร่วมทีมเข้าใจใน 5 นาทีไม่ได้ แปลว่าซับซ้อนไป
• Evolvability: ออกแบบให้เปลี่ยนได้ ไม่ใช่ให้รองรับทุกอนาคตตั้งแต่แรก

เทคนิคเพิ่ม Maintainability ในชีวิตประจำวัน

หลักการใหญ่จะไม่มีประโยชน์ถ้าไม่ลงมือทำทุกวัน นี่คือสิ่งที่ทำได้ทันที:

• ตั้งชื่อให้สื่อความหมาย: calculateMonthlyFee() ดีกว่า calc() หรือ doIt() ชื่อที่ดีลดเวลาอ่านลงครึ่งหนึ่ง
• เขียนโค้ดให้อ่านเหมือนเล่าเรื่อง: แยกฟังก์ชันเล็ก ทำงานเดียว ใช้ early return ลดการซ้อน if
• ลดการซ้ำซ้อน (DRY อย่างมีสติ): ซ้ำซ้อนเล็กน้อยที่แยกบริบทชัดเจน บางครั้งดีกว่า abstraction ที่ผิดที่แล้วผูกทุกอย่างเข้าด้วยกัน
• ทดสอบอัตโนมัติ: Unit test และ integration test คือตาข่ายนิรภัย เวลารีแฟกเตอร์แล้วรู้ทันทีว่าพังตรงไหน
• เอกสารที่อยู่ใกล้โค้ด: README สั้น ๆ, ตัวอย่างวิธีรัน, และคอมเมนต์อธิบาย "ทำไม" ไม่ใช่ "ทำอะไร"
• รีแฟกเตอร์แบบต่อเนื่อง: ไม่ต้องรอโปรเจกต์ใหญ่ แก้กลิ่นโค้ดเล็ก ๆ ทุกครั้งที่แตะไฟล์ เช่น เมธอดยาวเกิน 50 บรรทัด หรือพารามิเตอร์เกิน 4 ตัว

ปัญหาที่พบบ่อย	สัญญาณ	วิธีแก้เบื้องต้น
God Class	คลาสเดียวทำทุกอย่าง	แยกตามความรับผิดชอบ ใช้ SRP
Tight Coupling	แก้ที่เดียวพังหลายที่	ใช้ Dependency Injection และ Interface
ขาดการทดสอบ	กลัวแก้โค้ด	เพิ่ม test รอบจุดที่แก้บ่อยก่อน

การตัดสินใจเชิงเทคนิค: จากความรู้สึกสู่กระบวนการ

ทีมส่วนใหญ่ตัดสินใจด้วยประสบการณ์และความเคยชิน ซึ่งไม่ผิด แต่เมื่อทีมโตขึ้น การตัดสินใจแบบปากเปล่าทำให้เกิดปัญหา:

• คนใหม่ไม่รู้ว่าทำไมถึงเลือกฐานข้อมูลนี้
• ถกเถียงซ้ำเรื่องเดิมทุก 6 เดือน
• เปลี่ยนใจโดยไม่มีบันทึกผลกระทบ

กรอบคิดที่ดีควรมี 4 ขั้น:

1. ระบุบริบท: เรากำลังแก้ปัญหาอะไร ข้อจำกัดคืออะไร เช่น ต้องรองรับ 10k req/s ภายในงบปัจจุบัน
2. ลิสต์ทางเลือก: อย่างน้อย 2-3 ทางเลือก รวมทางเลือก "ไม่ทำอะไร"
3. ประเมิน trade-off: ความเร็ว vs ความซับซ้อน, ต้นทุนพัฒนา vs ต้นทุนดูแล, ความคุ้นเคยของทีม vs ความเหมาะสมทางเทคนิค
4. บันทึกผลและผลกระทบ: ตัดสินใจอะไร เพราะอะไร ยอมรับผลข้างเคียงอะไรบ้าง

หลักการ SOLID เองก็มีต้นทุน การทำ abstraction มากเกินไปในโปรเจกต์เริ่มต้นอาจเพิ่มความซับซ้อนโดยไม่จำเป็น ดังนั้นต้องชั่งน้ำหนักตามบริบท ไม่ใช่ทำตามหลักการแบบเคร่งครัดทุกที่

ADR: เครื่องมือบันทึกการตัดสินใจที่ทีมสมัยใหม่ใช้

Architecture Decision Record หรือ ADR คือเอกสารสั้น ๆ ปกติยาวไม่เกินหนึ่งหน้า อยู่ใน repository ใต้โฟลเดอร์ docs/adr/ เพื่อบันทึกการตัดสินใจสำคัญหนึ่งเรื่อง

แนวคิดนี้ถูกเสนอโดย Michael Nygard ในปี 2011 ในบทความ Documenting Architecture Decisions เพื่อแก้ปัญหาคลาสสิกที่ว่า คนมาใหม่เจอโค้ดที่ตัดสินใจไปแล้วแต่ไม่มีเหตุผลประกอบ เลยต้องเดาเอาเอง

โครงสร้าง ADR ที่นิยม (MADR Template):

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

ตัวอย่างสั้น: markdown

ADR-003: ใช้ REST แทน GraphQL สำหรับ Public API v1

Context

ทีมมีเวลา 6 สัปดาห์ ต้องเปิด API ให้พาร์ทเนอร์ภายนอก ทีมคุ้นเคยกับ REST มากกว่า

Decision

ใช้ REST + OpenAPI สำหรับ v1 ประเมิน GraphQL ใหม่ใน v2

Consequences

ดี: ส่งมอบเร็ว, เอกสารอัตโนมัติ เสีย: อาจต้องทำ versioning ถี่ขึ้นเมื่อ query ซับซ้อน

ข้อดีคือทำให้การตัดสินใจโปร่งใส ย้อนดูได้ และเมื่อบริบทเปลี่ยน เราสร้าง ADR ใหม่ที่ระบุว่า Superseded ADR เก่า แทนการลบทิ้ง

ข้อควรระวัง: เมื่อหลักการกลายเป็นภาระ

• Over-engineering: ใส่ design pattern ทุกที่ทั้งที่ยังไม่ต้องใช้ จำไว้ว่าโค้ดที่ง่ายและทำงานได้ตอนนี้ ดีกว่าโครงสร้างอลังการที่ไม่มีใครเข้าใจ
• วัดไม่ได้แล้วปรับไม่ได้: ใช้ตัวชี้วัดง่าย ๆ เช่น lead time ในการเพิ่มฟีเจอร์, จำนวนบั๊กที่เกิดจากการแก้, เวลา onboarding ของสมาชิกใหม่
• ตัดสินใจคนเดียว: การตัดสินใจสำคัญควรมีคนรีวิวอย่างน้อยหนึ่งคน ไม่ใช่เพื่อหาคนผิด แต่เพื่อกระจายความเข้าใจ
• ไม่มีการทบทวน: ตั้งเวลา 3-6 เดือนกลับมาอ่าน ADR เก่า บริบทเปลี่ยน เทคโนโลยีเปลี่ยน การตัดสินใจควรเปลี่ยนได้

สรุปและเช็กลิสต์เริ่มต้นวันนี้

ซอฟต์แวร์ที่ดูแลง่ายไม่ได้เกิดจากเครื่องมือแพงหรือภาษาใหม่ แต่เกิดจากวินัยเล็ก ๆ ที่ทำซ้ำทุกวัน บวกกับกระบวนการตัดสินใจที่บันทึกไว้

เช็กลิสต์ 7 ข้อที่คุณเริ่มได้ในสัปดาห์นี้:

1. เลือกโมดูลที่แก้บ่อยที่สุด 1 โมดูล ลองแยกความรับผิดชอบตาม SRP
2. เพิ่มเทสต์ให้จุดที่กลัวแตะที่สุดก่อน
3. ตั้งกติกา naming convention ของทีมและทำ code review ให้สม่ำเสมอ
4. สร้างโฟลเดอร์ docs/adr/ และเขียน ADR แรกของการตัดสินใจที่ค้างอยู่
5. บันทึก trade-off ทุกครั้ง ไม่ใช่แค่ผลลัพธ์
6. ลด coupling ด้วยการพึ่งพา interface แทน implementation โดยตรง
7. ทบทวน ADR ทุกไตรมาส ถามว่า "บริบทเดิมยังจริงอยู่ไหม"

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

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

• SOLID Principles - Robert C. Martin และคำอธิบายหลักการออกแบบที่ยั่งยืน
• Documenting Architecture Decisions โดย Michael Nygard - ต้นฉบับแนวคิด ADR
• MADR - Markdown Architecture Decision Records Template
• Martin Fowler - บทความเรื่อง Technical Debt และ Refactoring
• The Ultimate Guide to Software Maintainability - หลักการ modularity และ maintainability