Salah satu agile manifesto yang berisi keutamaan aplikasi yang berjalan dibanding dokumentasi yang komprehensif dapat menjadi pisau bermata dua
Saya bukan anti agile, tapi penerapan ini dapat mengakibatkan blunder bila tidak disikapi dengan hati-hati.
Penghilangan dokumentasi dapat menjadikan developer menjadi kuncen (juru kunci) atas modul / fitur yang ditulisnya, karena developer lain merasa was-was apabila melakukan perubahan kode, atau product manager merasa delivery lebih cepat apabila dilakukan oleh developer yang mengerjakan modul itu sebelumnya;
Atau ketika developer itu berpindah kerja, maka developer penggantinya susah untuk melanjutkan atau melakukan optimasi kode tersebut, sebab kode yang tersedia susah dipahami atau apabila melakukan perubahan didalamnya, akan berpengaruh ke modul lain (senggol bacok kasarannya).
Untuk itu perlu beberapa pendekatan untuk memitigasi tantangan tersebut.
- Unggah kode ke repository secara teratur.
Pastikan setiap kode tersimpan di repository, untuk memudahkan gunakan awalan no tiket pada branch yang ingin dibuat. Usahakan setiap selesai kerja untuk mem-push kode pada repository, berjaga-jaga apabila gawai yang digunakan mengalami masalah.
Developer yang baik tidak akan takut untuk menunjukkan hasil kerja mereka, walaupun masih dalam status pengembangan (wip)
- Lakukan kode review sebelum masuk ke mesin produksi
Semua kode yang akan masuk ke mesin produksi seyogyanya melewati proses review. Kode harus cukup rapi untuk dipahami. Tidak perlu berdebat sengit antara aliran spasi atau tab. Setidaknya kode dapat dibaca dan dipahami oleh rekan kerja.
Kode review dapat pula menjadi jembatan transfer knowledge (pertukaran ilmu) dan wisdom knowledge (pandangan multi perspektif) yang dapat memperkaya konsep pemograman dan teknis, selain dapat memberi sudut pandang lain apakah solusi yang diberikan dapat lebih ditingkatkan. Jangan baper ya di review ini, kita berusaha untuk menjadi lebih baik kok, bukan untuk menjatuhkan.
Untuk memudahkan standarisasi, dapat dibantu oleh linter (aplikasi analisa kode dan gaya penulisan program) seperti rubocop pada rails, linter-php untuk php, sonar dan findbugs untuk java.
- Investasi di test
Kode tidak akan bekerja kecuali terbukti lolos tes. Kode harus dianggap tidak layak bekerja bila belum ada tesnya. Tes tidak menjamin kode 100% bebas dari bug, tapi dapat membantu apakah perubahan kode yang dilakukan merusak fungsional sistem saat ini dan dapat menjadi semacam dokumentasi teknis bagaimana fungsi dari modul berjalan.
Tes ini dapat berguna juga untuk melihat ketahanan kode kita apabila ada skenario diluar normal, semisal ketika user melakukan input sembarang apakah menyebabkan aplikasi menjadi error atau tidak.
- Dokumentasi teknis
Dimana kita dapat meletakkan dokumentasi dalam kode:
- Readme.md
readme.md merupakan tempat permulaan dari semua dokumentasi. Saat orang ingin mengatahui basis kode, ini merupakan titik pertama untuk melihat.
readme.md berisi setidaknya gambaran kasar atas apa yang aplikasi mampu perbuat. Ini sangat berguna pada perusahaan yang memiliki banyak repositori dimana developer dapat berpindah antar repo dan mengetahui fungsionalitas repo dalam hitungan puluhan detik.
readme.md pun dapat menjadi semacam daftar isi dari dokumentasi yang lebih rinci apabila di lain hari repositori berkembang menjadi semakin kompleks. Semisal cara menjalankan aplikasi dapat diekstrak di dokumen lain seperti install.md
2. Commit message
“Commit message” berisi deskripsi perubahan apa yang ingin dicapai developer dalam kode yang dibuat.
Commit message ini akan berperan ketika kita ingin melihat riwayat bagaimana modul atau aplikasi berkembang, apa yang dipikirkan oleh developer atas kode yang diubah.
3. Pull request
Untuk memudahkan dalam pull request, saya membuat template dengan chrome extension untuk menampilkan panduan untuk kode agar dapat direview mulai dari:
- tujuan PR dibuat
- kode permulaan untuk direview
- bagaimana cara menduplikasi test secara manual
- dockup (environment test) bisa diakses dimana, dll
Poin terakhir, diperlukan keseimbangan dalam pengembangan aplikasi, dan tiap tim memiliki cara tersendiri (budaya) untuk menjalakannya. Kita dapat memiliki kode paling bersih, tingkat coverage test 100% atau dokumentasi paling lengkap dari A sampai Z, tapi disisi lain, adakah pelanggan yang menggunakan (membayar) produk kita. Atau sebaliknya, perusahaan dapat berjalan dengan kode yang acak adut tapi dapat memuaskan pelanggan dan menghasilkan uang didalamnya tapi kesulitan apabila ingin berkembang lebih besar karena perubahan kecil susah dikontrol.
Dengan sisi lain, product owner dan developer harus dapat berkolaborasi dalam kualitas kode yang dihasilkan dengan kepentingan bisnis didalamnya.