67

Apakah ada yang tahu jika ada semacam alat untuk meletakkan nomor pada utang teknis basis kode, sebagai semacam metrik kode? Jika tidak, adakah yang mengetahui algoritma atau set heuristik untuk itu?

Jika tak satu pun dari hal-hal itu ada sejauh ini, saya akan tertarik pada ide-ide untuk memulai dengan hal seperti itu. Yaitu, bagaimana saya bisa menghitung utang teknis yang ditimbulkan oleh suatu metode, kelas, namespace, majelis, dll.

Saya paling tertarik untuk menganalisis dan menilai basis kode C #, tapi jangan ragu untuk berpadu dengan bahasa lain juga, terutama jika konsepnya transenden bahasa.

code-quality technical-debt code-metrics

— Erik Dietrich
sumber

12

Utang teknis berasal dari keputusan, bukan kode. Itu timbul karena pilihan manajemen yang buruk. Tidak jelas bahwa "metode, kelas, ruang nama, majelis" mengandung utang teknis sendiri. Mereka mewakili kewajiban ketika ada pilihan yang lebih baik.

— S.Lott

7

Saya berpendapat (dalam konteks metafora utang) bahwa manajer mungkin adalah pemegang utang, tetapi kode artefak mewakili penilaian utang dan dapat dikuantifikasi. Artinya, saya setuju bahwa manajer dapat membuat keputusan seperti "lupakan pengujian unit karena kami tidak punya waktu" dan dengan demikian menimbulkan utang teknis. Tapi, saya pasti berpikir Anda dapat menempatkan angka ke elemen kode individual sebagai heuristik. Pikirkan seperti ini - jika manajemen membuat serangkaian keputusan yang mengerikan untuk masa depan, tetapi tidak ada kode yang ditulis, apakah ada hutang pada saat itu?

— Erik Dietrich

3

"Apakah ada hutang pada saat itu?" Utang memang perlu menumpuk, Anda benar. Tapi bukan kodenya; itu volume "pekerjaan" yang dilakukan yang perlu dibatalkan. Spesifikasi, desain, kode, pekerjaan DBA, semuanya harus dikerjakan ulang. Mengukur utang dari artefak perangkat lunak (seperti baris kode sumber) mirip dengan memperkirakan biaya pengembangan.

— S.Lott

7

Mengukur utang teknis itu sulit, ditambah lagi membingungkan manajer. Namun, saya dapat memberi tahu Anda cara yang baik untuk melawan utang teknis: prototipe murah, bagus dan berfungsi, terutama jika basis kode berputar di sekitar GUI. Seperti yang disarankan Joel di sini: joelonsoftware.com/articles/fog0000000332.html , habiskan sedikit waktu setiap hari untuk membereskan semuanya. Perubahan harus merupakan perbaikan positif, bukan "OMG, utang teknis kami = pentablobs dan naik secara eksponensial pada tingkat ... langit jatuh." Hanya menghabiskan sedikit waktu setiap hari pada kaizen dengan cara yang tidak merusak hal-hal yang berhasil. Berteman.

— Pekerjaan

6

@ZoranPavlovic Dilema aneh dan tidak diminta Anda tidak ada pilihan ketiga: Saya ingin tahu apakah ada alat yang berusaha untuk menghitung utang teknis.

— Erik Dietrich

38

Utang teknis hanyalah gagasan abstrak bahwa, di suatu tempat sepanjang garis merancang, membangun, menguji, dan memelihara sistem, keputusan tertentu dibuat sedemikian rupa sehingga produk menjadi lebih sulit untuk diuji dan dipelihara. Memiliki lebih banyak hutang teknis berarti semakin sulit untuk terus mengembangkan suatu sistem - Anda harus mengatasi hutang teknis dan mengalokasikan lebih banyak waktu untuk apa yang seharusnya menjadi tugas-tugas sederhana, atau Anda perlu menginvestasikan sumber daya (waktu dan uang) untuk mengurangi hutang teknis dengan refactoring kode, meningkatkan tes, dan sebagainya.

Ada sejumlah metrik yang mungkin memberi Anda beberapa indikasi mengenai kualitas kode:

Cakupan kode. Ada berbagai alat yang memberi tahu Anda berapa persen dari fungsi, pernyataan, dan garis yang dicakup oleh tes unit. Anda juga dapat memetakan tes sistem dan penerimaan kembali ke persyaratan untuk menentukan persentase persyaratan yang dicakup oleh tes tingkat sistem. Cakupan yang tepat tergantung pada sifat aplikasi.
Kopling dan kohesi . Kode yang menunjukkan kopling rendah dan kohesi tinggi biasanya lebih mudah dibaca, dipahami, dan diuji. Ada alat analisis kode yang dapat melaporkan jumlah kopling dan kohesi dalam sistem yang diberikan.
Kompleksitas siklomatik adalah jumlah jalur unik melalui aplikasi. Biasanya dihitung pada tingkat metode / fungsi. Kompleksitas siklomatik terkait dengan kemampuan memahami dan pengujian suatu modul. Nilai kompleksitas siklomatik yang lebih tinggi tidak hanya menunjukkan bahwa seseorang akan mengalami lebih banyak kesulitan dalam mengikuti kode, tetapi kompleksitas siklomatik juga menunjukkan jumlah kasus uji yang diperlukan untuk mencapai cakupan.
Berbagai ukuran kompleksitas Halstead memberikan wawasan tentang keterbacaan kode. Ini menghitung operator dan operan untuk menentukan volume, kesulitan, dan usaha. Seringkali, ini dapat menunjukkan betapa sulitnya bagi seseorang untuk mengambil kode dan memahaminya, sering kali dalam contoh seperti tinjauan kode atau pengembang baru ke basis kode.
Jumlah kode rangkap. Kode duplikat dapat menunjukkan potensi untuk refactoring ke metode. Memiliki kode duplikat berarti ada lebih banyak baris untuk bug yang akan diperkenalkan, dan kemungkinan lebih besar bahwa cacat yang sama ada di banyak tempat. Jika logika bisnis yang sama ada di banyak tempat, menjadi lebih sulit untuk memperbarui sistem untuk memperhitungkan perubahan.

Seringkali, alat analisis statis akan dapat mengingatkan Anda tentang masalah potensial. Tentu saja, hanya karena alat menunjukkan masalah tidak berarti ada masalah - dibutuhkan penilaian manusia untuk menentukan apakah ada sesuatu yang bermasalah di jalan. Metrik ini hanya memberi Anda peringatan bahwa mungkin sudah saatnya untuk melihat sistem atau modul lebih dekat.

Namun, atribut ini fokus pada kode. Mereka tidak dengan mudah menunjukkan utang teknis apa pun dalam arsitektur atau desain sistem Anda yang mungkin terkait dengan berbagai atribut kualitas.

— Thomas Owens
sumber

1

Saat ini saya menggunakan metrik NDepend ( ndepend.com ), CodeRush dan VS untuk mengawasi metrik yang Anda sebutkan (dengan pengecualian langkah-langkah Halstead, yang akan saya bahas lebih lanjut). Saya berpikir saya mungkin akan menggunakan gabungan dari metrik ini untuk mencoba menempatkan semacam angka pada elemen kode tertentu yang secara kasar akan menunjukkan, sekilas, betapa mahal untuk pengembangan yang sedang berlangsung.

— Erik Dietrich

@ErikDietrich Anda mungkin bisa, tetapi saya mungkin tidak akan menghitung nilai itu. Mungkin laporan gaya "ringkasan eksekutif" tentang apa yang dikatakan oleh alat metrik Anda, sehubungan dengan perubahan seiring waktu, akan lebih tepat.

— Thomas Owens

2

Metrik sederhana lain yang saya tambahkan ke dalam daftar adalah jumlah TODO / HACK / WTF? komentar dalam basis kode ...

— MaR

@Mar Itu mengasumsikan bahwa Anda menggunakan ini dengan benar dan tidak menggunakannya untuk keuntungan Anda. Ingin waktu ekstra untuk membersihkan basis kode, cukup tambahkan komentar ini di tempat yang tidak sesuai. Tidak peduli tentang basis kode, cukup hapus dari tempat seharusnya. Komentar bisa berbohong, kode tidak bisa.

— Thomas Owens

1

@Thomas Owens: setuju, tapi hampir semua metrik sendiri bisa ditipu. Jika digunakan dengan benar dan jujur, "TODO metric" memberikan tinjauan murah kode apa yang sebenarnya hilang atau harus diubah (= hutang tak terlihat untuk metrik berbasis kode saja).

— MaR

23

Sonar memiliki heuristik utang teknis serta beberapa fitur lain yang berguna untuk proyek perangkat lunak.

Ini juga mendukung berbagai bahasa yang cukup luas.

SonarQube (sebelumnya Sonar ) adalah platform open source untuk Pemeriksaan Kontinu kualitas kode ...

Mendukung 25+ bahasa: Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL, dll.

SonarQube juga digunakan di Android Deveopment.

Menawarkan laporan tentang kode duplikat, standar pengkodean, pengujian unit, cakupan kode, kode kompleks, bug potensial, komentar dan desain dan arsitektur.

Mesin waktu dan pandangan diferensial.

Analisis sepenuhnya otomatis: terintegrasi dengan Maven, Ant, Gradle, dan alat integrasi berkelanjutan (Atlassian Bamboo, Jenkins, Hudson, dll.).

Terintegrasi dengan lingkungan pengembangan Eclipse

Terintegrasi dengan alat eksternal: JIRA, Mantis, LDAP, Fortify, dll.

Dapat diperluas dengan penggunaan plugin.

Menerapkan metodologi SQALE untuk menghitung utang teknis ...

— Robert Greiner
sumber

1

Keren Terimakasih! Saya memiliki dan menggunakan NDepend untuk pekerjaan C # saya, tetapi saya juga melakukan sedikit pekerjaan Java dan saya tertarik pada metrik di sana. Paling tidak, ini memberi saya fungsionalitas untuk Java, dan itu bisa menjadi pelengkap yang bagus untuk NDepend.

— Erik Dietrich

Luar biasa, kami menggunakan Sonar tempat saya bekerja dan ia melakukan beberapa hal yang sangat bagus yang memberi Anda wawasan tentang kondisi basis kode Anda.

— Robert Greiner

2

@ErikDietrich, FYI Sonar juga memiliki plugin C # .

— Péter Török

@ErikDietrich FYI sekarang ada plugin NDepend untuk Sonar ndepend.com/docs/sonarqube-integration-ndepend

— Patrick Smacchia - NDepend dev

Apakah ada alternatif sumber terbuka?

— hellboy

5

Saya benci menggunakan analogi dari keuangan tetapi tampaknya sangat tepat. Ketika Anda memberi harga sesuatu (aset dalam bentuk apa pun), itu dapat memiliki nilai intrinsik dan ekstrinsik. Dalam hal ini, kode yang ada memiliki nilai intrinsik yang akan menjadi kuantitas yang sesuai dengan kualitas relatif dari kode tersebut dan juga akan memiliki nilai ekstrinsik (nilai dari apa yang dapat dilakukan ke kode) dan jumlah tersebut akan menjadi aditif. Nilai intrinsik dapat dipecah menjadi kredit dan debit (baik vs buruk) menggunakan metodologi apa pun yang Anda gunakan untuk mencetak kode (+5 untuk komentar / keterbacaan, -10 untuk cakupan kode, dll.)

Saya tentu saja tidak tahu alat apa pun yang menghitung ini hari ini dan saya pikir Anda akan memiliki diskusi yang sepenuhnya baru di tangan Anda jika Anda berdebat tentang manfaat dari berbagai strategi "penilaian hutang" tetapi saya setuju dengan Matthew - hutang adalah biaya kumulatif untuk mendapatkan kode sebaik yang Anda bisa dapatkan, menggunakan metode apa pun yang Anda gunakan untuk mengeluarkan biaya jam kerja yang dibutuhkan untuk sampai ke sana.

Hal lain yang perlu dipertimbangkan adalah bahwa tentu saja ada ukuran efektivitas biaya di mana ketika seseorang semakin mendekati "kesempurnaan", nilai satu jam yang dihabiskan pada basis kode lebih dari kemungkinan menurun secara eksponensial sehingga mungkin ada masalah optimasi tambahan untuk memaksimalkan utilitas dari pekerjaan yang dilakukan.

— Pencocokan Pola
sumber

Ya, konsep pengembalian marjinal yang berkurang tentu saja merupakan sesuatu yang ingin saya sampaikan dalam membuat dan menyempurnakan metrik. Jadi, bukan hanya "inilah argumen objektif saya untuk refactoring kelas ini dari perspektif bisnis" tetapi juga "inilah alasan saya untuk tidak repot pada saat ini."

— Erik Dietrich

5

Di antara pengembang, ukuran utang teknis yang cukup dapat diandalkan tampaknya adalah WTF / menit .

_{Masalah dengan "metrik" ini adalah bahwa biasanya agak sulit untuk berkomunikasi "di luar".}

Metrik yang bekerja untuk saya dalam mengkomunikasikan utang teknis kepada "orang luar" adalah jumlah upaya pengujian dan perbaikan bug (terutama untuk memperbaiki bug regresi ) yang diperlukan untuk pengiriman yang sukses.

Peringatan: meskipun pendekatan ini cukup kuat, orang akan lebih baik memeriksa dengan WTF lama yang baik / menit sebelum beralih ke itu. Masalahnya, ini cukup rumit: untuk mendapatkan data, kita harus melacak waktu dengan cermat dan mencatatnya secara akurat per kategori yang sesuai.

jauh lebih mudah untuk menyatakan total 3 minggu yang dihabiskan untuk mengimplementasikan fitur A daripada

saya menghabiskan 14 jam pada draft implementasi fitur A kemudian 29 jam pada pengujian asap lalu 11 jam pada implementasi perbaikan untuk regresi yang saya temukan, kemudian 18 jam menguji QA Implementasi fitur sudah. Setelah itu, QA guys menghabiskan 17 jam untuk menguji rilis kandidat awal. Setelah itu saya menghabiskan 13 jam menganalisis bug yang diajukan oleh QA untuk rilis kandidat awal dan 3 jam mengimplementasikan perbaikan. Setelah itu, saya menghabiskan 11 jam merokok untuk menguji perubahan yang saya buat pada pelepasan kandidat awal. Setelah itu...

Bagaimanapun data tentang upaya perbaikan dan perbaikan bug cukup mudah untuk dikomunikasikan dalam pengalaman saya.

Untuk rilis terbaru, kami menghabiskan sekitar 90% waktu untuk menguji dan memperbaiki bug regresi. Untuk rilis berikutnya, sarankan untuk mengalokasikan beberapa upaya untuk mendapatkan nilai ini hingga 60-70%.

Kata peringatan lainnya. Data seperti 90% di atas dapat diartikan tidak hanya sebagai indikasi hutang teknis, tetapi juga (kejutan kejutan) sebagai indikasi seseorang tidak cukup mahir dalam pemrograman / teknologi tertentu. "Anda membuat terlalu banyak bug dalam kode Anda".

Jika ada risiko data disalahtafsirkan dengan cara itu, ada baiknya untuk memiliki data referensi tambahan tentang sesuatu yang cenderung tidak dibandingkan dengan WTF .

Katakanlah jika ada dua komponen / aplikasi serupa yang dikelola oleh pengembang yang sama, rilis pertama pada "tingkat pemborosan" sekitar 50% dan kedua pada 80-90, ini membuat kasus yang cukup kuat dalam mendukung kedua menjadi subjek utang teknis.

Jika ada penguji yang berdedikasi dalam proyek ini, mereka juga dapat berkontribusi untuk evaluasi data yang lebih objektif. Seperti yang saya sebutkan dalam jawaban lain ,

Dengan penguji, Anda meminta seseorang untuk membackup pemahaman Anda tentang masalah desain. Ketika hanya ada pengembang yang mengeluh tentang kualitas kode , ini sering terdengar seperti WTF subyektif dari balik pintu tertutup .

Tetapi ketika hal ini digaungkan oleh orang QA yang mengatakan sesuatu seperti component Amemiliki 100 bug regresi untuk 10 fitur baru, berbeda dengan component Byang memiliki 10 bug regresi per 20 fitur baru , komunikasi tiba-tiba berubah menjadi permainan lain secara keseluruhan.

— agas
sumber

2

Saya suka jawaban ini banyak. Dengan departemen QA khusus, rasio cacat regresi terhadap cacat baru sangat mudah untuk dihitung dan pasti bisa memberi tahu Anda banyak tentang utang teknis.

— Erik Dietrich

4

Saya pikir pertanyaannya adalah berapa biayanya untuk "membeli kembali" hutang teknis Anda - yaitu, berapa banyak pekerjaan untuk memperbaikinya? Nah, itu tergantung pada tim untuk mencari tahu.

Selama perencanaan sprint, saya meminta tim untuk memperkirakan kompleksitas memperbaiki item utang teknis dengan cara yang sama mereka akan memperkirakan kompleksitas cerita pengguna. Pada saat itu, ini adalah permainan negosiasi antara tim dan pemilik produk untuk menentukan utang teknis mana yang memiliki prioritas cukup tinggi untuk dilakukan dalam sprint saat ini (mengganti cerita pengguna sebenarnya) dan apa yang bisa menunggu.

Jika Anda tidak melakukan scrum, saya akan tetap pada premis saya - hutang teknis harus diukur dengan biaya pemulihan.

— Matthew Flynn
sumber

Jadi, dalam konteks poin cerita, apakah adil untuk mengatakan bahwa Anda dapat menambahkan beberapa poin ke setiap cerita jika ada utang teknis tingkat tinggi yang diwakili oleh area kode yang terkena dampak? Artinya, jika cerita X melibatkan penambahan ke elemen kode Y, yang hanya mengerikan, Anda menempelkan beberapa poin pada cerita secara khusus karena sifat dari Y? Dan jumlah poin itu sama atau terkait dengan jumlah poin untuk melakukan perbaikan yang Anda sebutkan memperkirakan?

— Erik Dietrich

1

@Erik Dietrich - Nah, TD pasti menambah kompleksitas untuk solusinya. Kesulitannya mungkin bahwa memperbaiki sedikit demi sedikit TD mungkin lebih mahal daripada solusi grosir. Jadi mungkin Anda memiliki 3 cerita yang akan dinilai masing-masing 5 jika TD dihilangkan, tetapi masing-masing 8 dengan utang di tempat - sehingga menambah hingga 9 poin TD. Tugas untuk memperbaiki TD secara keseluruhan (terlepas dari cerita) mungkin benar-benar menjadi 8. Jadi Anda dapat berargumen bahwa solusi grosir biaya kurang (8) daripada sedikit demi sedikit (9). Ini akan menjadi bagian dari negosiasi

— Matius Flynn

Itu masuk akal. Dan, tentu saja, apa yang saya cari adalah membuat (agak) kasus objektif untuk mengatakan sesuatu seperti "dalam satu tahun, kita dapat mengembangkan X fitur baru jika kita terus membajak, tetapi X + Y fitur baru jika kita bayar sebagian hutang teknis ini ".

— Erik Dietrich

2

Ada platform yang cukup kuat di luar sana yang disebut CASTuntuk mencari utang teknis dalam aplikasi besar. Kami menggunakannya pada proyek di mana kami mengambil alih perangkat tambahan besar untuk sistem warisan. Itu tidak memberi tahu Anda apa yang ada di kepala orang-orang yang menulis kode, tetapi memeriksa kode dan menemukan cacat kode dan arsitektur, kemudian menghitung untuk utang teknis jika Anda mau. Penggunaan nyata dalam melihat ini, bukan $ jumlah tetapi daftar masalah yang sudah ada dalam kode. Ini memberitahu Anda tentang sebagian dari hutang teknis yang Anda miliki (jadi saya tidak setuju dengan beberapa jawaban di atas). Ada beberapa hutang teknis yang murni berbasis desain dan itu sangat subjektif - seperti pornografi - Anda tahu ketika Anda melihatnya dan mengetahui konteksnya. Saya berpendapat apakah itu utang "teknis". Ada beberapa hutang teknis yang murni dalam implementasi dan saya percaya bahwa '

— Leonhard
sumber

Saya membagikan pertanyaan ini di twitter, dan seseorang merespons berbicara tentang CAST. Saya tidak begitu jelas tentang apa yang dilakukannya setelah memeriksa situs web mereka. Apakah ada freebie atau versi demo untuk mengambil test drive?

— Erik Dietrich

2

Berikut ini adalah Webinar dari MIT yang menjelaskan penelitian tentang utang teknis dalam sistem perangkat lunak besar: http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

Para penulis menulis kode untuk menganalisis proyek dan mengeluarkan metrik 'kompleksitas arsitektur'. Metrik ini terbukti memiliki hubungan yang kuat dengan kepadatan cacat, produktivitas pengembang, dan pergantian staf pengembangan.

Pekerjaan yang dijelaskan dalam Webinar dibangun berdasarkan penelitian modularitas yang dilakukan oleh Alan MacCormack dan Carliss Baldwin di Harvard Business School. Saya akan melihat surat-surat mereka juga. 'Biaya propagasi' mereka mungkin apa yang Anda cari.

— pengguna94203
sumber

1

Saya akan mengatakan metrik kode standar dapat digunakan sebagai tampilan relatif tingkat tinggi dari hutang teknis. VS Ultimate mencakup Penganalisis Kode yang akan memberi Anda "Indeks Maintainability" berdasarkan Kompleksitas Siklus, Kopling, LoC, dan Kedalaman Warisan. Anda dapat menyelam ke titik masalah dan melihat detail (turun ke tingkat fungsi). Saya hanya menjalankannya di proyek saya dan skor terendah yang kami dapatkan adalah 69 pada paket Data kami (mengkonfigurasi dan menginisialisasi EF) dan Test Suite kami. Yang lainnya 90 atau lebih. Ada alat lain yang akan memberi Anda lebih banyak metrik seperti yang dibahas dalam PPP Paman Bob

— Michael Brown
sumber

Jadi, katakan Anda memiliki sesuatu yang tidak ada dalam paket uji atau paket data yang skornya di bawah 90. Apakah Anda memiliki ambang numerik di sana di mana Anda berkata, "baiklah, itu tidak cukup baik dan kami akan melakukan refactor"? Atau, apakah Anda menggunakan informasi ini untuk membuat kasus ini kepada manajemen atau pemangku kepentingan bahwa refactoring diperlukan? Yaitu, apakah manajer / pemangku kepentingan peduli dengan indeks pemeliharaan Microsoft, atau apakah Anda menyajikan informasi itu dengan cara lain? Atau, apakah Anda tidak menyajikannya dan dengan diam-diam memperbaiki masalah Anda sendiri?

— Erik Dietrich

Saya suka pertanyaan itu. Jawaban saya akan selalu bahwa menulis kode terbaik yang Anda bisa bukanlah sesuatu yang Anda minta izin untuk lakukan. Saya menggunakan apa yang Paman Bob sebut "aturan boyscout" (selalu meninggalkan kode dalam kondisi yang lebih baik daripada ketika Anda tiba) dan saya sebut refactoring oportunistik. Idenya adalah bahwa ketika Anda harus memodifikasi kode yang ada, luangkan waktu untuk a) menutupinya dalam unit test b) refactor menjadi lebih bersih. Michael Feathers Bekerja Efektif dengan Legacy Code menyediakan beberapa panduan untuk melakukan ini.

— Michael Brown

@ Mike-Itu akan membuat Anda dipecat di banyak lingkungan pengembangan di mana kontrol ketat dari semua perubahan kode dilacak dan dimonitor. Terutama jika peningkatan Anda yang tampaknya tidak bersalah yang tidak seorang pun memberitahu Anda untuk mengoreksi akhirnya merusak sesuatu yang dulu berhasil.

— Dunk

Catatan saya tidak mengatakan menyelam dan mau tidak mau membersihkan kode. Saya berkata untuk membersihkan kode yang sudah Anda kerjakan. Saya juga bekerja dengan kode yang sangat diatur (ditugaskan item kerja, harus memberikan daftar perubahan yang dibuat untuk menangani item kerja untuk persetujuan, melakukan perubahan yang disetujui ). 9/10 kali menjelaskan refactoring dalam permintaan perubahan akan menghasilkan persetujuan.

— Michael Brown

0

Saya tidak akan menganggap utang teknis sebagai dolar di mana Anda memerlukan model mewah untuk menghitungnya. Saya akan menganggapnya sebagai bantuan. Jika seseorang membantu Anda dan Anda cenderung lupa, tuliskan. Saat Anda mengambil jalan pintas, tuliskan. Ini membantu Anda mengingat, dan lebih banyak impoten memaksa Anda untuk mengakuinya. Tidak diperlukan alat mewah. Notepad atau Ecxel dapat melakukan triknya.

— MathAttack
sumber

2

Dari perspektif realpolitik, saya berpendapat bahwa orang yang paling berkeinginan untuk melakukan kejahatan jangka panjang untuk hasil jangka pendek mungkin juga orang-orang yang paling tidak mungkin mendokumentasikan keputusan mereka. Jadi, saya setuju dengan ide Anda secara teori, tapi saya pikir serial "permintaan pemohon" akan menjadi yang paling tidak mungkin untuk melacak keseimbangan bantuan.

— Erik Dietrich

@ErikDietrich - Saya setuju. Dan pelaku pelanggaran serial yang lebih buruk bahkan tidak tahu mereka menambah hutang mereka. (Mirip dengan pelaku kartu kredit terburuk yang menghancurkan peringkat kredit mereka.) Tetapi titik awalnya mengasumsikan keinginan untuk mengukur, dan sulit bagi yang bukan penulis untuk mengukurnya. Anda tidak tahu di mana kotoran itu kecuali itu anjing Anda, atau Anda kebetulan masuk ke dalamnya.

— MathAttack

0

Saya bekerja untuk perusahaan yang mencari tahu persis ini. Di bawah ini adalah 3 metrik yang dapat ditindaklanjuti yang kami sarankan untuk dilihat saat menangani utang teknis. Untuk informasi lebih lanjut tentang "bagaimana" dan "kapan" untuk melacaknya, kami mengumpulkan artikel ringkasan 3 Metrik untuk Memahami dan Menangani Hutang Teknis .

Apa yang kamu pikirkan? Senang menjawab pertanyaan dan lapar mendengar tanggapan Anda :).

Kepemilikan untuk mencegah cacat & utang teknologi yang tidak diinginkan

Kepemilikan adalah indikator utama kesehatan teknik.

Bagian-bagian basis kode yang menerima kontribusi dari banyak orang menumpuk cruft dari waktu ke waktu, sementara mereka yang menerima kontribusi dari lebih sedikit orang cenderung berada dalam keadaan yang lebih baik. Lebih mudah untuk mempertahankan standar tinggi dalam kelompok ketat yang memiliki informasi tentang bagian basis kode mereka.

Ini memberikan beberapa kekuatan prediksi: bagian-bagian kode basis yang dimiliki secara lemah cenderung menumpuk hutang seiring waktu dan menjadi semakin sulit untuk diajak bekerja sama. Khususnya, kemungkinan utang tidak diambil secara tidak sengaja , hanya sebagai efek samping dari informasi yang tidak lengkap dan kepemilikan yang dilemahkan terhadap kualitas kode.

Ini agak analog dengan tragedi milik bersama .

Kohesi untuk meningkatkan arsitektur

Kohesi adalah indikator tambahan komponen yang terdefinisi dengan baik.

Kohesi dan mitranya, kopling, telah lama dikenal sebagai konsep penting untuk fokus ketika merancang perangkat lunak.

Kode dikatakan memiliki kohesi yang tinggi ketika sebagian besar elemennya bersatu. Kohesi tinggi umumnya lebih disukai karena itu terkait dengan rawatan, penggunaan kembali, dan ketahanan. Kohesi tinggi dan sambungan longgar cenderung berjalan seiring.

Selain dikaitkan dengan kode yang lebih dapat digunakan kembali dan dipelihara, kohesi yang tinggi juga meminimalkan jumlah orang yang perlu terlibat untuk memodifikasi bagian tertentu dari basis kode yang meningkatkan produktivitas.

Churn untuk mengidentifikasi area masalah

Churn (aktivitas berulang) membantu mengidentifikasi dan memberi peringkat area-area yang sudah matang untuk refactoring dalam sistem yang sedang tumbuh.

Seiring pertumbuhan sistem, pengembang semakin sulit memahami arsitektur mereka. Jika pengembang harus memodifikasi banyak bagian basis kode untuk memberikan fitur baru, akan sulit bagi mereka untuk menghindari memperkenalkan efek samping yang mengarah ke bug, dan mereka akan kurang produktif karena mereka perlu membiasakan diri dengan lebih banyak elemen dan konsep.

Inilah sebabnya mengapa penting untuk mengusahakan tanggung jawab tunggal untuk menciptakan sistem yang lebih stabil dan menghindari konsekuensi yang tidak diinginkan. Sementara beberapa file adalah hub arsitektur dan tetap aktif ketika fitur baru ditambahkan, adalah ide yang baik untuk menulis kode dengan cara yang membuat penutupan file, dan dengan ketat meninjau, menguji, dan area pengadukan QA.

Churn memunculkan file-file aktif ini sehingga Anda dapat memutuskan apakah mereka harus dipecah untuk mengurangi area permukaan perubahan dalam basis kode Anda.

— Stefanie
sumber

-1

Jika Anda memiliki riwayat yang baik melalui bugtracker atau semacam perangkat lunak tangkas Anda dapat membuatnya tetap sederhana. Waktu yang dihabiskan untuk menyelesaikan tugas-tugas dasar. Juga, keandalan estimasi ketika proyek masih muda vs sekarang.

— Erik Reppen
sumber

Bagaimana saya bisa mengukur jumlah utang teknis yang ada dalam suatu proyek?

Kepemilikan untuk mencegah cacat & utang teknologi yang tidak diinginkan

Kohesi untuk meningkatkan arsitektur

Churn untuk mengidentifikasi area masalah