- Konsep utang teknis
- Biaya implisit dari pekerjaan ulang di masa depan yang diperlukan ketika memilih solusi yang mudah tetapi terbatas, alih-alih mengambil pendekatan yang lebih baik yang mungkin memakan waktu lebih lama
- Biaya pekerjaan tambahan yang timbul karena memilih solusi tercepat, bukan solusi yang paling efektif
- Jenis utang teknis yang dibedakan oleh insinyur perangkat lunak Martin Fowler
- Utang teknis yang bijaksana dan disengaja (Prudent & Deliberate)
- Tim tahu bahwa mereka sedang berutang, tetapi mempertimbangkan apakah ‘imbalan rilis yang lebih cepat lebih besar daripada biaya melunasi utang’
- Utang teknis yang ceroboh dan disengaja (Reckless & Deliberate)
- Hasil dari keputusan untuk melanjutkan dengan cara ‘cepat dan berantakan’ karena tahu praktik desain yang baik dan mampu menerapkannya, tetapi tidak punya waktu untuk menulis kode yang rapi
- Utang teknis yang bijaksana tetapi tidak disengaja (Prudent & Inadvertent)
- Hasil ketika perangkat lunak yang baik telah dibuat dan kodenya rapi, tetapi baru seiring waktu menyadari ‘seharusnya desainnya seperti apa’
- Utang teknis yang ceroboh dan tidak disengaja (Reckless & Inadvertent)
- Hasil yang muncul karena kurang tahu
- Cara mengatasi utang teknis
- Mengelola daftar utang teknis
- Lakukan retrospektif proyek untuk menyusun daftar utang teknis dan membagikannya
- Setiap kali utang teknis muncul, catat pekerjaan yang diperlukan untuk menyelesaikannya beserta perkiraan usaha dan jadwal
- Diskusikan dalam tim apakah utang teknis akan diselesaikan dan kapan waktunya, lalu susun rencana penyelesaiannya
- Membedakan utang teknis yang baik dan yang buruk
- Klasifikasi seperti ini membantu menentukan prioritas masalah terbesar
- Refactoring
- Sambil menjalankan pekerjaan, rapikan bagian yang diperlukan dan lakukan refactoring sedikit demi sedikit
- Saat melakukan refactoring skala besar, bagikan situasinya kepada tim dan beri tahu risiko serta biaya utang teknis
- Menulis kode pengujian
- Semakin kompleks kode dan semakin besar skala refactoring, semakin sulit memperbaiki kode sekaligus tanpa bug
- Untuk mencegah efek samping, tulis kode pengujian
- Menetapkan dan mematuhi standar kualitas
- Tetapkan standar kualitas agar coder tidak bisa merilis kode yang asal-asalan
- Hindari perubahan aturan atau jadwal yang mendadak
- Jika aturan terkait developer terus berubah dan tenggat waktu diubah-ubah, akan sulit menghindari utang teknis
- Sediakan jadwal, metodologi, dan beban kerja yang realistis agar utang teknis bisa dikelola
- Apakah utang teknis selalu buruk?
- Dalam buku karya Chris Riccomini dan Dmitriy Ryaboy, 『Bacaan Wajib! Panduan Onboarding Developer: Lahirnya developer profesional yang memahami software berkelanjutan dan budaya kolaborasi yang lancar』, disebutkan “jika itu adalah utang yang dilatih agar tim dapat menyelesaikannya nanti, maka itu bisa disebut ‘utang yang baik’”
- But utang teknis dapat berdampak negatif pada bisnis sehingga harus diselesaikan
- Hal ini muncul sebagai bug dan menurunkan pengalaman pengguna
- Jika utang teknis memburuk, developer akan lebih sulit bekerja di dalam codebase yang ada
- Karena waktu harus dibagi antara mengembangkan fitur baru dan memperbaiki fitur yang ada, siklus hidup pengembangan perangkat lunak melambat dan waktu peluncuran ke pasar tertunda
Belum ada komentar.