Apakah "clean code" selalu sepadan dengan waktu yang dikeluarkan, atau apakah "cukup baik" kadang dapat diterima?

Question

Accepted Answer

**Tergantung pada umur kode dan dampak potensialnya.** Clean code memberikan hasil yang sangat baik untuk kode yang hidup dan berubah; "cukup baik" adalah keputusan yang tepat untuk kode sekali pakai, prototipe, atau kode yang jarang diubah. Keahliannya adalah menyesuaikan investasi Anda dengan situasi — menghindari baik kecerobohan maupun over-engineering.

## Prinsipnya: sesuaikan upaya dengan umur kode

Kualitas kode adalah sebuah **investasi**, dan seperti investasi apa pun, hasilnya bergantung pada waktu dan eksposur. Ada dua pertanyaan yang perlu diajukan:

- **Berapa lama kode ini akan bertahan?** Kode yang dibaca dan diubah selama bertahun-tahun membutuhkan kejelasan; script satu kali tidak perlu.
- **Apa jangkauan dampaknya?** Modul inti yang disentuh oleh banyak orang dan bergantung pada jalur kritis memerlukan perhatian; sudut terpencil yang jarang berubah tidak perlu.

## Kapan clean code jelas unggul

- Kode yang **sering berubah** — kejelasan terbayar setiap kali seseorang membaca atau mengeditnya.
- Kode yang **dibagikan, berpusat, atau berumur panjang** — biaya kebingungan berlipat ganda di berbagai orang dan waktu.
- Apa pun yang memiliki **bug mahal** — pembayaran, autentikasi, integritas data.

## Kapan "cukup baik" adalah pilihan yang tepat

- **Kode sekali pakai** — spike, eksperimen, migrasi satu kali, script yang akan Anda hapus besok.
- **Prototipe** yang dirancang untuk memvalidasi ide, bukan untuk bertahan lama.
- **Kode yang jarang disentuh, berisiko rendah** di mana pemolesan memberikan sedikit manfaat.

## Dua mode kegagalan

| Kegagalan | Terlihat seperti | Biaya |
|---|---|---|
| **Kecerobohan** | mengirim kekacauan ke dalam kode yang akan bertahan | perubahan masa depan lambat, bug, erosi |
| **Over-engineering** | terlalu merekayasa kode yang tidak akan penting | waktu terbuang, abstraksi prematur |

Keduanya adalah pemborosan nyata. "Cukup baik" adalah pilihan yang *disengaja, kontekstual* — bukan alasan untuk ceroboh, dan bukan lisensi untuk memoles selamanya.

## Mengapa ini penting

Pertanyaan ini membedakan engineer yang menerapkan kualitas **secara dogmatis** dari mereka yang menerapkannya **secara ekonomis**. Memperlakukan clean code sebagai agama membuang-buang upaya pada kode sekali pakai; memperlakukannya sebagai opsional merusak sistem yang Anda andalkan. Penilaian senior adalah mengetahui *jenis kode apa yang Anda pegang* dan berinvestasi sesuai dengan itu — dan mampu menjelaskan pertukaran itu adalah tepat jenis pemikiran pragmatis yang ingin dilihat tim.

Kegagalan	Terlihat seperti	Biaya
Kecerobohan	mengirim kekacauan ke dalam kode yang akan bertahan	perubahan masa depan lambat, bug, erosi
Over-engineering	terlalu merekayasa kode yang tidak akan penting	waktu terbuang, abstraksi prematur