Ini artikel tentang utang teknis memiliki beberapa poin yang baik, termasuk:

Bekerja pada "masalah teknis" bekerja paling baik ketika didorong oleh cerita. Basis kode mungkin membutuhkan pekerjaan di mana-mana, tetapi imbalannya akan diterima hanya di mana kode akan dikerjakan untuk alasan yang dihadapi pengguna. Jika tidak ada cerita yang akan melewati area crufty, mengerjakannya sebagian besar akan sia-sia.

Oleh karena itu, saya lebih suka pendekatan mengambil cerita seperti biasa (tapi mungkin lebih sedikit dari mereka), dan mengikuti "aturan pramuka" meninggalkan perkemahan lebih baik daripada yang Anda temukan. Dengan kata lain, ke mana pun cerita menuntun kita, mari kita tulis lebih banyak tes, mari kita refactor lebih agresif.

Pendekatan ini setidaknya memiliki kelebihan-kelebihan ini:

• mempertahankan alur cerita yang "paling masuk akal";
• memberikan bantuan dari semua talenta tim;
• menyediakan bagi seluruh tim untuk belajar cara menjaga kode tetap bersih;
• memfokuskan perbaikan tepat di tempat yang dibutuhkan;
• tidak menyia-nyiakan perbaikan yang "mungkin" dibutuhkan;

Saya telah melihat kualitas kode memiliki efek yang sangat besar pada produktivitas jangka panjang, jadi saya percaya bahwa utang teknis harus dijaga. Saya pikir posting di atas masuk akal, tetapi saya tidak begitu yakin tentang dua poin terakhir. Saya tertarik untuk mencari tahu pengalaman nyata manfaat dari membersihkan utang teknis, bahkan jika itu tidak terkait dengan cerita pengguna.

Apa manfaat positif yang Anda lihat dari membersihkan basis kode Anda dan membebaskan diri dari hutang teknis? Metode apa yang Anda gunakan untuk menyelesaikan pekerjaan?

Saya bisa memberi Anda satu contoh dari pengalaman saya.

Sekitar 10 atau 12 tahun yang lalu saya mewarisi aplikasi dari tim pengembang yang akhirnya meninggalkan perusahaan (terlalu lama untuk masuk ke sini ...). Sistem ini adalah sistem pembuatan laporan middleware besar yang dikembangkan di rumah. Itu berjalan setiap minggu malam dan menghasilkan sekitar 2 lusin laporan Excel untuk eksekutif senior perusahaan Fortune 500. Ketika saya mewarisinya, butuh sekitar 5-6 jam untuk berjalan dan selama minggu apa pun akan gagal setidaknya 2 malam.

Saya bukan seorang kemping yang senang diberi kekacauan ini.

Awalnya rencanaku hanyalah menghentikan pendarahan dan memperbaiki penyebab utama kegagalan. Setelah saya menjadi lebih nyaman dengan basis kode, saya mulai mencari tempat di mana saya bisa memperbaiki dan menambah stabilitas dan kinerja. Selama kurang lebih 2 tahun, saya membuat banyak sekali perubahan pada sistem. Kami menghentikan sistem itu beberapa tahun yang lalu dan pada saat itu seluruh proses membutuhkan waktu 45 menit untuk berjalan dan tidak menghasilkan masalah apa pun selama bertahun-tahun.

Banyak pekerjaan yang harus dilakukan untuk membayar utang teknis tetapi itu layak, layak untuk dilakukan. Itu bagus tidak mendapatkan panggilan telepon di tengah malam bahwa sistem gagal. Sangat menyenangkan datang ke kantor di monring dan tidak melihat apa pun kecuali kabar baik di log.

(Selain ... Setelah beberapa tahun saya bertemu dengan salah satu pengembang utama sistem ini. Dia bertanya kepada saya bagaimana kinerjanya dan saya mengatakan kepadanya betapa buruknya sistem itu. Dia benar-benar meminta maaf dan mengatakan kepada saya bahwa dia tahu itu akan terjadi. sedikit untuk mendukung setelah dia pergi dan berharap dia melakukan pekerjaan yang lebih baik di sana).

Sudah pengalaman saya bahwa manfaat pembersihan kode paling terlihat ketika saya harus mempertahankan kode di mana pembersihan belum dilakukan. Di mana pembersihan telah dilakukan, perubahan saya terdiri dari membaca kode, melihat satu atau dua tempat yang perlu diubah, dan pergi dari sana. Jika pembersihan belum dilakukan, tambahkan langkah awal membaca kode beberapa kali dan cobalah mencari tahu apa yang dipikirkan penulis (kadang-kadang saya) ketika ia menulisnya.

menghilangkan utang teknis menghasilkan lebih sedikit dukungan teknis dan landasan yang lebih baik untuk peningkatan

selalu

Satu pengalaman yang saya miliki adalah ketika saya mengelola tim Kinerja Situs di perusahaan saya sebelumnya. Setiap malam, untuk periode satu jam hingga dua jam, situs web yang dipantau oleh tim saya akan turun di bawah ambang batas kinerja yang dapat diterima karena informasi penggarukan bot dari situs dengan cepat. Langkah-langkah yang diambil tim untuk mengatasi ini terdiri dari masuk ke sistem admin manual dan memblokir alamat IP yang menyebabkan masalah. Tak perlu dikatakan, ini menghabiskan satu anggota tim jam tidur hampir setiap malam. Saya perhatikan apa yang terjadi dan saya mengambil sendiri BlackBerry on-call selama beberapa hari untuk melihat seberapa buruknya dan memberi istirahat pada tim saya.

Setelah beberapa hari, saya langsung pergi ke pemilik bisnis tim dan memberi tahu mereka bahwa jika kami tidak menerapkan sistem pemblokiran otomatis sehingga bot akan memiliki waktu yang jauh lebih sulit mempengaruhi kinerja situs, kami kemungkinan akan kehilangan beberapa jika tidak semua anggota tim karena kelelahan dan kelelahan. Mereka setuju, dan kami menerapkan sistem yang memungkinkan kami tidur di malam hari. Pemilik bisnis mengerti bahwa biaya beberapa hari atau satu minggu pengembangan minimal dibandingkan dengan biaya mempekerjakan / melatih insinyur baru.

Mengenai dua poin terakhir: Saya mengerti dari mana asalnya , seperti dijelaskan dalam posting aslinya :

Atau, apakah mungkin untuk menetapkan kembali beberapa pengembang untuk menyelesaikan masalah teknis ini, sementara tim lainnya melanjutkan hal-hal yang berorientasi pengguna? Ini mungkin memengaruhi kecepatan tim, tetapi jadi apa?

"Jadi apa" yang sama: pemilik produk dan orang-orang dari sisi bisnis menjadi tidak bahagia. Dan ketika Momma tidak bahagia, semua orang tidak bahagia.

Namun, batas antara apa yang harus dilakukan dan apa yang mungkin dilakukan cukup samar. Yang dihadapi pengguna sangat luas, dan mencakup kinerja dan kemunculan kesalahan. Namun dalam beberapa kasus, masalah mendasar dari kinerja yang buruk dan tingginya tingkat kesalahan terletak lebih dalam pada kode. Untuk mengatakannya dalam kata-katanya: sebuah cerita mungkin tidak melewati area crufty, tetapi area crufty itu dapat menyembunyikan beberapa hal buruk yang menyerang cerita di jalan yang dibersihkan di sebelahnya.

Hal-hal yang tidak mempengaruhi kinerja keseluruhan kurang menarik untuk dibersihkan, tetapi orang harus mengevaluasi dengan sangat hati-hati pengaruh poin-poin itu. Lebih sering daripada tidak mereka memiliki pengaruh tidak langsung yang bisa sangat besar.

Manfaat terbesar yang akan diterima organisasi sebagai akibat dari membayar hutang teknis adalah menghindari bunga majemuk. Ada sebuah contoh dalam entri blog di bawah ini yang menunjukkan bagaimana jumlah pokok utang pada utang teknis naik dari $ 160 ribu menjadi $ 430 ribu hanya dalam lima tahun. Butuh programmer penuh waktu yang didedikasikan untuk melayani jumlah hutang itu. Itu akan membantu menempatkannya dalam perspektif bagi para pembuat keputusan!

Dari blog.acrowire.com .