12.2 Membaca Alur, Bukan Sekadar File

Setelah memahami peta codebase, langkah berikutnya adalah mencari alur utama yang benar-benar terjadi di dalamnya. Banyak engineer junior membuka file secara acak—membaca satu fungsi di sini, satu kelas di sana—lalu merasa sudah memahami sistem. Padahal yang mereka dapat hanyalah potongan puzzle tanpa tahu bagaimana potongan itu tersambung.

Senior engineer melakukan pendekatan yang berbeda. Ia tidak membaca file, ia membaca alur. Ia memulai dari titik masuk yang paling jelas: sebuah request dari pengguna. Mungkin itu endpoint API, mungkin handler event dari queue, mungkin fungsi entry point di batch job. Dari sana ia menelusuri perjalanan data sampai keluar sebagai response.

Bayangkan Anda sedang menelusuri fitur pengajuan refund. Anda mulai dari controller yang menerima HTTP request. Anda lihat bagaimana request divalidasi, lalu diteruskan ke service layer. Di service layer Anda menemukan business logic: apakah refund ini memenuhi syarat? Apakah ada duplikasi? Apakah pengguna masih dalam masa berlaku kontrak? Setiap pertanyaan ini membawa Anda ke fungsi-fungsi lain, ke repository yang mengambil data dari database, ke client yang memanggil API eksternal untuk verifikasi pihak ketiga.

Diagram berikut menggambarkan alur yang dimaksud, dari controller hingga response, termasuk jalur error yang jarang dilalui.

flowchart TD A[HTTP Request] --> B[Controller] B --> C{Validasi} C -- Gagal --> D[Return Error Response] C -- Lolos --> E[Service Layer] E --> F{Cek Syarat Refund} F -- Tidak Memenuhi --> G[Return Rejection] F -- Memenuhi --> H{Cek Duplikasi} H -- Duplikat --> I[Return Duplicate Error] H -- Unik --> J[Repository: Ambil Data User] J --> K{Cek Masa Kontrak} K -- Kedaluwarsa --> L[Return Expired Error] K -- Aktif --> M[API Eksternal: Verifikasi Pihak Ketiga] M -- Timeout --> N[Return Timeout Error] M -- Data Tidak Sesuai --> O[Return Schema Error] M -- Sukses --> P[Proses Refund] P --> Q[Return Success Response]

Inilah yang membedakan senior engineer. Ia tidak berhenti di satu file. Ia mengikuti alur sampai ke ujung, termasuk jalur yang jarang dilalui. Ketika menemukan panggilan ke layanan eksternal, ia bertanya: apa yang terjadi jika layanan itu lambat? Apa yang terjadi jika timeout? Apa yang terjadi jika return data yang tidak sesuai skema? Ia menelusuri error path dengan keseriusan yang sama seperti happy path.

Dalam praktiknya, menelusuri alur seperti ini membutuhkan alat bantu. IDE dengan fitur “go to definition” dan “find references” menjadi sahabat utama. Beberapa tim menyediakan tracing terdistribusi yang menampilkan perjalanan request melintasi service. Tapi alat hanyalah pemercepat. Yang lebih penting adalah pola pikir: Anda sedang membangun model mental tentang bagaimana sistem benar-benar bekerja, bukan bagaimana dokumen solusi menggambarkannya.

Berikut contoh perintah yang bisa Anda jalankan di terminal untuk menelusuri alur refund dari controller ke service ke repository:

# Cari semua file yang memanggil refundService
grep -r "refundService" --include="*.go" -l

# Lihat definisi fungsi Refund di service layer
grep -n "func.*Refund" --include="*.go" -r

# Lihat panggilan ke repository dari service
grep -rn "repository\." --include="*.go" | head -10

Seringkali Anda akan menemukan kejutan. Mungkin business logic ternyata tidak persis seperti yang ditulis di dokumen. Mungkin ada validasi tambahan yang tidak tercatat. Mungkin ada caching yang mengubah perilaku sistem. Mungkin ada jalur cadangan mechanism yang hanya aktif dalam kondisi tertentu. Semua ini tidak akan Anda temukan jika Anda hanya membaca file secara acak atau hanya percaya pada diagram.

Setelah Anda menguasai satu alur utama, Anda bisa beralih ke alur lain. Tapi jangan terburu-buru. Satu alur yang dipahami dengan baik lebih berharga daripada sepuluh alur yang hanya Anda lihat sekilas. Karena dari satu alur itulah Anda mulai memahami pola yang digunakan tim: bagaimana mereka menangani error, bagaimana mereka memisahkan tanggung jawab, bagaimana mereka mengelola state, bagaimana mereka berkomunikasi dengan sistem lain.

Yang menarik, AI bisa membantu proses ini. Anda bisa bertanya pada AI assistant: “Tunjukkan alur lengkap dari request pembuatan refund, dari controller sampai response.” AI akan membaca seluruh codebase dan menyusun alurnya. Tapi Anda tetap harus memverifikasi. Karena AI bisa melewatkan cabang kondisi, salah memahami logika kompleks, atau tidak menangkap konteks bisnis yang tersirat dalam kode.

Memahami alur utama adalah fondasi. Setelah ini Anda akan siap membaca petunjuk dari production: log, metrik, dan insiden yang menunjukkan apakah sistem benar-benar berjalan seperti yang Anda pahami. Tapi itu untuk subbab berikutnya. Untuk sekarang, latih diri Anda menelusuri satu alur sampai ke ujung, termasuk jalur errornya. Itulah cara senior engineer membaca codebase.