Foto oleh redcharlie di Unsplash
Setelah Bertahun-tahun Bekerja di Tech, Saya Lelah Berdebat Tentang Framework
M. Zakyuddin Munziri
@zakiego
Ditulis asli dalam English.
Saya lelah dengan pertengkaran itu.
Setelah bertahun-tahun bekerja di tech, saya melihat argumen yang sama berulang. Orang memperlakukan framework seperti identitas. Tweet menjadi perang. Rapat menjadi debat tentang selera. Sementara itu produk dan pengguna menunggu.
Ya, beberapa framework secara objektif lebih buruk. Tapi sebagian besar framework populer sudah cukup dekat kualitasnya. Perbedaan nyata itu penting dalam konteks, bukan sebagai pemenang mutlak. Satu framework mungkin bootstrap lebih cepat. Yang lain mungkin menawarkan ergonomi yang sedikit lebih baik untuk pola tertentu. Itu adalah tradeoff nyata, tapi jarang menjadi penentu sukses atau gagalnya proyek.
Kenapa pertengkaran terjadi
Debat framework menjadi bising karena dua alasan utama. Pertama, alat menjadi identitas. Memilih framework menandakan pengalaman, selera, atau kepemilikan pada suatu kelompok. Kedua, hype memperbesar perbedaan kecil. Library baru berjanji menyelesaikan perasaan yang sudah dimiliki orang. Library lama disalahkan atas masalah yang sebenarnya adalah masalah proses.
Ketika lapisan emosional itu muncul, percakapan meninggalkan tradeoff dan memasuki ranah agama. Itu membuang waktu dan moral.
Sebagian besar framework ada di angka 11 sampai 14 dari skala 1 sampai 20
Dalam praktiknya, framework berkutat pada masalah inti yang sama: routing, state management, rendering, lifecycle, dan data flow. Detail implementasi berbeda. API berbeda. Tapi setelah bulan-bulan pertama proyek, faktor dominan bukanlah nama frameworknya.
Apa yang sebenarnya menggerakkan hasil adalah sistem manusia di sekitar framework itu: bagaimana tim mereview kode, siapa yang memiliki perilaku runtime, bagaimana testing dan observability distrukturkan, dan bagaimana perubahan dikirim dan di-rollback. Hal-hal inilah yang menentukan kecepatan dan stabilitas, bukan apakah library A menggunakan hooks atau class components atau API router yang berbeda.
Preferensi itu boleh. Mandat itu tidak
Saya punya favorit. Saya akan menjelaskan kenapa saya menyukainya. Saya akan menunjukkan pola yang saya suka dan antipattern yang saya hindari.
Tapi preferensi tidak boleh menjadi mandat tanpa alasan. Tim yang baik memilih default dan mendokumentasikan alasannya. Mereka membuat keputusan itu bisa dibalik (reversible). Mereka menuliskan tradeoff sehingga pendatang baru mengerti biayanya. Mereka mengizinkan pengecualian dengan jalur persetujuan singkat ketika kasusnya kuat.
Itu menjaga percakapan tetap praktis. Itu memindahkan tim dari debat kesukuan menjadi tradeoff engineering.
Framework bisa dipelajari dan ditambal
Framework adalah alat, bukan doktrin. Jika framework kekurangan fitur yang Anda butuhkan, Anda bisa melakukan satu dari tiga hal realistis. Pertama, terima tradeoff dan hindari pola yang memicu kelemahan itu. Kedua, tambahkan adapter kecil atau wrapper yang menyediakan kontrak yang Anda inginkan. Ketiga, dokumentasikan pola sehingga tim menggunakan pendekatan yang konsisten.
Ini adalah langkah engineering. Ini membosankan. Ini berhasil. Ini berskala jauh lebih baik daripada meyakinkan seluruh perusahaan untuk berganti stack demi kemenangan ergonomi kecil.
Bagaimana saya menyarankan tim memutuskan dengan cepat dan tanpa drama
Buat proses keputusan menjadi eksplisit. Jawab tiga pertanyaan praktis dan dokumentasikan.
- Masalah apa yang sedang kita selesaikan dan kenapa framework ini membantu kita menyelesaikannya.
- Apa biaya terukur yang kita terima jika kita memilih framework ini.
- Bagaimana kita bisa membalikkan atau memitigasi pilihan ini jika menyebabkan masalah.
Jika jawaban-jawaban itu jelas, pilihan framework biasanya baik-baik saja. Jika Anda tidak bisa menjawabnya, debat itu hanya kebisingan.
Kapan argumen itu layak dilakukan
Ada kasus nyata yang pantas diperjuangkan. Kendala performa ekstrem, persyaratan kepatuhan (compliance) yang ketat, atau hutang legacy yang masif adalah alasan sah untuk eskalasi. Dalam kasus-kasus itu, berdebatlah dengan data dan metrik yang jelas. Tunjukkan perbedaan dalam biaya pemeliharaan, overhead operasional, atau latensi di bawah beban nyata. Tapi situasi itu kurang umum daripada yang terlihat di perang Twitter.
Penutup
Saya masih peduli tentang alat yang bagus. Saya masih peduli tentang tradeoff. Saya tidak acuh tak acuh. Saya hanya lelah mengubah selera teknis menjadi gesekan tim.
Pilihan framework adalah tentang konteks, bukan karakter. Ajarkan tradeoff, dokumentasikan pola, tambal celahnya. Lalu berhenti berdebat dan kembali membangun hal-hal yang berguna.
Jika debat berlanjut, cobalah ini dengan tim Anda: pilih default, tulis satu paragraf menjelaskan alasannya, tetapkan jendela review pendek, dan lanjutkan. Anda akan menyelesaikan lebih banyak hal.
