- Isi yang dibagikan oleh para pengembang berpengalaman kepada pengembang baru tentang filosofi pengembangan perangkat lunak
- Berisi nasihat tentang berbagai topik seperti menghindari penulisan ulang total (ground-up rewrite), manajemen jadwal, kualitas kode, otomasi, dan penanganan edge case
Hindari situasi di mana penulisan ulang total (ground-up rewrite) terlihat menarik, apa pun harganya
- Godaan untuk melakukan penulisan ulang total biasanya muncul ketika akumulasi utang teknis sudah membuat kode lama sulit dipelihara
- Saat kompleksitas kode mulai menumpuk, kita harus lebih awal menangkap sinyal peringatan seperti perubahan sederhana pun menjadi sulit, komentar/dokumentasi susah ditulis, atau semakin sedikit orang yang memahami kode inti, lalu aktif mencari solusi
- Setelah fase ekspansi selesai, kompleksitas harus dikurangi dan kualitas harus dirapikan melalui tahap integrasi
- Jika penulisan ulang total menjadi tak terhindarkan, itu berarti proyek sudah memasuki fase berbahaya
- Untuk mengurangi risiko, utang teknis harus terus dikelola dan kualitas kode harus dipantau dengan saksama
Selesaikan 90% dari seluruh pekerjaan dalam separuh waktu yang tersedia
- Menulis kode versi pertama hingga bisa berjalan hanyalah sekitar separuh dari keseluruhan pekerjaan
- Tahap setelah itu—penanganan edge case, pengujian, deployment, dokumentasi, performa, kemudahan pemeliharaan, dan sebagainya—membutuhkan waktu jauh lebih banyak daripada yang dibayangkan
- Sisakan buffer yang cukup untuk menangani masalah tak terduga atau pekerjaan penyempurnaan akhir (polishing)
- Pada akhirnya, kita harus menyadari adanya jarak antara “membuat kode asal berjalan di awal” dan “menjadikannya fitur yang benar-benar selesai”, lalu mencerminkannya dalam jadwal
Otomatiskan praktik terbaik
- Jika hanya berulang kali menekankan kepada pengembang secara lisan atau lewat dokumen bahwa “harus dilakukan seperti ini”, kesalahan tetap mudah terjadi
- Jika memungkinkan, lebih efektif memaksakannya melalui automated test atau skrip dalam bentuk seperti “build gagal jika aturan dilanggar”
- Aturan yang baru diperkenalkan—seperti API yang dilarang atau komentar yang wajib ditambahkan—juga bisa diotomatisasi secara bertahap untuk mengurangi error atau kelalaian
- Namun, tidak semua hal bisa diotomatisasi, dan aturan yang terlalu ketat bisa mengganggu alur pengembangan, jadi tetap perlu keseimbangan
Pertimbangkan juga data ekstrem (patologis/Pathological)
- Menilai kode hanya berdasarkan input normal (golden path) itu berbahaya
- Kita perlu mengasumsikan situasi bermasalah seperti request yang tertunda atau terputus, data dalam jumlah sangat besar (ratusan ribu hingga ratusan juta baris), atau string aneh (terlalu panjang, mengandung slash atau spasi)
- Kesiapan menghadapi edge case secara menyeluruh sangat menentukan kualitas akhir kode
Biasanya ada cara yang lebih sederhana untuk menuliskannya
- Setelah membuat kode bisa berjalan di tahap awal, sebaiknya sisihkan waktu untuk meninjaunya kembali dan memperbaikinya agar lebih sederhana dan jelas
- Meski sudah menemukan “solusi yang tampak bagus”, penting untuk tetap punya sikap yang memberi ruang untuk meninjau lagi apakah ada solusi yang lebih baik
- Proses me-refactor kode yang panjang dan kompleks menjadi ringkas akan meningkatkan kualitas akhir
Tulis kode agar mudah diuji
- Jika interface dan side effect diminimalkan, penulisan automated test menjadi jauh lebih mudah
- Jika strukturnya sulit diuji, besar kemungkinan encapsulation-nya belum dilakukan dengan baik
- Jika struktur kode dirancang secara konkret agar pengujian bisa berjalan dengan baik, bug dapat ditemukan lebih dini
Kode yang “secara pembuktian” tidak bermasalah bukan berarti selesai
- Kode yang secara struktural tampak aman pun bisa menimbulkan masalah ketika lingkungan sekitarnya berubah atau sebagian cara pemanggilannya ikut berubah
- Untuk kode terkait keamanan, meskipun call site saat ini aman, desainnya tetap perlu mempertimbangkan kemungkinan perubahan di masa depan
- Kode harus ditulis agar “jelas aman, dan tetap tidak bermasalah meski terjadi perubahan”
Komentar
- Sumber kutipan “Saya tidak menulis surat ini lebih singkat karena saya tidak punya waktu untuk menulisnya lebih singkat” adalah Pascal
- Selalu waspadai off-by-one error
- Menambahkan guideline baru ke wiki
- Jika sistem dokumentasi/berbagi pengetahuan di dalam perusahaan tidak tertata dengan baik, informasi akan tersebar dan menimbulkan kebingungan
- Dokumen resmi bisa menjadi usang karena harus melalui proses persetujuan, atau beberapa wiki bisa ada bersamaan sehingga tidak jelas mana yang menjadi referensi resmi
- Menetapkan hanya satu wiki sebagai pusat seluruh materi, lalu membiarkan pengembang menulis langsung bagian yang kurang atau melengkapinya lewat reverse-engineering, adalah pendekatan yang efektif
- Jika dokumentasi terhubung dengan baik ke tempat lain (source control, komentar kode, dan sebagainya), informasi terbaru akan lebih mudah dipertahankan
- Jika automated test dan lingkungan build terlalu rumit atau tidak terekspos ke pengembang, bisa muncul situasi di mana tidak ada yang benar-benar pernah menjalankan seluruh test
- Skrip build Jenkins sebaiknya dijaga tetap sederhana dalam bentuk seperti “cd project; ./build-it”, dan skrip ini sendiri lebih baik juga dimasukkan ke source control
- Jika seluruh tim berbagi lingkungan yang sama (misalnya image virtual machine, pengaturan build) untuk menjalankan build dan test, banyak masalah bisa dicegah lebih awal
- Akan bermanfaat jika edge case dipertimbangkan sejak tahap pengembangan, misalnya membuat
destroy_object(foo) tetap aman walaupun foo bernilai NULL, atau membuat destroy_object() dipanggil secara internal ketika create_object() gagal
- Pada akhirnya, yang penting adalah memastikan semua pengembang dapat dengan mudah mengakses dan berpartisipasi dalam dokumentasi serta lingkungan build/test
- Dokumentasi dan automated test: Disebutkan saran praktis bahwa dokumen atau wiki penting untuk berbagi pengetahuan, dan pengaturan lingkungan CI/CD seperti Jenkins juga harus bisa dibagikan
- Tidak ada alat perubahan perilaku yang lebih efektif daripada “membuat orang merasa tidak nyaman” sampai mereka menghafal perilaku yang diinginkan
- Seperti ada juga posisi yang menentang pepatah catur, “Jika melihat langkah yang tampak bagus, langsung jalankan”, dalam pemrograman pun sama. Ada dua sisi yang perlu dipertimbangkan.
6 komentar
> Biasanya ada cara yang bisa ditulis lebih sederhana
Saya percaya bahwa memikirkan solusi yang lebih ringkas akan menurunkan kompleksitas kode dan kebijakan.
> "Menyelesaikan 90% dari seluruh pekerjaan dalam setengah dari waktu yang memungkinkan"
Menurut saya ini memang sangat benar. Daripada mencoba mengimplementasikannya secara sempurna sekaligus, meninjaunya dua kali dengan cepat justru mengurangi kesalahan dan membuat pengelolaan waktu jadi lebih baik.
ground-up rewrite) terlihat menarik> Selalu waspadai off-by-one error
Saya sempat bertanya-tanya apa itu off-by-one error, ternyata ini adalah jenis error yang berkaitan dengan kondisi batas seperti
for (int i = 1; i < n; ++i) { ... },for (int i = 0; i <= n; ++i) { ... }.> Hindari situasi di mana penulisan ulang total dari nol (
ground-up rewrite) terlihat menarik, berapa pun harga yang harus dibayar.Saya rasa ini adalah pitfall yang membuat bisnis banyak perusahaan IT gagal berkembang, dan ketika technical debt sudah menumpuk, organisasi engineering yang tidak mampu mengatasinya (atau tidak ingin mengatasinya) tampaknya menganggap penulisan ulang total sebagai sesuatu yang menarik.
Saya sangat sependapat dengan pandangan para penulis bahwa, jika tidak ada alasan yang benar-benar meyakinkan, penulisan ulang sebaiknya dihindari sebisa mungkin.
Pendapat Hacker News
Pengembangan perangkat lunak adalah proses berulang antara mencoba dan belajar. Pengembang berpengalaman meningkatkan pemahaman mereka dengan menulis dan menguji kode, serta banyak belajar, tetapi hal ini sering tidak terlihat dalam rapat atau perencanaan. Pengembang junior kesulitan menghasilkan kode yang siap produksi dan cenderung enggan mengerjakan hal yang pada akhirnya dibuang. Jika manajer kurang memiliki pengalaman pengembangan, masalah ini bisa menjadi lebih buruk
Kutipan "Saya minta maaf menulis surat yang panjang, tetapi saya tidak punya waktu untuk menulis yang singkat" berasal dari matematikawan dan filsuf Prancis Blaise Pascal, dan mengandung makna bahwa menulis dengan singkat justru lebih sulit
Aturan 90/50 menekankan pentingnya pengujian dan penanganan pengecualian untuk meningkatkan kualitas kode. Menyiapkan pengujian otomatis membantu menetapkan ekspektasi yang jelas untuk codebase
Pendidikan ilmu komputer sering mendorong penulisan kode yang rumit, tetapi menulis kode yang mudah dibaca itu penting. Diperlukan penamaan variabel dan fungsi yang baik, formatting yang konsisten, serta desain yang modular
Mekanisme bernama Ratchet menyediakan cara yang sempurna untuk masa depan
Upaya untuk menggeneralisasi pengalaman dan pemahaman domain dapat berujung pada generalisasi yang keliru. Pengembangan adalah seni mengelola kompleksitas, dan penting untuk belajar melalui kegagalan
Kutipan "90% pertama dari pekerjaan memakan 90% waktu, dan 10% sisanya memakan 90% waktu lainnya" menggambarkan realitas pengembangan dengan baik. Saat mempertimbangkan penanganan pengecualian, error, kegunaan, keamanan, dan sebagainya, banyak pekerjaan tak terduga yang diperlukan
Tulisan Joel Spolsky memperingatkan risiko menulis ulang dan menekankan kebijaksanaan DevOps
Perlu mengoptimalkan keterbacaan kode dan menyadari bahwa semakin lama waktu hingga bug ditemukan, semakin besar biayanya. Lebih baik mengutamakan prinsip functional programming dan menggunakan sistem tipe yang kuat