Sistem perangkat lunak cenderung mengakumulasi sampah - kelemahan internal yang membuatnya lebih sulit untuk memodifikasi dan memperluas sistem dibandingkan dengan kode ideal. Utang teknis adalah metafora yang ditemukan oleh Ward Cunningham. Dia menjelaskan bagaimana memahami sampah ini, dengan analogi dengan pinjaman keuangan. Upaya tambahan yang diperlukan untuk menambah fitur baru adalah bunga pinjaman.



Bayangkan di basis kode saya ada modul struktur bingung. Perlu menambahkan fitur baru. Jika strukturnya jelas, maka pekerjaan akan memakan waktu empat hari, tetapi dengan sampah ini butuh enam hari. Perbedaan dalam dua hari - ini adalah bunga hutang.

Apa yang paling menarik bagi saya dalam metafora hutang adalah pemahaman yang jelas tentang biaya servis atau penghapusannya. Saya bisa menghabiskan lima hari membersihkan struktur modular, membuang sampah, secara metaforis membayar "pemberi pinjaman". Jika saya melakukan ini untuk fungsi ini, saya akan kehilangan karena saya akan menghabiskan sembilan hari, bukan enam. Tetapi jika ada dua fungsi yang lebih, maka lebih menguntungkan untuk membuang sampah.

Dengan rumusan ini, tugas menjadi murni matematika. Setiap manajer dengan tablet elektronik akan menyelesaikannya. Sayangnya, kami tidak dapat mengukur kinerja , jadi tidak ada biaya yang dapat diukur secara objektif. Kita dapat memperkirakan kira - kira berapa lama untuk mengembangkan fungsi, berapa lama untuk bekerja setelah membuang sampah - dan mengasumsikan biaya untuk menghilangkannya. Tetapi akurasi estimasi semacam itu agak rendah.

Oleh karena itu, biasanya pilihan terbaik adalah melakukan apa yang biasanya kita lakukan dengan hutang keuangan: secara bertahap membayar pokok. Pada fungsi pertama, saya akan menghabiskan beberapa hari ekstra untuk menghilangkan beberapa sampah. Ini mungkin cukup untuk mengurangi bunga atas utang, sehingga di masa depan itu bisa dilunasi dalam satu hari. Ini masih waktu ekstra, tetapi dengan menghilangkan sampah, perubahan di masa depan menjadi lebih murah. Keuntungan besar dari peningkatan bertahap adalah bahwa kami secara alami menghabiskan lebih banyak waktu membuang sampah di area yang sering berubah. Inilah tepatnya area basis kode yang paling membutuhkan pembuangan sampah.

Perbandingan pembayaran bunga dengan pelunasan utang utama membantu menentukan jenis sampah yang harus dihadapi. Jika saya memiliki beberapa area basis kode yang sangat mengerikan, maka masalahnya akan hilang jika ternyata tidak menguntungkan untuk menghapus sampah. Bunga dibayarkan hanya ketika Anda harus bekerja dengan bagian dari perangkat lunak ini (metafora agak timpang di tempat ini karena Anda selalu harus membayar pinjaman bank). Dengan demikian, area kode yang mengerikan tetapi stabil dapat dibiarkan sendiri.

Berbeda dengan bagian kode yang stabil, bidang aktivitas tinggi tidak memerlukan toleransi untuk sampah karena pembayaran bunga di sana sangat tinggi. Ini sangat penting, karena sampah menumpuk di mana pengembang membuat perubahan tanpa memperhatikan kualitas: semakin banyak perubahan, semakin besar risiko sampah.

Metafora hutang terkadang digunakan untuk menjustifikasi kode kualitas yang buruk. Argumennya adalah bahwa kode kualitas memerlukan lebih banyak waktu dan usaha. Jika Anda sangat membutuhkan fitur baru, lebih baik mengambil alih hutang dan menanganinya nanti

Bahayanya di sini adalah seringnya analisis ini keliru. Sampah sangat cepat mulai membahayakan, memperlambat pengenalan fitur-fitur baru. Akibatnya, pengembang melebihi batas kredit dan merilis produk lebih lambat daripada jika mereka akan segera menghabiskan waktu memberikan kualitas yang lebih tinggi. Di sini, metafora sering menyesatkan orang, karena dinamika utang teknis sebenarnya tidak sesuai dengan dinamika pinjaman keuangan. Dengan asumsi utang untuk mempercepat pelepasan produk hanya berfungsi jika Anda tetap di bawah garis hasil desain dalam hipotesis keberlanjutan arsitektur , dan pengembang melewatinya dalam beberapa minggu, bukan bulan.



Debat sering diadakan tentang apakah berbagai jenis sampah harus dianggap utang. Tampaknya bagi saya berguna untuk memperhitungkan apakah suatu tugas dilakukan secara sadar dan wajar - atau secara sembrono. Jadi, satu persegi utang teknis muncul .

Bacaan lebih lanjut

Sejauh yang saya tahu, Ward pertama kali memperkenalkan konsep ini dalam laporan OOPSLA 1992 . Itu juga dibahas di wiki .

Ada rekaman video di mana Ward Cunningham membahas metaforanya.

Dave Nicolette memperluas pandangan Ward tentang utang teknis dengan memberikan contoh yang bagus tentang apa yang saya sebut utang sengaja wajar .

Beberapa pembaca menyarankan metafora lain yang valid. David Panarity menyebut pengembangan berkualitas rendah sebagai kekurangan pemrograman . Rupanya, dia mulai menggunakan istilah itu beberapa tahun yang lalu ketika itu konsisten dengan kebijakan pemerintah; Saya kira sekarang ini relevan lagi.

Scott Wood menyarankan untuk memperlakukan “ inflasi teknis sebagai kehilangan tanah ketika tingkat teknologi saat ini jauh melebihi tingkat produk Anda sehingga secara bertahap jatuh dari lingkungan. Program tertinggal dalam versi bahasa sedemikian rupa sehingga kode tidak lagi kompatibel dengan kompiler utama. "

Steve McConnell menyoroti beberapa poin bagus dalam metafora. Khususnya, karena pengurangan hutang yang tidak disengaja menyisakan lebih banyak ruang untuk secara sengaja menerima hutang ketika itu bermanfaat. Saya juga suka perumusan pembayaran minimum (yang terlalu tinggi untuk memperbaiki masalah pada sistem yang disematkan, tetapi tidak pada situs).

Aaron Erickson berbicara tentang membiayai Enron .

Henrik Kniberg berpendapat bahwa utang teknis lama menyebabkan masalah terbesar, dan bahwa bijaksana untuk menetapkan plafon utang berkualitas tinggi agar lebih mudah dikelola.

Eric Dietrich membahas kehilangan manusia karena hutang teknis : pertempuran tim, penurunan keterampilan, dan kelelahan.

Suntingan

Posting ini awalnya diterbitkan pada 1 Oktober 2003. Saya menulis ulang sepenuhnya pada bulan April 2019.