Anda memang tidak bisa membaca code, tapi Anda tetap bisa menjalankan audit kualitas code, karena kesehatan sebuah codebase terlihat dari perilaku tim jauh sebelum terlihat di diff. Seberapa cepat developer baru bisa merilis perubahan pertamanya. Seberapa tegang tim menjelang rilis. Berapa banyak orang yang benar-benar memahami cara kerja sistem. Semua ini adalah pertanyaan yang bisa Anda ajukan dalam rapat 30 menit, tanpa perlu latar belakang teknis.
Saya sudah berada di kedua sisi ini, sebagai CTO yang menjawab pertanyaan-pertanyaan ini, dan yang lebih relevan untuk Anda, sebagai reviewer luar yang diminta menjawabnya tentang sistem milik orang lain. Sinyal-sinyal proksi ini cukup konsisten sehingga Anda tidak perlu mempercayai laporan siapa pun begitu saja. Anda hanya perlu mengajukan pertanyaan yang tepat dan peka terhadap jawaban yang tidak nyambung.
Satu pertanyaan yang paling banyak bicara
"Berapa lama waktu yang dibutuhkan developer baru untuk merilis perubahan kecil pertamanya?"
Di codebase yang sehat, jawabannya hitungan hari, paling lama dua minggu untuk sesuatu yang lebih kompleks. Di codebase yang tidak sehat, jawabannya sebulan atau lebih, dengan alasan yang biasanya berbunyi "sistem kami memang rumit." Kompleksitas itu nyata, tapi butuh sebulan untuk merilis apa pun adalah masalah dokumentasi dan struktur, bukan masalah kecerdasan. Artinya orang baru tidak bisa menemukan jalannya di dalam sistem, yang berarti hanya tim yang ada sekarang yang bisa menyentuh code dengan aman, dan itu adalah risiko bisnis yang Anda tanggung tanpa Anda sadari.
Tanyakan ini langsung ke vendor atau lead internal Anda. Lalu tanyakan lagi, secara terpisah, ke developer yang paling baru direkrut. Kesenjangan antara kedua jawaban itu sendiri sudah informatif.
Sinyal yang bisa Anda cek tanpa membuka editor
- Frekuensi dan suasana hati saat deploy. Tanyakan "kapan terakhir kali deploy, dan apakah itu bikin stres?" Tim dengan code yang sehat melakukan deploy sering (harian atau mingguan) dan menganggapnya rutin. Tim dengan code yang rapuh jarang deploy dan memperlakukan setiap rilis seperti keadaan darurat kecil. Kalau deploy hanya terjadi sebulan sekali dan semua orang tegang sebelumnya, itu jawabannya.
- Pertanyaan bus factor. "Kalau [developer senior] cuti sebulan besok, apa yang terjadi pada roadmap?" Jawaban yang baik menyebut dua atau tiga nama yang bisa menggantikan. Jawaban yang buruk adalah keheningan panjang, atau satu nama yang diulang-ulang dengan gugup.
- Kekambuhan bug. "Apakah kategori bug yang sama muncul lagi setelah pernah diperbaiki?" Bug yang berulang di area yang sama biasanya berarti akar masalahnya, bukan sekadar gejalanya, tidak pernah benar-benar ditangani.
- Cek realitas dokumentasi. Minta untuk melihat dokumen onboarding yang diterima karyawan baru. Bukan untuk menilai akurasi teknisnya, cukup cek apakah dokumen itu memang ada, lalu tanyakan ke karyawan yang paling baru direkrut apakah dokumen itu benar-benar berguna atau mereka justru belajar dengan bertanya ke sana-sini.
- Cakupan test, versi laporan lalu versi kenyataan. Tanyakan berapa persen code yang punya automated test. Berapa pun angkanya, lanjutkan dengan "kalau ada test yang gagal, apakah tim berhenti dan memperbaikinya, atau di-comment-out lalu lanjut jalan?" Jawaban kedua ini lebih penting daripada yang pertama.
Membaca jawaban seperti kasus McKinsey, bukan kuis teknis
Tidak satu pun dari pertanyaan ini menuntut Anda memahami satu baris code pun, tapi semuanya menuntut Anda peka terhadap ketidakkonsistenan. Kalau vendor Anda bilang deploy berjalan mulus tapi account manager Anda menyebut "kemarin weekend agak berat untuk merilis versi terakhir," itu tanda bahaya. Kalau tim bilang dokumentasi sudah solid tapi karyawan paling baru bilang mereka tersesat selama tiga minggu, itu tanda bahaya. Anda tidak sedang menilai kemampuan teknis, Anda sedang mengecek apakah cerita yang disampaikan sesuai dengan pengalaman orang-orang yang benar-benar menjalaninya.
Ini logika audit yang sama yang saya terapkan pada keputusan build versus buy: risiko sesungguhnya biasanya tidak terlihat dalam presentasi, tapi terlihat dari bagaimana tim berperilaku dalam kondisi operasional normal.
Kapan harus melibatkan reviewer dari luar
Jalankan dulu langkah-langkah di atas sendiri, tidak ada biaya selain waktu Anda. Libatkan reviewer teknis eksternal kalau salah satu dari ini muncul:
| Sinyal | Kenapa penting |
|---|---|
| Satu orang memegang semua pengetahuan krusial | Single point of failure untuk seluruh bisnis Anda |
| Onboarding butuh lebih dari sebulan | Masalah struktural, bukan masalah training |
| Tim keberatan kalau ada yang melihat code mereka | Biasanya tanda mereka sudah tahu code itu tidak akan lolos pemeriksaan |
| Anda akan mengakuisisi, berinvestasi, atau sangat bergantung pada sistem ini | Biaya kalau Anda salah menilai jauh lebih besar daripada biaya audit |
Audit sungguhan pada titik ini memakan waktu satu hari hingga beberapa hari kerja seorang senior engineer, biasanya di kisaran 8 hingga 20 juta Rupiah tergantung ukuran sistem, dan hasilnya harus berupa laporan berbahasa awam, bukan stack trace. Minta itu secara eksplisit di awal, supaya Anda tidak diberi empat puluh halaman yang tidak bisa Anda pakai.
Kesimpulan
Audit kualitas code tidak menuntut Anda membaca satu fungsi pun. Yang dibutuhkan adalah bertanya soal waktu onboarding, kepercayaan diri saat deploy, kekambuhan bug, dan siapa yang memegang pengetahuan, lalu benar-benar mendengarkan kesenjangan antara apa yang diceritakan kepada Anda dan apa yang dialami orang paling baru dan paling tidak berkepentingan di tim. Jalankan percakapan ini setiap kuartal dengan vendor atau tim internal mana pun yang Anda andalkan, dan libatkan mata teknis dari luar hanya ketika jawabannya benar-benar tidak nyambung. Kalau Anda butuh opini kedua atas sistem yang akan Anda pertaruhkan untuk bisnis, itu persis jenis engagement yang ditangani ervandra.com.