Ada satu kebiasaan yang semakin saya sadari setelah mengerjakan beberapa project: jangan terlalu cepat membuka code editor.
Ketika mendapatkan sebuah kebutuhan baru, godaan pertama biasanya adalah memilih framework, membuat struktur folder, lalu mulai mengerjakan halaman pertama. Saya pernah berpikir seperti itu. Namun semakin kompleks project yang dikerjakan, semakin jelas bahwa keputusan yang dibuat sebelum coding justru sering menentukan apakah aplikasi akan mudah dikembangkan atau menjadi masalah baru.
Bagi saya, membangun aplikasi web dimulai dari memahami apa yang ingin diselesaikan, bukan teknologi apa yang ingin digunakan.
Apa yang Perlu Dipersiapkan Sebelum Membangun Aplikasi Web?
Saya biasanya memulai dari enam hal: requirement, user, data, architecture, feature, dan technical constraints.
Requirement bukan sekadar daftar permintaan seperti “buatkan modul stok”. Saya perlu memahami proses sebenarnya: barang masuk dari mana, siapa yang mencatat, kapan stok berubah, bagaimana barang keluar, dan informasi apa yang dibutuhkan setelah transaksi terjadi.
Kemudian ada user. Orang yang memasukkan data belum tentu orang yang mengambil keputusan dari data tersebut. Karena itu, kebutuhan admin gudang, operator, supervisor, atau pemilik bisnis bisa berbeda meskipun mereka menggunakan aplikasi yang sama.
Setelah itu saya memikirkan data. Data bukan hanya sesuatu yang disimpan di database. Ia harus menggambarkan proses bisnis. Jika stok berubah, saya perlu tahu perubahan itu terjadi karena apa, kapan, siapa yang melakukannya, dan bagaimana sistem mempertanggungjawabkan perubahan tersebut.
Baru kemudian saya memikirkan architecture dan feature. Fitur harus mengikuti kebutuhan dan alur data, bukan sebaliknya.
Hal terakhir adalah technical constraints: kemampuan server, performa, keamanan, integrasi, waktu pengerjaan, biaya, sampai batasan teknologi yang digunakan.
Pendekatan ini juga sejalan dengan pengalaman saya ketika menerjemahkan kebutuhan bisnis menjadi fitur. Saya tidak ingin fitur berdiri sendiri; setiap fitur harus mempunyai alasan dan hubungan dengan proses lainnya. Saya membahas pendekatan tersebut lebih jauh dalam cara mengubah kebutuhan bisnis menjadi fitur dalam aplikasi web.
Bagaimana Saya Menentukan Requirement, User, Data, dan Fitur pada Aplikasi?
Cara berpikir tersebut saya praktikkan ketika mengembangkan Inventory Management System.
Saya tidak melihatnya hanya sebagai aplikasi untuk menampilkan jumlah stok.
Di balik kebutuhan inventory, ada beberapa pertanyaan yang lebih penting: apa yang sebenarnya sedang dikontrol, siapa yang bertanggung jawab, dan dari mana angka stok tersebut berasal?
Dari sana, kebutuhan mulai terlihat sebagai sebuah sistem. Data material harus memiliki konteks. Data mesin tidak bisa dipisahkan begitu saja dari aktivitas operasional. Order dan penagihan memiliki hubungan dengan customer, sementara informasi harga dapat berbeda berdasarkan customer tertentu.
Artinya, satu fitur hampir selalu memengaruhi fitur lainnya.
Inilah alasan saya tidak suka langsung membuat UI berdasarkan daftar menu. Menu seperti Stok Material, Data Mesin, atau Penagihan memang terlihat sederhana, tetapi di belakangnya terdapat relasi data, permission, business rules, dan kemungkinan perubahan status.
Saya kemudian memikirkan architecture berdasarkan kebutuhan tersebut. Bagaimana data mengalir? Apa yang menjadi sumber kebenaran? Apa yang harus divalidasi di backend? Bagaimana frontend mendapatkan data? Dan apa yang terjadi jika jumlah data semakin besar?
Pertanyaan-pertanyaan tersebut mungkin tidak terlihat ketika pengguna membuka dashboard. Tetapi justru di situlah sebagian besar pekerjaan engineering terjadi.
Mengapa Keputusan Sebelum Coding Menentukan Kualitas Aplikasi Web?
Bagi saya, dokumentasi sebelum implementasi bukan birokrasi tambahan. Ia adalah cara untuk mengurangi keputusan yang harus ditebak ketika aplikasi sudah terlanjur dibangun.
Ini menjadi semakin relevan di era AI. Developer sekarang dapat menghasilkan kode jauh lebih cepat, tetapi kecepatan menghasilkan kode tidak otomatis membuat keputusan teknis menjadi benar. Stack Overflow mencatat bahwa 66% developer frustrasi dengan solusi AI yang “hampir benar”, sementara 46% tidak mempercayai akurasi output AI.
Karena itu, saya justru melihat kemampuan menentukan apa yang harus dibangun dan mengapa sebagai bagian yang semakin penting dari pekerjaan developer.
Hal yang sama berlaku untuk performa. Aplikasi yang secara fungsional benar belum tentu siap menghadapi penggunaan nyata. Setelah sistem dibangun, saya perlu mengetahui bagaimana aplikasi berperilaku ketika request bertambah, bukan sekadar memastikan halaman dapat dibuka. Karena itu saya juga menerapkan pendekatan pengujian performa dan membahasnya melalui load testing dan alasan website membutuhkannya.
Pada akhirnya, enam hal tadi bukanlah urutan yang selalu kaku.
Requirement memengaruhi feature. User memengaruhi permission. Data memengaruhi architecture. Architecture dibatasi technical constraints. Feature kemudian diuji terhadap kebutuhan awal.
Semuanya saling berhubungan.
Itulah cara saya sekarang melihat proses membangun aplikasi web. Bukan dimulai dari pertanyaan “pakai teknologi apa?”, tetapi dari “masalah apa yang sebenarnya ingin diselesaikan?”
Karena ketika pertanyaan pertama sudah tepat, keputusan teknis setelahnya biasanya menjadi jauh lebih masuk akal.
Dan bagi saya, itulah bagian menarik dari pekerjaan developer: bukan hanya membuat sesuatu bekerja, tetapi memahami alasan mengapa sesuatu itu perlu dibangun.
Untuk melihat bagaimana saya berkembang dari proses tersebut dan teknologi yang saya gunakan dalam pekerjaan, Anda juga dapat melihat profil dan perjalanan saya ferdy salsabilla sebagai developer.