Developer Sudah Pergi, Dokumentasi Tidak Ada: Cara Membaca Ulang Sistem dari Source Code

Aplikasinya Jalan, Penjelasannya Hilang

Banyak organisasi baru sadar masalah ini ketika sudah terlambat. Sebuah aplikasi sudah bertahun-tahun dipakai: mahasiswa mengajukan berkas, staf menyetujui permohonan, laporan keluar setiap akhir semester. Lalu developer yang membuatnya pindah kerja, folder berisi spesifikasi terhapus saat bersih-bersih penyimpanan, atau satu-satunya catatan ada di laptop yang sudah diganti. Semua tetap terlihat baik, sampai suatu hari aplikasinya perlu diubah.

Saat itulah muncul pertanyaan yang tidak bisa dijawab siapa pun. Fitur apa saja yang sebenarnya ada? Siapa boleh melakukan apa? Data disimpan di mana? Apa yang terjadi kalau satu tabel diubah?

Sekarang ada versi baru dari cerita yang sama. Pemilik usaha yang paham bisnisnya, tetapi tidak berlatar belakang pemrograman, membuat aplikasi pertamanya dengan bantuan AI. Aplikasinya berjalan dan bisa dipakai. Namun tidak ada yang menuliskan kebutuhan, tidak ada yang mencatat keputusan desain, dan "developer"-nya hanyalah sesi percakapan yang tidak menyimpan catatan. Ketika aplikasi itu ingin dikembangkan, satu-satunya pegangan adalah kodenya.

Kabar baiknya, kode itu adalah catatan paling lengkap yang Anda miliki. Setiap halaman yang bisa dibuka pengguna, setiap tabel yang diisi aplikasi, dan setiap aturan yang mengizinkan atau menolak sebuah aksi tertulis di sana. Kode memang tidak ditulis untuk dibaca sebagai dokumentasi, tetapi dengan cara yang terarah, kode bisa diterjemahkan kembali menjadi dokumentasi.

Pengalaman Kami: Proyek yang Datang Hanya Berupa Kode

Panduan ini lahir dari pekerjaan nyata. qadrtech pernah diminta seorang klien untuk melanjutkan pengembangan aplikasi yang mereka bangun sendiri dengan bantuan AI. Klien sangat memahami bisnisnya, tetapi pengembangan software bukan bidang mereka. AI pun mengerjakan persis apa yang diminta: menghasilkan source code yang berjalan, dan tidak lebih dari itu.

Tidak ada dokumen analisis, tidak ada dokumen desain, tidak ada SRS (software requirements specification), dan tidak ada catatan mengapa aplikasinya dibentuk seperti itu. Sebelum merencanakan satu fitur baru pun, kami harus lebih dulu memahami apa yang sudah dikerjakan sistem tersebut. Demi menjaga privasi klien, nama proyek dan bidang usahanya tidak kami sebutkan di sini.

Proses itulah yang kami rangkum di bawah. Dari sana kami juga diingatkan pada satu batasan penting: kode menjelaskan dengan sangat tepat apa yang dilakukan sistem, tetapi hampir tidak pernah menjelaskan mengapa.

Mengapa Aplikasi Buatan AI Perlu Langkah Ini

Asisten coding berbasis AI memungkinkan orang tanpa latar belakang teknis merilis versi pertama aplikasinya. Itu manfaat yang nyata. Yang tidak dilakukan AI dengan sendirinya adalah pekerjaan rekayasa di sekelilingnya: menanyakan siapa penggunanya, mencatat aturan yang harus dipatuhi sistem, atau mendokumentasikan keputusan. Orang yang bukan developer umumnya tidak tahu bahwa hal itu perlu diminta, sehingga dokumen-dokumen tersebut tidak pernah ada.

Hasilnya adalah aplikasi yang seluruh perilakunya hanya tersimpan di dalam kode, sering kali tersusun dari banyak prompt yang terpisah. Menyusun ulang pengetahuannya bukan bentuk kritik terhadap klien maupun alat yang dipakai. Ini sekadar pekerjaan analisis dan desain yang dulu terlewat, dan sekarang dikerjakan belakangan.

Langkah Nol: Pastikan Akses Ada di Tangan Organisasi

Upaya memahami sistem akan sia-sia kalau sistemnya keburu hilang. Sebelum membuka satu file pun, pastikan semua hal yang dibutuhkan aplikasi dikuasai oleh organisasi, bukan oleh perorangan.

• Source code. Cari repositorinya. Kalau tidak ada, salin kode dari server produksi lalu segera simpan dalam version control, meskipun riwayatnya baru dimulai hari ini.
• Server dan hosting. Pastikan siapa pemegang akun hosting, login server, dan panel kontrol. Ganti kata sandi bersama yang masih diketahui developer lama.
• Database. Buat backup lengkap dan simpan di tempat yang terpisah dari server.
• Domain dan DNS. Periksa atas nama siapa domain terdaftar dan kapan masa berlakunya habis. Domain yang kedaluwarsa bisa mematikan aplikasi sama efektifnya dengan server yang rusak.
• Layanan pihak ketiga. Pengiriman email, payment gateway, layanan SMS atau WhatsApp, penyimpanan cloud, dan semua API key di file konfigurasi masuk ke daftar ini.

Catat lokasi dan pemegang masing-masing akses. Daftar itulah halaman pertama dokumentasi baru Anda.

Membaca Sistem Lapis demi Lapis

Membuka file secara acak hanya akan membuat bingung. Lebih efektif membaca sistem berlapis, dari luar ke dalam, dan menuliskan temuan di setiap lapisan. Contoh di bawah memakai Laravel karena itulah framework yang paling sering kami tangani, tetapi framework web lain umumnya punya padanan yang serupa.

1. Kenali Teknologi dan Dependensinya

Mulailah dari file yang mendeskripsikan proyek, bukan file yang mengimplementasikannya.

• composer.json dan package.json memberi tahu framework, versinya, serta pustaka apa saja yang dipakai.
• .env.example, atau .env asli di server, menunjukkan layanan luar yang dibutuhkan aplikasi: database, email, antrean, penyimpanan, dan kunci layanan pihak ketiga.
• Versi framework menggambarkan seberapa tua sistem itu secara praktis, dan jalur upgrade seperti apa yang menanti.

Hasil yang dicatat: versi bahasa dan framework, jenis database, serta daftar layanan luar.

2. Jadikan Daftar Route sebagai Daftar Fitur

Bagi pengguna, aplikasi web adalah kumpulan halaman dan tombol. Semua itu didaftarkan di satu tempat. Di Laravel, daftarnya bisa ditampilkan langsung:

php artisan route:list --except-vendor

Kolom method, URL, controller, dan middleware dari perintah ini adalah inventaris fitur paling lengkap yang bisa Anda dapatkan. Kelompokkan route berdasarkan prefix atau controller, lalu beri setiap kelompok nama yang mudah dipahami, misalnya "pengajuan berkas", "persetujuan pembimbing", atau "laporan".

Hasil yang dicatat: daftar fitur per kelompok, lengkap dengan URL menuju masing-masing fitur.

3. Pahami Bisnis Lewat Struktur Database

Tabel-tabel di database menunjukkan apa saja yang benar-benar dicatat organisasi. Kalau proyek memakai migration, baca berurutan: Anda akan melihat bukan hanya skema saat ini, tetapi juga bagaimana skema itu bertumbuh. Kalau migration tidak ada atau sudah tidak sesuai, ambil skema dari backup database produksi, karena di sanalah kondisi yang sebenarnya.

Perhatikan beberapa hal berikut:

• Foreign key dan pola penamaan seperti student_id atau supervisor_id, yang menunjukkan hubungan antarentitas.
• Kolom status seperti status, state, atau is_approved, yang menandakan adanya alur kerja.
• Soft delete dan timestamp, yang menunjukkan riwayat apa yang disimpan sistem.
• Tabel yang tampaknya tidak terpakai. Jangan dihapus dulu. Tandai sebagai pertanyaan.

Hasil yang dicatat: diagram relasi entitas (ERD). Tidak perlu indah; diagram sederhana berisi tabel utama dan hubungannya sudah cukup untuk menghentikan tebak-tebakan.

4. Petakan Peran dan Hak Akses

Aplikasi bisnis hampir selalu melayani beberapa jenis pengguna dengan tampilan yang berbeda. Temukan di mana aturan itu disimpan. Biasanya ada di:

• middleware pada route, seperti auth, role:admin, atau middleware buatan sendiri;
• policy dan gate (app/Policies, Gate::define);
• tabel roles atau permissions, atau kolom role di tabel users;
• kondisi di dalam view yang menyembunyikan tombol dari pengguna tertentu.

Poin terakhir patut diwaspadai. Tombol yang hanya disembunyikan di tampilan bukanlah pengamanan, dan celah seperti ini sering baru ketahuan ketika peta hak akses disusun ulang.

Hasil yang dicatat: matriks peran, dengan peran sebagai kolom, fitur sebagai baris, dan tanda di setiap kombinasi yang diizinkan.

5. Telusuri Alur Status dan Persetujuan

Pengetahuan paling berharga dalam sistem administrasi biasanya adalah alurnya: permohonan dibuat, diperiksa, disetujui atau dikembalikan, lalu ditutup. Logika ini jarang berada di satu tempat.

Cari bagian kode yang mengubah status:

grep -rn "status" app/ --include=*.php | grep -E "=|update"

Ikuti setiap hasilnya ke controller atau service yang mengubah status tersebut. Catat syarat apa yang membolehkan perubahan itu dan siapa yang boleh memicunya. Dari catatan itu, gambarkan setiap status sebagai kotak dan setiap perpindahan sebagai panah. Diagram ini akan menjawab lebih banyak pertanyaan dukungan dibanding dokumen lain mana pun.

Hasil yang dicatat: satu diagram status untuk setiap alur, lengkap dengan peran yang menjalankan tiap perpindahan.

6. Temukan Proses yang Berjalan Diam-diam

Sebagian perilaku sistem tidak dipicu oleh pengguna sama sekali.

• Tugas terjadwal di app/Console/Kernel.php atau routes/console.php, serta crontab di server.
• Job antrean dan listener yang mengirim email atau memproses file di belakang layar.
• Integrasi dengan sistem lain, misalnya sistem informasi akademik, payment gateway, atau portal pelaporan pemerintah.
• Cara deploy: bagaimana kode sampai ke server, perintah apa yang dijalankan setelah update, dan di mana file unggahan disimpan.

Bagian inilah yang paling mudah rusak tanpa ketahuan setelah ada perubahan, karena tidak ada yang melihatnya berjalan.

Hasil yang dicatat: catatan operasional berisi jadwal otomatis, job latar belakang, integrasi, dan langkah deploy.

7. Manfaatkan Riwayat Git, tetapi Jangan Dipercaya Mentah-mentah

Kalau repositori dengan riwayat masih ada, git log bisa menunjukkan kapan bagian tertentu berubah dan fitur mana yang muncul bersamaan. Pesan commit seperti "fix" atau "update" memang tidak banyak menjelaskan, tetapi tanggal dan file yang berubah bersamaan tetap menjadi petunjuk berguna.

Perlakukan riwayat sebagai bukti yang perlu diperiksa, bukan sebagai dokumentasi. Commit yang mengaku memperbaiki sesuatu belum tentu benar-benar memperbaikinya.

Cocokkan dengan Orang yang Memakainya

Kode menunjukkan apa yang dilakukan sistem. Kode tidak bisa menunjukkan apakah perilaku itu memang disengaja, sekadar ditoleransi, atau bug lama yang sudah biasa diakali pengguna.

Setelah semua lapisan tercatat, tinjau hasilnya bersama orang-orang yang paling dekat dengan sistem: admin yang menerima keluhan, beberapa pengguna rutin, dan pemilik proses di sisi bisnis. Ajukan pertanyaan yang konkret:

• "Di kode, koordinator bisa langsung menyetujui tahap ini. Apakah itu memang dilakukan?"
• "Tabel ini sudah lama tidak bertambah datanya. Apakah fiturnya masih dibutuhkan?"
• "Laporan ini dibuat otomatis setiap malam. Ada yang membacanya?"

Jawaban mereka mengubah deskripsi tentang kode menjadi deskripsi tentang layanan.

Dokumen yang Sebaiknya Anda Miliki di Akhir Proses

Tujuannya bukan manual setebal buku. Beberapa dokumen ringkas yang benar-benar dibuka orang jauh lebih berharga daripada dokumen lengkap yang tidak pernah diperbarui.

1. README yang menjelaskan apa sistem ini, teknologinya, cara menjalankannya secara lokal, dan cara deploy.
2. Daftar akses berisi lokasi kode, server, database, domain, dan akun pihak ketiga, beserta pemegangnya.
3. Daftar fitur per kelompok, disusun dari daftar route.
4. Diagram relasi entitas untuk tabel-tabel utama.
5. Matriks peran yang menunjukkan siapa boleh melakukan apa.
6. Diagram alur untuk setiap proses yang berbasis status.
7. Catatan operasional tentang jadwal otomatis, proses latar belakang, dan integrasi.
8. Daftar pertanyaan terbuka untuk semua hal yang tidak terjawab oleh kode.

Simpan dokumen-dokumen ini di dalam repositori, berdampingan dengan kode, supaya ikut diperbarui ketika kodenya berubah.

Hal yang Tidak Bisa Dikembalikan oleh Kode

Perlu diakui dengan jujur, sebagian pengetahuan memang tidak tersimpan di kode, secermat apa pun kode itu dibaca:

• Alasan di balik keputusan. Kode menunjukkan bahwa persetujuan butuh dua tanda tangan, tetapi tidak menjelaskan apakah itu aturan resmi, permintaan seorang pimpinan, atau solusi darurat atas masalah lama.
• Kesepakatan dengan klien atau pengguna. Ruang lingkup, janji, dan pengecualian yang disepakati dalam rapat tidak meninggalkan jejak di source code.
• Hal yang pernah dicoba lalu ditinggalkan. Alternatif yang ditolak biasanya tidak terlihat sama sekali.
• Dampak di dunia nyata. Kode tidak mencatat apakah sistem menghemat waktu atau bagaimana pendapat penggunanya.

Pada aplikasi buatan AI, ada satu lapisan tambahan: sebagian "keputusan" di dalam kode sebenarnya tidak pernah diputuskan oleh siapa pun. Itu hanyalah hasil yang diberikan AI untuk prompt tertentu. Karena itu, bagian dari proses pemulihan adalah menanyakan kepada pemilik aplikasi perilaku mana yang memang mereka inginkan, dan mana yang selama ini hanya mereka terima apa adanya.

Prinsipnya tetap sama untuk kasus apa pun: catat apa yang diketahui, tandai apa yang masih berupa asumsi, dan serahkan sisanya sebagai pertanyaan terbuka kepada pemilik sistem, alih-alih mengisinya dengan tebakan.

Supaya Tidak Terulang

Memulihkan pengetahuan itu mahal. Mencegahnya jauh lebih murah, asalkan dimulai sejak awal dan dijaga tetap sederhana.

• Simpan dokumentasi di repositori, bukan di drive pribadi atau tumpukan chat.
• Catat keputusan saat keputusan dibuat, cukup beberapa kalimat: konteks, keputusan, dan alasannya.
• Jadikan serah terima sebagai deliverable. Saat proyek selesai atau developer berganti, organisasi harus menerima kode, daftar akses, dan dokumen-dokumen di atas, bukan hanya aplikasi yang berjalan.
• Perbarui dokumen ketika sistem berubah. README yang masih menjelaskan cara deploy tahun lalu justru menyesatkan.

Penutup

Sistem tanpa dokumentasi bukan berarti sistem yang hilang. Selama kode dan datanya masih di tangan Anda, sebagian besar pengetahuan bisa disusun kembali selapis demi selapis, lalu dikonfirmasi kepada orang-orang yang memakainya setiap hari. Hal yang tidak bisa dipulihkan sebaiknya disebut apa adanya, bukan ditebak.

Kalau organisasi Anda bergantung pada aplikasi yang tidak bisa lagi dijelaskan sepenuhnya, baik karena developernya sudah pindah maupun karena aplikasinya dibuat dengan AI dan kini perlu dikembangkan, kami siap membantu memetakannya. Hubungi kami dan ceritakan apa yang dikerjakan aplikasi Anda hari ini; kami akan mulai dari sana.