Karma buruk dalam pemrograman. Apa itu utang teknis dan bagaimana cara memperbaikinya

Hutang teknis. Kebanyakan programmer yang aktif bekerja di bidang keahliannya harus berurusan dengan istilah ini. Bagi banyak orang, penyebutannya bahkan bisa menyebabkan sakit kepala, serta ketidaknyamanan di bagian tubuh lain yang muncul setiap kali Anda menghadapi hutang teknis saat mengerjakan sebuah proyek. Oleh karena itu, hari ini kita akan membahas tentang utang teknis (technical debt/TD): apa itu utang teknis, tampilannya, jenis utang teknis apa saja, dan cara mengelolanya secara efektif.

Apa itu utang teknis?

Namun, pertama-tama mari kita pahami terminologinya. Hutang teknis adalah metafora rekayasa perangkat lunak untuk masalah yang terakumulasi dalam kode atau arsitektur perangkat lunak karena pengabaian kualitas dalam pengembangan perangkat lunak dan menyebabkan tambahan biaya tenaga kerja di masa depan. Ini adalah definisi utang teknis yang diberikan oleh Wikipedia. Sederhananya, utang teknis adalah hasil dari penerapan solusi pembangunan yang disederhanakan dan bersifat jangka pendek, yang kemudian menyebabkan peningkatan (kecuali, tentu saja, utang tersebut “dilunasi”) biaya uang dan waktu untuk perbaikan selanjutnya. menulis ulang kode atau mempertahankan produk dalam bentuk yang ada. Dalam dunia pemrogram biasa, utang teknis adalah salah satu jenis karma negatif, demotivasi, dan sumber kesedihan yang muncul sebagai akibat dari kode yang buruk, penggunaan kruk, dan solusi “sementara” (tetapi sebenarnya tidak terlalu) yang membantu memecahkan permasalahan jangka pendek dan mempercepat pembangunan “secara kredit”, yaitu dengan mengorbankan semakin banyaknya permasalahan di masa depan. Dalam industri TI, utang teknis merupakan masalah yang cukup serius. Menurut sebuah penelitian baru-baru ini , perusahaan di seluruh dunia setiap tahunnya menghabiskan lebih dari $85 miliar per tahun hanya untuk memperbaiki kode yang buruk. Secara total, sekitar $300 miliar per tahun dihabiskan untuk proyek-proyek yang berkaitan dengan dukungan sistem yang ketinggalan jaman dan perangkat lunak yang “buruk”. Ini adalah angka yang signifikan. Para peneliti memperkirakan bahwa jika upaya semua pengembang yang menangani utang teknis dan konsekuensinya dipusatkan kembali pada pembangunan yang “benar”, hal ini akan menambah sekitar $3 triliun PDB global selama dekade ini.

Alasan penampilan

Perlu dipahami bahwa utang teknis tidak selalu buruk, sama halnya dengan berhutang finansial bisa berdampak positif jika, misalnya, Anda mengambil pinjaman untuk mengembangkan bisnis (atau meluncurkan startup ). Dalam kasus TD, hal ini dapat diterima bagi perusahaan yang berkembang pesat yang perlu merilis produk atau layanan baru dengan cepat dan sering untuk mengevaluasi keberhasilan mereka dan mempelajari kebutuhan pasar, atau dengan cepat menangkap ceruk pasar baru, misalnya. Namun, seperti halnya utang finansial, Anda harus berhati-hati dengan utang teknis dan mengetahui cara mengelolanya, jika tidak, masalah serius dapat timbul. Semakin banyak utang teknis yang terakumulasi selama pengembangan produk perangkat lunak, semakin besar dampaknya terhadap perusahaan, memperlambat peluncuran rilis baru, menurunkan moral pembuat kode biasa yang bertanggung jawab atas “pemeliharaan” utang tersebut, dan meningkatkan biaya. , yang pada akhirnya malah dapat menghancurkan perusahaan. Alasan terjadinya utang teknis, selain keinginan mulia untuk menyelesaikan produk sesegera mungkin atau untuk menyenangkan pengguna dengan rilis baru, sering kali adalah manajemen produk yang buruk, tenggat waktu atau keterbatasan sumber daya yang tidak realistis, dan tentu saja, kemalasan pembuat kode. , ditambah dengan kualifikasi yang rendah dan kurangnya pemahaman terhadap prinsip-prinsip utama pembangunan, juga seringkali berkontribusi terhadap pertumbuhan utang. Seringkali pengembang sendiri sangat menyadari keberadaan dan pertumbuhan utang teknis yang konstan, namun tidak memiliki kekuatan yang cukup untuk mengubahnya, atau tidak dapat menyampaikan informasi kepada manajemen tentang adanya masalah tersebut dan pentingnya penyelesaiannya.

Klasifikasi

Seperti disebutkan di atas, utang teknis hadir dalam berbagai bentuk, dan karena definisi itu sendiri hanyalah sebuah metafora, berbagai jenis utang teknis dapat diklasifikasikan dengan cara yang berbeda. Secara khusus, Dag Liodden, salah satu pendiri dan CTO Tapad, yang dianggap sebagai salah satu pakar utang teknis dunia, dalam pidatonya di acara tahunan CTO Summit, mengusulkan untuk membagi utang teknis menjadi tiga jenis utama.

1. Hutang teknis yang disengaja.

   Hal ini muncul ketika pengembang dengan sengaja memilih bukan solusi terbaik, karena lebih mudah dan cepat untuk diterapkan, yang pada gilirannya akan membantu meluncurkan produk baru ke pasar dengan cepat.

   “Terkadang kami sengaja mengambil utang teknis untuk mengurangi waktu pengembangan. Jika Anda memutuskan untuk menempuh cara ini, pertimbangkan tidak hanya waktu yang akan Anda hemat selama pengembangan, namun juga waktu yang harus Anda habiskan nantinya untuk “melunasi” utang tersebut. Selain itu, pastikan para pemangku kepentingan [manajemen puncak perusahaan] sadar bahwa keputusan seperti itu pasti akan memperlambat peluncuran fungsi-fungsi lain di masa depan,” kata Dag Ljodden.

   Pendekatan untuk menyelesaikan utang teknis jenis ini

   Pakar menyarankan untuk mendokumentasikan kasus-kasus tersebut secara hati-hati agar dapat dikembalikan dan diperbaiki sebelum utang teknis ini hilang, sehingga menjadi bagian integral dari struktur proyek.

2. Hutang teknis yang tidak disengaja atau timbul dari arsitektur proyek yang sudah ketinggalan zaman.

   Selain itu, hutang teknis sering kali muncul seiring berjalannya waktu, karena kesalahan dan kekurangan pada tahap pembuatan arsitektur proyek. Seiring berkembangnya sistem dan perubahan persyaratan perangkat lunak, kesalahan desain menjadi lebih jelas, dan penambahan fitur baru memerlukan lebih banyak waktu dan usaha. Kualitas arsitektur proyek awal memainkan peran penting di sini - harus sederhana dan fungsional, sehingga akan lebih mudah untuk beradaptasi dengan perubahan.

   Pendekatan untuk menyelesaikan utang teknis jenis ini

   Untuk mencegah utang teknis jenis ini terakumulasi dan tidak melebihi tingkat kritis, Dag Llodden merekomendasikan pemfaktoran ulang secara rutin - kira-kira setiap dua tahun sekali, selama periode ketika sistem berada dalam kondisi stabil. Pimpinan tim dan manajer produk harus mengalokasikan waktu untuk “melunasi” jenis hutang teknis yang timbul karena arsitektur dan persyaratan proyek yang sering berubah.

3. Hutang teknis yang timbul seiring berjalannya waktu.

   Pakar tersebut menyebut utang teknis semacam itu “berumur panjang”. Ini terakumulasi seiring berjalannya waktu karena suatu komponen atau sistem secara bertahap menjadi lebih kompleks karena banyak perubahan yang terus ditambahkan. Hal ini sering kali diperburuk jika orang yang berbeda mengerjakan sistem pada tahapan yang berbeda dan tidak sepenuhnya memahami arsitektur aslinya.

   Pendekatan untuk menyelesaikan utang teknis jenis ini

   Ini adalah satu-satunya dari tiga jenis utang teknis yang harus Anda coba hindari secara berkelanjutan melalui refactoring rutin, kata pakar. Idealnya, tim pengembangan harus meluangkan waktu untuk memahami secara menyeluruh arsitektur sistem yang sedang mereka kerjakan, meskipun sistem tersebut awalnya dibuat oleh orang lain. Memahami sistem akan memungkinkan Anda untuk secara bertahap meningkatkan dan memperbaiki kode yang buruk tanpa membawa proyek ke tahap “busuk”.

Solusi Manajemen Utang Teknis

Ada banyak pilihan untuk mengelola utang teknis secara efektif, namun semua ahli sepakat bahwa hal ini harus dilakukan, karena utang teknis merupakan bagian integral dari hampir semua pembangunan, dan perusahaan yang mengabaikannya akan selalu menghadapi masalah pada tahap selanjutnya. Berikut beberapa solusi dan pendekatan efektif dalam mengelola utang teknis untuk tim pengembangan.

1. Alokasikan persentase tetap dari waktu kerja Anda untuk mengerjakan utang teknis.

   Hal tentang utang teknis adalah tidak pernah ada waktu untuk menghilangkannya (karena selalu ada tugas dengan prioritas lebih tinggi) kecuali Anda melakukannya dengan sengaja. Oleh karena itu, solusi yang baik adalah dengan mengalokasikan persentase waktu kerja tertentu untuk tujuan ini - sekitar 20-25%.

   Hal ini dapat dilakukan dengan berbagai cara.

2. Kerjakan hutang teknis 1 hari seminggu

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

Terakhir, saya ingin menekankan sekali lagi bahwa tidak mungkin dilakukan tanpa hutang teknis dalam pengembangan perangkat lunak, karena mereka merupakan bagian integral dari pengembangan. Namun meskipun bersifat teknis, TD masih menjadi permasalahan yang disebabkan oleh faktor manusia dalam pembangunan. Dan meskipun Anda tidak dapat melakukannya tanpanya sepenuhnya, jumlah hutang teknis dapat dikurangi sebanyak mungkin jika Anda menulis kode yang “bersih” dan melakukan pendekatan terhadap proses pengembangan dengan bertanggung jawab dan profesional. Inilah yang kami harapkan untuk semua orang!