Setiap tahun muncul daftar “stack terbaik”. Setiap tahun daftar itu berbeda. Dan setiap tahun sebagian pembacanya mengganti perkakas yang sebenarnya masih bekerja dengan baik.
Tulisan ini bukan daftar. Daftar punya masa kedaluwarsa yang pendek, dan yang menentukan proyek Anda berhasil atau tidak jarang ada di dalamnya.
Yang lebih berguna adalah kerangka untuk memutuskan sendiri — karena keputusan yang tepat untuk tim tiga orang berbeda dari yang tepat untuk tim tiga puluh, dan tidak ada daftar yang tahu Anda yang mana.
Sebelum membandingkan apa pun, jawab ini: berapa lama proyek ini harus hidup, dan siapa yang akan merawatnya?
Prototipe yang akan dibuang dalam tiga bulan boleh dibangun dengan apa pun yang membuat Anda cepat. Sistem yang harus jalan lima tahun dan akan diwariskan ke orang yang belum direkrut punya batasan yang sama sekali berbeda.
Kebanyakan penyesalan soal stack berasal dari menerapkan aturan kelompok pertama pada proyek kelompok kedua.
Perbandingan perkakas hampir selalu berpusat pada performa. Padahal performa jarang jadi alasan sebuah proyek gagal.
Yang lebih sering menghabiskan waktu: berapa lama orang baru bisa produktif, seberapa mudah mencari jawaban saat ada yang rusak jam sebelas malam, dan seberapa sering Anda dipaksa memperbarui karena ada perubahan yang merusak kompatibilitas.
Ketiganya punya penanda yang bisa Anda periksa sebelum memutuskan.
Kedalaman dokumentasi. Bukan apakah ada dokumentasi, tapi apakah ada bagian yang membahas kasus tidak lazim dan kegagalan. Dokumentasi yang hanya berisi “memulai” adalah tanda perkakas yang belum dipakai orang untuk hal serius.
Umur dan ritme rilis. Proyek yang merilis versi mayor setiap enam bulan menuntut anggaran pemeliharaan yang jarang diperhitungkan siapa pun di awal.
Jumlah jawaban di luar dokumentasi resmi. Saat produksi bermasalah, Anda tidak akan membaca dokumentasi — Anda akan mencari pesan galat itu persis. Perkakas populer menang di sini bukan karena lebih baik secara teknis, tapi karena orang lain sudah pernah mengalami masalah Anda.
Ini aturan paling praktis yang saya tahu: dalam satu proyek, pilih maksimal satu teknologi yang belum pernah dipakai tim Anda.
Alasannya bukan konservatisme. Alasannya kemampuan mendiagnosis.
Kalau ada masalah dan hanya satu bagian yang asing bagi Anda, Anda tahu di mana harus mencari. Kalau tiga bagian asing sekaligus, setiap kesalahan berubah jadi penyelidikan panjang untuk menentukan lapisan mana yang bersalah — dan waktu itu tidak pernah masuk ke perkiraan proyek.
Belajar hal baru itu penting. Tapi belajar tiga hal baru sambil mengejar tenggat adalah cara memastikan Anda tidak benar-benar belajar satu pun.
Beberapa pola berulang setiap tahun dengan nama berbeda, dan hampir selalu bisa dilewati untuk sebagian besar proyek.
Memecah jadi banyak layanan sejak awal. Biaya operasionalnya nyata dan langsung; manfaatnya baru muncul pada skala yang mungkin tidak akan pernah Anda capai. Mulailah dari satu aplikasi yang tertata rapi. Memecahnya nanti lebih mudah daripada yang dikhawatirkan orang.
Abstraksi untuk kebutuhan yang belum ada. Lapisan yang dibuat “supaya nanti mudah ganti basis data” hampir tidak pernah dipakai untuk mengganti basis data. Yang pasti terjadi adalah setiap orang harus membaca dua lapisan alih-alih satu, selamanya.
Mengejar versi mayor terbaru pada hari rilis. Tunggu satu atau dua rilis tambalan. Biarkan orang lain menemukan masalahnya.
Di sisi lain, ada hal-hal yang jarang disesali siapa pun.
Pemeriksaan tipe, dalam bahasa apa pun yang Anda pakai. Ia membayar dirinya sendiri pada saat orang lain membaca kode Anda — termasuk Anda enam bulan kemudian.
Satu perintah untuk menyiapkan lingkungan pengembangan. Kalau orang baru butuh setengah hari dan bertanya di tiga tempat sebelum bisa menjalankan proyek, Anda membayar biaya itu berulang kali.
Pencatatan dan penelusuran yang dipasang sejak awal, bukan setelah insiden pertama. Menambahkannya saat sistem sudah berjalan selalu lebih mahal, dan biasanya dilakukan dalam keadaan panik.
Basis data yang membosankan. PostgreSQL menyelesaikan lebih banyak masalah daripada yang orang kira, termasuk beberapa yang biasanya jadi alasan menambah sistem terpisah.
Kalau Anda sedang menimbang dua pilihan, jangan bandingkan lewat artikel. Bangun potongan paling menyeramkan dari proyek Anda di keduanya.
Bukan aplikasi contoh. Bagian yang Anda tahu akan sulit — otentikasi yang rumit, laporan yang berat, integrasi dengan sistem lama yang aneh.
Dua hari untuk masing-masing. Setelah itu Anda akan tahu lebih banyak daripada yang bisa diberikan seratus perbandingan di internet, dan yang Anda ketahui itu spesifik untuk masalah Anda sendiri.
Stack yang dipilih dengan sadar dan dipahami tim lebih baik daripada stack yang “lebih modern” tapi setengah dimengerti.
Sebagian besar proyek tidak gagal karena salah memilih kerangka kerja. Mereka gagal karena tidak ada yang memahami keseluruhannya ketika bagian yang penting rusak.
Tulisan ini sengaja tidak menyebut versi atau membandingkan produk tertentu. Lanskap perkakas berubah lebih cepat daripada umur sebuah artikel, sementara kriteria memilihnya relatif tetap.
