Apa itu Prinsip YAGNI? #

YAGNI (You Aren’t Gonna Need It) adalah prinsip dalam software engineering yang menegaskan bahwa jangan mengimplementasikan sesuatu sebelum benar-benar dibutuhkan. Prinsip ini berasal dari praktik Extreme Programming (XP) dan sering dianggap sebagai penyeimbang dari over-engineering.

Intinya sederhana:

Jika sebuah fitur belum dibutuhkan hari ini, jangan dibuat sekarang.

YAGNI bukan berarti anti-perencanaan, melainkan anti asumsi berlebihan tentang masa depan.

Masalah yang Ingin Dicegah oleh YAGNI #

Tanpa YAGNI, engineer sering terjebak pada:

1. Over-engineering – sistem terlalu kompleks untuk kebutuhan saat ini
2. Dead code – fitur dibuat tapi tidak pernah dipakai
3. Biaya maintenance tinggi – lebih banyak kode = lebih banyak bug
4. Waktu delivery melambat – fokus ke fitur imajiner, bukan kebutuhan nyata

YAGNI membantu tim untuk fokus pada value yang nyata dan terukur.

YAGNI vs “Future Proof Design” #

Ini miskonsepsi yang sering terjadi.

👉 YAGNI tidak melarang extensibility, tapi melarang implementasi fitur spekulatif.

Contoh sehat:

• ✅ Interface kecil dan jelas
• ❌ Implementasi multi-provider padahal baru ada 1 provider

Contoh Kasus Tanpa YAGNI (Anti-Pattern) #

Kasus: Service Pembayaran #

Engineer berpikir:

“Nanti pasti akan ada banyak payment provider. Kita siapkan dari awal.”

Implementasi Tanpa YAGNI #

// Terlalu kompleks untuk kebutuhan saat ini

type PaymentProvider interface {
    Pay(amount int64) error
    Refund(transactionID string) error
    Validate() error
}

type MidtransProvider struct {}
func (m *MidtransProvider) Pay(amount int64) error { return nil }
func (m *MidtransProvider) Refund(id string) error { return nil }
func (m *MidtransProvider) Validate() error { return nil }

// Factory + registry + config yang belum dibutuhkan

Padahal:

• Baru ada 1 provider
• Fitur refund bahkan belum ada requirement

❗ Ini melanggar YAGNI.

Implementasi dengan YAGNI (Lebih Sederhana) #

Versi Sesuai Kebutuhan Saat Ini #

// Fokus hanya pada kebutuhan nyata

type PaymentService struct {}

func (p *PaymentService) Pay(amount int64) error {
    // call Midtrans API
    return nil
}

Keuntungan:

• Kode lebih pendek
• Lebih mudah di-test
• Lebih cepat dikembangkan

Jika nanti ada provider lain? 👉 Refactor saat dibutuhkan, bukan sekarang.

Refactor Saat Dibutuhkan (YAGNI yang Sehat) #

Ketika requirement berubah:

• Ada 2+ payment provider
• Switching provider dibutuhkan

Barulah lakukan refactor:

type PaymentProvider interface {
    Pay(amount int64) error
}

type MidtransProvider struct {}
func (m *MidtransProvider) Pay(amount int64) error { return nil }

type XenditProvider struct {}
func (x *XenditProvider) Pay(amount int64) error { return nil }

💡 Refactor lebih murah daripada memelihara fitur spekulatif bertahun-tahun.

Contoh YAGNI dalam API Design (Golang) #

Anti YAGNI #

type UserFilter struct {
    Name      *string
    Age       *int
    Gender    *string
    City      *string
    Country   *string
    IsActive  *bool
}

Padahal endpoint hanya butuh filter name.

Dengan YAGNI #

type UserFilter struct {
    Name string
}

Tambahkan field saat benar-benar dibutuhkan.

YAGNI dalam Arsitektur Sistem #

Contoh Melanggar YAGNI #

• Microservices untuk aplikasi dengan 5 endpoint
• Event-driven + Kafka untuk traffic kecil
• CQRS + Event Sourcing tanpa kebutuhan audit

Contoh Mengikuti YAGNI #

• Monolith modular
• Simple REST API
• Database tunggal

➡️ Skala naikkan kompleksitas, bukan turunkan.

Kapan YAGNI Tidak Boleh Diterapkan Secara Ekstrem? #

YAGNI bukan alasan untuk:

• ❌ Mengabaikan security
• ❌ Mengabaikan error handling
• ❌ Mengabaikan logging & observability
• ❌ Mengabaikan testability

Contoh:

• Validasi input selalu perlu
• Timeout & retry bukan fitur spekulatif

Hubungan YAGNI dengan Prinsip Lain #

• KISS → YAGNI membantu menjaga kesederhanaan
• DRY → Jangan abstraksi sebelum ada duplikasi nyata
• SOLID → Terapkan seperlunya, bukan dogmatis

Abstraction should be pulled by need, not pushed by fear.

Checklist Praktis YAGNI untuk Engineer #

Sebelum menambahkan fitur, tanyakan:

• Apakah ini dipakai hari ini?
• Apakah ada requirement tertulis?
• Apakah ada use case nyata?
• Apakah cost maintenance sebanding?

Jika jawabannya “belum” → Tunda.

Kesimpulan #

Prinsip YAGNI mengajarkan bahwa:

• Kompleksitas adalah utang
• Fitur spekulatif jarang terbayar
• Refactor itu normal dan sehat

Dengan YAGNI, engineer Golang bisa membangun sistem yang:

• Lebih simpel
• Lebih mudah dirawat
• Lebih cepat beradaptasi

Bangun untuk kebutuhan sekarang, siapkan pikiran untuk perubahan besok.