Membosankan itu fitur di perangkat lunak institusi

Perangkat lunak institusi punya syarat sukses yang berbeda dari proyek sampingan. Ia sukses kalau masih berjalan dua tahun kemudian, di hari Selasa, saat orang yang membangunnya sedang cuti.

Syarat itu memberi imbalan pada pilihan yang membosankan:

• Framework dengan sejarah rilis panjang.
• Database relasional, bukan mesin penyimpanan baru.
• Satu jalur deployment, bukan tiga.
• Konfigurasi di satu file, bukan tersebar di UI.
• Log yang menjawab “apa yang terjadi jam 09.14” tanpa debugger.

Tidak ada yang menarik untuk dibicarakan. Semuanya mengurangi jumlah cara sistem bisa gagal saat tidak ada yang mengawasi.

Kebaruan punya biaya operasi

Setiap alat baru menambah kategori pengetahuan yang harus dipegang seseorang:

• Bagaimana ia di-deploy?
• Bagaimana ia gagal?
• Ke mana log-nya pergi?
• Versi mana yang sedang berjalan?
• Apa yang rusak saat ia di-upgrade?

Untuk tim satu atau dua orang yang merawat belasan situs kecil, biaya itulah kendalanya. Menambah alat baru tidak gratis hanya karena memasangnya gratis.

Karena itu juga saya curiga pada perubahan arsitektur yang dibenarkan terutama oleh preferensi developer. Rewrite adalah taruhan bahwa sistem baru lebih murah dioperasikan selama sisa umur proyek. Taruhan itu kadang benar. Jarang sejelas rasanya di minggu pertama.

Membosankan bukan berarti sembarangan

Kesalahan sebaliknya adalah memperlakukan “membosankan” sebagai alasan untuk struktur yang buruk. Stack membosankan tanpa disiplin skema, tanpa validasi, dan tanpa catatan deployment hanyalah kekacauan lama.

Yang saya kejar:

• Batas eksplisit. Di mana input divalidasi, di mana izin diperiksa, di mana data ditulis.
• Satu sumber kebenaran per fakta. Peran, konfigurasi, dan konten tidak boleh didefinisikan dua kali.
• Default yang bisa dioperasikan. Backup, perpanjangan TLS, dan rotasi log adalah bagian dari build, bukan tugas nanti.
• Dokumentasi yang menjawab pertanyaan berikutnya. Bukan novel — satu halaman pendek tentang cara deploy, restore, dan rollback.

Tes yang saya pakai

Sebelum menambah sesuatu, saya bertanya dua hal:

1. Ini menghilangkan mode kegagalan, atau menambah satu?
2. Kalau saya tidak bisa dihubungi sebulan, apakah orang lain bisa mengoperasikannya dari yang tertulis?

Kalau jawabannya “menambah satu” dan “tidak”, kebaruan itu butuh alasan yang lebih baik daripada rasa tertarik.

Tes itu bukan argumen melawan belajar. Saya sedang mempelajari Go dan infrastruktur berbasis container. Tapi belajar terjadi di lab dulu. Produksi adalah tempat versi membosankan dipasang.