YAGNI — กฎเหล็กที่กันโปรเจกต์ซอฟต์แวร์จากการตายเพราะ over-engineering พร้อม 4 ต้นทุนของ 'เผื่อไว้' ที่ Martin Fowler เตือน

5 สัญญาณว่าคุณกำลัง Violate YAGNI

อยาก audit ตัวเองง่ายๆ? ดูสัญญาณเหล่านี้ในโปรเจกต์ที่ทำอยู่

1. มี "Manager" หรือ "Factory" Class ที่จัดการของแค่ 1 ชนิด

ถ้าคุณมี UserFactory ที่สร้างได้แค่ User แบบเดียว — มันไม่ใช่ factory มันคือ over-abstraction

UserFactory มีค่าเมื่อจำเป็นต้องสร้าง User หลายแบบ (regular, admin, guest) จาก source หลายที่ — ถ้ายังไม่ใช่ ตัด

2. มี Configuration Option ที่ไม่มีใครเปลี่ยน

ทุก config option = code path เพิ่ม = test case เพิ่ม = ความซับซ้อนเพิ่ม

ถ้า config นั้นมีค่าเดียวมา 6 เดือนแล้ว → ลบมันออก ใส่ค่า hardcode ไปก่อน เมื่อถึงวันที่ต้องใส่ option จริงค่อยใส่กลับ

3. มี Interface ที่มี Implementation เดียว

PaymentProvider interface ที่มี StripePaymentProvider เป็นเพียง implementation เดียว — interface นั้นทำให้ navigation ลำบาก โดยไม่มีประโยชน์จริง

ใช้ class ตรงๆ ก่อน — เมื่อจำเป็นต้องมี implementation 2 — ค่อย extract interface

4. มี Database Field/Column ที่ไม่มี Code อ่าน

users.metadata column ที่เก็บ JSON "เผื่อใช้" — แต่ไม่มี code path ไหนอ่านหรือเขียน

ทุก field = ความรับผิดชอบ — schema migration ยากขึ้น, backup ใหญ่ขึ้น, นัก audit ต้องถามว่าเก็บอะไร PDPA-wise

5. มี "Generic" Function ที่ใช้ครั้งเดียว

utils/processAnyEntity() ที่ทำได้ทุกอย่าง — แต่ในโปรเจกต์เรียกใช้แค่ 1 ที่

function ที่ใช้ครั้งเดียวควรเป็น code ตรงในที่ที่ใช้ ไม่ต้อง extract — ทำให้คนอ่านไม่ต้องกระโดดข้ามไฟล์

---

เมื่อไหร่ที่ YAGNI กลายเป็นกับดัก

YAGNI เป็นหลัก guideline ไม่ใช่ดogma

มีกรณีที่ ต้อง over-engineer จริงๆ — เพราะการเพิ่มทีหลังจะแพงเกินไป หรือเสี่ยงเกินไป

Security and Compliance

อันนี้ไม่ใช่ YAGNI — ถ้าระบบจัดการข้อมูลส่วนบุคคล PDPA, GDPR หรือ financial data — ใส่ security control ตั้งแต่วันแรก:

• input validation
• authentication / authorization
• audit logging (ทุก action ที่แตะ PII)
• encryption at rest

เพราะการ retrofit security เข้าระบบที่ ship ไปแล้ว = แพงและเสี่ยงระเบิด

Audit Trail and Logging

ถ้าระบบมี business workflow ที่ต้อง trace ย้อนหลัง — ใส่ audit log ตั้งแต่วันแรก

ค่าใช้จ่ายในการเก็บ log = น้อย เทียบกับค่าเสียโอกาสเมื่อ event เกิดขึ้นแล้วไม่มี log

Data Schema Decisions

schema database เป็นสิ่งที่เปลี่ยนทีหลังยาก — โดยเฉพาะตาราง core

ใช้เวลา design schema ให้ดีตั้งแต่แรก (ไม่ใช่ over-engineer แต่ "เผื่อ" ในระดับ data shape ที่ make sense)

External API Contracts

API ที่ client ภายนอกใช้ = เปลี่ยนยากเพราะกระทบ consumer หลายราย

design carefully ตั้งแต่ v1 — versioning, error format, pagination

YAGNI ใช้ไม่ได้ตรงนี้ เพราะ cost of repair แพงมากเมื่อ break compatibility

---

YAGNI กับ Refactoring — ความเข้าใจผิดที่พบบ่อย

หลายคนคิดว่า YAGNI = "ห้าม refactor" — ผิด

Fowler ย้ำชัด — YAGNI ต้องการ codebase ที่ maintainable ถึงจะ work

หลักการคือ:

• เขียนเท่าที่จำเป็น (YAGNI)
• เมื่อต้องการเพิ่ม → refactor ของเดิม แล้วเพิ่ม (Refactoring discipline)
• มี test coverage ดี → refactor ปลอดภัย (TDD)
• มี continuous integration → ส่ง code ใหม่ได้ง่าย (CI/CD)

ถ้าทีมเขียน "minimal" แต่ codebase รก, ไม่มี test, deploy ลำบาก — YAGNI จะกลายเป็น technical debt generator

นี่คือเหตุผลที่ Beck ออกแบบ XP เป็น ชุดวิธีปฏิบัติร่วมกัน ไม่ใช่หลักเดี่ยว

---

วิธีที่ทีม Enersys ใช้ YAGNI ในงานจริง

ในฐานะ software house ที่ทำงาน Odoo, AI Integration และ Data Privacy (PDPA) ให้ลูกค้าองค์กรไทย — เราใช้ YAGNI เป็น guideline หลักทุกโปรเจกต์

ไม่ใช่เพราะแฟชั่น — แต่เพราะลูกค้าจ่ายเงินจริง และเราต้อง ส่งคุณค่าทุกบาท

Discovery Phase — ถาม "ต้องใช้เมื่อไหร่"

ก่อนเริ่มทุก feature เราถาม:

• ใครจะใช้ feature นี้?
• ใช้บ่อยแค่ไหน?
• ถ้าไม่มี feature นี้ user ทำงานต่อได้ไหม?
• มี alternative ที่ง่ายกว่าไหม?

ถ้าคำตอบกำกวม → defer ไม่ใส่ใน scope รอบนี้

Scope Negotiation — แยก "Must Have" จาก "Nice to Have"

ลูกค้าหลายรายส่ง requirement ที่มี 100+ ข้อ — บางข้อ "nice to have" ที่ทำให้ผ่านสบายๆ จะ delay timeline ไป 2-3 เดือน

หน้าที่เราในฐานะ consultant คือถามตรงๆ — "ข้อนี้ถ้ายังไม่มีในเดือนหน้า กระทบธุรกิจไหม"

ถ้าไม่กระทบ → ดันไป phase 2

Architecture Decisions — Start Simple, Refactor Later

โปรเจกต์ Odoo ส่วนใหญ่เริ่มจาก standard module + minimal customization

ไม่ build framework ตัวเอง ไม่ทำ abstraction layer ใหม่ ใช้ของ Odoo ตามที่มี

เมื่อ requirement พิเศษมาถึง → ค่อย extend อย่างมีหลัก ไม่ใช่ "preemptive flexibility"

Code Review — Challenge ทุก Abstraction

ใน review ถ้าเห็น interface, factory, manager, generic util — ถามทุกครั้ง

• มี implementation ที่ 2 ไหม?
• ถ้ายังไม่มี ตอนนี้จำเป็นต้องมี abstraction ไหม?
• ลบทิ้งได้ไหม?

หลายครั้งคำตอบคือ — ลบได้ → ลบ → code base เล็กลง → maintain ง่ายขึ้น

Documentation — เก็บ Decision Log

ทุกครั้งที่ ตัดสินใจไม่ทำอะไร — เราจดเหตุผล

"ไม่ใส่ multi-currency เพราะลูกค้ามีบริษัทเดียวในไทย — เมื่อมี subsidiary ต่างประเทศจะกลับมาทบทวน"

document นี้ทำให้:

• 6 เดือนข้างหน้า ทีมไม่งง ว่า "ทำไมไม่ใส่"
• เมื่อ requirement เปลี่ยน → กลับมาดู context ได้
• ลูกค้ามั่นใจว่าทีมคิด ไม่ใช่ลืม

---

กรณีศึกษา — เลือก "ไม่ทำ" ดีกว่า "เผื่อทำ"

(เราเปลี่ยนรายละเอียดและตัวเลขเล็กน้อยเพื่อปกป้องลูกค้า)

โปรเจกต์ ERP สำหรับธุรกิจ trading นำเข้าส่งออก scope เริ่มต้น 6 เดือน

ใน requirement document มีคำว่า "ในอนาคตอาจรองรับ" 14 ครั้ง

• ในอนาคตอาจรองรับหลาย currency
• ในอนาคตอาจมี subsidiary
• ในอนาคตอาจ integrate กับระบบบัญชี A, B, C
• ในอนาคตอาจรองรับการขายผ่าน marketplace
• ...

ทีมเก่าที่เคยเสนอ proposal → คิดว่า "ต้องเผื่อทุกอย่าง" → quote 14 เดือน, ราคา 3X

เราเสนอ approach ต่างกัน:

• phase 1 (4 เดือน) — ระบบที่ใช้งานวันนี้ได้จริง: single currency, single entity, integrate 1 ระบบบัญชีหลัก
• phase 2 (โต ตามความต้องการ) — extend เมื่อถึงเวลา based on actual data

ลูกค้าเลือก phase 1 → ภายใน 4 เดือน ระบบใช้งานจริง → กระแสเงินสดเข้า payback ได้เร็ว

หลังจากใช้งาน 8 เดือน:

• 3 ข้อจาก 14 ของ "ในอนาคตอาจรองรับ" → ต้องการจริง → ค่อยทำ phase 2
• 11 ข้อ → ไม่ได้ใช้, ไม่ต้องการ, หรือเปลี่ยน requirement ไปแล้ว

ถ้าเราทำตามที่ทีมเก่าเสนอ → 11 จาก 14 ฟีเจอร์ = wasted work = ลูกค้าจ่ายแพงกว่า 3X เพื่อสิ่งที่ไม่ได้ใช้

นี่คือ YAGNI ในธุรกิจจริง

---

YAGNI สำหรับ AI/LLM Era — สำคัญกว่าเดิม

ปี 2026 ทีมเขียน code ด้วย AI tool (Claude Code, Cursor, Codex) เร็วขึ้น 3-5 เท่า

แต่ "เร็ว" ไม่ได้แปลว่าควรเขียนเยอะ

AI ชอบสร้าง abstraction "เผื่อ" — เพราะ training data ของ AI = code ที่เขียนโดย engineer ทั่วโลกที่ over-engineer

ถ้าทีมไม่มี YAGNI discipline + ปล่อย AI เขียน → ได้ code base ที่ใหญ่ขึ้น 3-5 เท่า ในเวลาเท่าเดิม

cost of carry = mushroom

นี่คือเหตุผลที่ YAGNI ในยุค AI สำคัญกว่าเดิม — เพราะ economics ของการ "เผื่อเขียน" แทบจะ 0 (AI ทำให้) แต่ economics ของการ "เผื่อ maintain" สูงขึ้น (เพราะ code เยอะขึ้น)

ทีมที่ใช้ AI เก่ง = ทีมที่ใช้ AI เพื่อ เขียนสิ่งที่จำเป็น clean ที่สุด ไม่ใช่ทีมที่ใช้ AI เพื่อ เขียนเยอะที่สุด

---

สรุป — YAGNI เป็น Discipline ไม่ใช่ Tagline

YAGNI ไม่ใช่ excuse ที่จะขี้เกียจ ไม่ใช่ permission ที่จะไม่คิดล่วงหน้า

YAGNI = discipline ที่บังคับให้คุณ:

• พิสูจน์ความจำเป็นก่อนเขียน
• ตัด complexity ที่ไม่ pay off
• เก็บ codebase ให้เล็ก clean ง่าย maintain
• ส่งคุณค่าทุกบาทที่ลูกค้าจ่าย (หรือเวลาที่คุณลงทุน)

4 ต้นทุนของ Fowler:

• Build — เขียนไปแล้วไม่ได้ใช้
• Delay — เสียโอกาส ship ของจำเป็น
• Carry — แบกภาระทุกวัน
• Repair — ซ่อมตอนเวลามาถึง เพราะที่เผื่อไม่ตรง

หลีกเลี่ยงทั้ง 4 ได้ด้วยกฎเดียว — "You Aren't Gonna Need It"

ในยุค AI ที่ทุกคนเขียน code ได้เร็วขึ้น YAGNI สำคัญที่สุด — เพราะคนที่ "เผื่อเขียน" ได้ฟรี ก็จะเป็นคนที่ "เผื่อ maintain" แพงที่สุด

ที่ Enersys เราเลือก discipline นี้ทุกโปรเจกต์ — เพราะลูกค้าจ่ายค่าผลลัพธ์ ไม่ใช่ค่า abstraction ที่ดูเท่

---

แหล่งข้อมูล

• Martin Fowler — Yagni (bliki, May 2015) — ต้นทาง 4 cost categories ที่อ้างถึงในบทความ
• Wikipedia — You aren't gonna need it — ที่มา, Ron Jeffries quote, ความเชื่อมโยงกับ XP
• Ron Jeffries — What is Extreme Programming — perspective จาก co-founder XP โดยตรง
• Kent Beck — Extreme Programming Explained (2nd ed., Addison-Wesley) — หนังสือต้นทางของ XP และที่มาของ DTSTTCPW