Sebagai mahasiswa ilmu komputer atau pegiat coding di kampus, kita pasti sering bikin aturan dokumentasi yang muluk-muluk di awal proyek kelompok. Mulai dari satu dokumen satu tanggung jawab, sampai aturan ketat nggak boleh nulis baris kode atau teks terlalu panjang. Tapi, apa yang terjadi di hari pertama? Semuanya dilanggar!

Pengalaman ini saya rasakan sendiri pada proyek saya. Aturan sudah ditulis manis-manis sehari sebelumnya, tapi realitanya bikin geleng-geleng kepala. Ada 25 dari 37 folder yang tidak punya README atau index, folder khusus aturan teknik isinya berantakan tanpa index, dan ada dokumen yang melanggar aturan batas 45 baris dengan rekor mencengangkan: 1.203 baris!

Menulis Aturan Saja Tidak Cukup, Biarkan Mesin yang Menegakkan

Nulis aturan di atas kertas (atau file Markdown) nggak bikin aturan itu serta-merta dipatuhi. Mau nggak mau, kita harus biarkan mesin yang menegakkannya lewat Continuous Integration (CI). Tapi sebelum itu, saya sempat dihadapkan pada dilema klasik saat pertama kali menjalankan checker CI:

  • 63 pelanggaran langsung muncul sekaligus! Semua jadi merah membara.
  • Opsi pertama: Perbaiki semua 63 pelanggaran dulu dari awal sebelum CI diaktifkan.
  • Opsi kedua: Bikin file .lintignore, masukkan 63 pelanggaran itu ke dalam daftar hitam, kasih komentar "hapus nanti", lalu lanjut ngoding.

Tentu saja opsi kedua sangat menggoda. Tapi pertanyaannya: Kapan daftar "nanti" itu benar-benar dibersihkan? Jawabannya: nggak pernah. Daftar pengecualian itu hanya akan jadi sumber kebenaran kedua yang dibiarkan menumpuk tanpa ada insentif untuk menghapusnya.

Menghindari Jebakan Aturan yang Terlalu Kaku

Kalau kita pakai aturan ekstrem bahwa setiap file yang melebihi 45 baris harus langsung di-refactor, apa yang terjadi kalau seseorang cuma mau benerin typo satu karakter di file berukuran 1.200 baris? PR-nya bakal ditolak oleh CI dengan alasan filenya terlalu panjang.

Akibatnya? Tim bakal malas benerin typo. Aturan malah berubah jadi mesin yang menghukum progress kecil. Makanya, logika CI harus cerdas:

  • Jangan hukum file lama yang nggak disentuh.
  • Jangan biarkan file bertambah panjang dari ukuran aslinya.
  • Gunakan git untuk membandingkan apakah file tersebut bertumbuh saat di-merge. Jika tidak bertambah panjang, biarkan lolos.

Pelajaran Pahit Seputar Secret Scanning

Masalah lain yang sering bikin pusing adalah deteksi token rahasia atau API keys. Saat pemindaian pertama gagal karena false-positive pada placeholder bertanda kurung siku (<TOKEN_NAME>), godaan terbesarnya adalah mengecualikan seluruh folder docs dari pemindaian.

Untungnya hal itu tidak saya lakukan. Kalau saya mengecualikan folder tersebut, saya tidak akan pernah sadar ada production signing secret milik saya sendiri yang tersimpan plain-text di dalam dokumentasi! Pelajaran pentingnya: Eksklusifkan bentuk polanya (shape), bukan tempat foldernya (place).

Kesimpulan: Worth It Gak Buat Diterapkan di Proyek Skripsi?

Menerapkan sistem CI yang ketat tanpa membuat file ignore yang menumpuk terbukti sangat efektif menjaga kerapian kode dan dokumentasi jangka panjang. Meskipun mesin tidak bisa mengecek apakah tulisan dokumentasi kita sinkron secara logika dengan sistem aslinya, setidaknya struktur dasar proyek tetap bersih dari utang teknis (technical debt).

Buat kalian para mahasiswa yang sedang merintis proyek akhir atau aplikasi bareng teman satu tim, mulailah mendisiplinkan diri dengan automasi sejak hari pertama. Jangan biarkan aturan hanya menjadi pajangan di dalam repo GitHub!