Karma buruk dalam pengaturcaraan. Apakah hutang teknikal dan bagaimana untuk menyelesaikannya

Hutang teknikal. Kebanyakan pengaturcara yang aktif bekerja dalam kepakaran mereka perlu berurusan dengan istilah ini. Bagi kebanyakan orang, sebutannya malah boleh menyebabkan sakit kepala, serta ketidakselesaan di bahagian lain badan yang muncul apabila anda berurusan dengan hutang teknikal semasa menjalankan projek. Oleh itu, hari ini kita akan bercakap tentang hutang teknikal (TD): apakah itu, bagaimana ia muncul, jenis hutang teknikal yang ada, dan cara menguruskannya dengan berkesan.

Apakah hutang teknikal?

Walau bagaimanapun, mula-mula mari kita memahami istilah. Hutang teknikal ialah metafora kejuruteraan perisian untuk masalah terkumpul dalam kod perisian atau seni bina akibat pengabaian kualiti dalam pembangunan perisian dan menyebabkan kos buruh tambahan pada masa hadapan. Ini adalah definisi hutang teknikal yang diberikan oleh Wikipedia. Ringkasnya, hutang teknikal adalah hasil daripada menggunakan penyelesaian yang dipermudahkan dan jangka pendek dalam pembangunan, yang kemudiannya membawa kepada kos wang dan masa yang semakin meningkat (melainkan, sudah tentu, hutang itu "dibayar balik") untuk pemurnian berikutnya, menulis semula kod atau mengekalkan produk dalam bentuk sedia ada. Dalam dunia pengaturcara biasa, hutang teknikal adalah salah satu jenis karma negatif, penyahmotivasi dan sumber kesedihan yang datang sebagai pembalasan untuk kod buruk, penggunaan tongkat dan penyelesaian "sementara" (tetapi sebenarnya tidak terlalu) yang membantu menyelesaikan masalah jangka pendek dan mempercepatkan pembangunan "secara kredit," iaitu, dengan mengorbankan masalah yang semakin bertambah pada masa hadapan. Dalam industri IT, hutang teknikal adalah masalah yang agak serius. Menurut satu kajian baru-baru ini , syarikat di seluruh dunia setiap tahun membelanjakan lebih daripada $85 bilion setahun hanya untuk membetulkan kod buruk. Secara keseluruhan, kira-kira $300 bilion setahun dibelanjakan untuk projek yang berkaitan dengan menyokong sistem lapuk dan perisian "buruk". Ini adalah nombor penting. Penyelidik menganggarkan bahawa jika usaha semua pemaju yang bekerja dengan hutang teknikal dan akibatnya difokuskan semula pada pembangunan "betul", ia akan menambah kira-kira $3 trilion kepada KDNK global sepanjang dekad semasa.

Sebab penampilan

Perlu difahami bahawa hutang teknikal tidak selalunya sesuatu yang buruk, sama seperti masuk ke dalam hutang kewangan boleh menjadi positif jika, sebagai contoh, anda membuat pinjaman untuk membangunkan perniagaan (atau melancarkan permulaan ). Dalam kes TD, ini boleh diterima untuk syarikat yang berkembang pesat yang perlu mengeluarkan produk atau perkhidmatan baharu dengan cepat dan kerap untuk menilai kejayaan mereka dan mengkaji keperluan pasaran, atau cepat menangkap niche baharu, sebagai contoh. Tetapi, seperti hutang kewangan, anda perlu berhati-hati dengan hutang teknikal dan tahu cara menguruskannya, jika tidak masalah serius boleh timbul. Lebih banyak hutang teknikal terkumpul semasa pembangunan produk perisian, lebih banyak ia boleh menjejaskan syarikat, memperlahankan pengeluaran keluaran baharu, menurunkan semangat pengkod biasa yang bertanggungjawab untuk "penyelenggaraan" hutang tersebut, dan meningkatkan kos , yang akhirnya boleh memusnahkan syarikat . Sebab-sebab berlakunya hutang teknikal, sebagai tambahan kepada keinginan murni untuk menyelesaikan produk secepat mungkin atau untuk menggembirakan pengguna dengan keluaran baru, selalunya pengurusan produk yang lemah, tarikh akhir yang tidak realistik atau had sumber, dan sudah tentu, kemalasan coder. , ditambah pula dengan kelayakan yang rendah dan kekurangan pemahaman tentang prinsip pembangunan utama, juga sering menyumbang kepada pertumbuhan hutang. Selalunya berlaku bahawa pemaju sendiri menyedari kehadiran dan pertumbuhan berterusan hutang teknikal, tetapi tidak mempunyai kuasa yang cukup untuk mengubahnya, atau tidak dapat menyampaikan maklumat kepada pengurusan tentang kewujudan masalah sedemikian dan kepentingan menyelesaikannya.

Pengelasan

Seperti yang dinyatakan di atas, hutang teknikal datang dalam pelbagai bentuk, dan oleh kerana definisi itu sendiri hanyalah metafora, jenis hutang teknikal yang berbeza boleh diklasifikasikan dalam cara yang berbeza. Khususnya, Dag Liodden, pengasas bersama dan CTO Tapad, yang dianggap sebagai salah seorang pakar dunia mengenai hutang teknikal, semasa ucapan di acara tahunan CTO Summit, mencadangkan membahagikan hutang teknikal kepada tiga jenis utama.

1. Hutang teknikal yang disengajakan.

   Ia muncul dalam kes di mana pemaju sengaja tidak memilih penyelesaian terbaik, kerana ia lebih mudah dan lebih cepat untuk dilaksanakan, yang seterusnya, akan membantu dengan cepat mengeluarkan produk baharu ke pasaran.

   “Kadang-kadang kami sengaja mengambil hutang teknikal untuk mengurangkan masa pembangunan. Jika anda memutuskan untuk pergi ke laluan ini, pertimbangkan bukan sahaja masa yang anda akan simpan semasa pembangunan, tetapi juga masa yang anda perlu belanjakan kemudian untuk "membayar" hutang tersebut. Selain itu, pastikan pihak berkepentingan [pengurusan atasan syarikat] sedar bahawa keputusan sedemikian pasti akan melambatkan pelancaran fungsi lain pada masa hadapan,” kata Dag Ljodden.

   Pendekatan untuk menyelesaikan jenis hutang teknikal ini

   Pakar menasihatkan dengan berhati-hati mendokumentasikan kes sedemikian untuk kembali kepada mereka dan membetulkannya sebelum hutang teknikal ini hilang, menjadi sebahagian daripada struktur projek.

2. Tidak sengaja atau timbul daripada seni bina projek yang lapuk. Hutang teknikal.

   Juga, hutang teknikal sering timbul dari semasa ke semasa, disebabkan oleh kesilapan dan kekurangan pada peringkat mencipta seni bina projek. Apabila sistem berkembang dan keperluan perisian berubah, ralat reka bentuk menjadi lebih jelas dan menambah ciri baharu memerlukan lebih banyak masa dan usaha. Kualiti seni bina projek awal memainkan peranan penting di sini - ia mestilah mudah dan berfungsi, maka ia akan lebih mudah untuk menyesuaikan diri dengan perubahan.

   Pendekatan untuk menyelesaikan jenis hutang teknikal ini

   Untuk mengelakkan jenis hutang teknikal ini daripada terkumpul dan tidak melebihi tahap kritikal, Dag Llodden mengesyorkan pemfaktoran semula secara berkala - kira-kira sekali setiap dua tahun, semasa tempoh sistem berada dalam keadaan stabil. Ketua pasukan dan pengurus produk mesti memperuntukkan masa untuk "membayar" hutang teknikal jenis ini yang timbul disebabkan oleh seni bina dan keperluan yang kerap berubah untuk projek.

3. Hutang teknikal yang timbul dari semasa ke semasa.

   Pakar memanggil hutang teknikal sedemikian "lama reput." Ia terkumpul dari semasa ke semasa apabila komponen atau sistem secara beransur-ansur menjadi lebih kompleks disebabkan oleh banyak perubahan yang sentiasa ditambah. Ini sering menjadi lebih teruk jika orang yang berbeza bekerja pada sistem pada peringkat yang berbeza dan tidak memahami sepenuhnya seni bina asal.

   Pendekatan untuk menyelesaikan jenis hutang teknikal ini

   Ini adalah satu-satunya daripada tiga jenis hutang teknikal yang anda harus cuba elakkan secara berterusan melalui pemfaktoran semula biasa, kata pakar itu. Sebaik-baiknya, pasukan pembangunan harus meluangkan masa untuk memahami secara menyeluruh seni bina sistem yang sedang mereka kerjakan, walaupun ia pada asalnya dicipta oleh orang lain. Memahami sistem akan membolehkan anda menambah baik dan membetulkan kod buruk secara beransur-ansur tanpa membawa projek ke peringkat "reput".

Penyelesaian Pengurusan Hutang Teknikal

Terdapat banyak pilihan untuk menguruskan hutang teknikal dengan berkesan, tetapi semua pakar bersetuju bahawa ini mesti dilakukan, kerana hutang teknikal adalah sebahagian daripada hampir semua pembangunan, dan syarikat-syarikat yang mengabaikannya selalu menghadapi masalah pada peringkat kemudian. Berikut ialah beberapa penyelesaian dan pendekatan yang berkesan untuk menguruskan hutang teknikal untuk pasukan pembangunan.

1. Peruntukkan peratusan tetap masa kerja anda untuk menyelesaikan hutang teknikal.

   Perkara mengenai hutang teknikal ialah tidak ada masa untuk berusaha menghapuskannya (kerana sentiasa ada tugas keutamaan yang lebih tinggi) melainkan anda melakukannya dengan sengaja. Oleh itu, penyelesaian yang baik adalah untuk memperuntukkan peratusan tetap tertentu masa bekerja untuk tujuan ini - kira-kira 20-25%.

   Ini boleh dilakukan dengan cara yang berbeza.

2. Bekerja pada hutang teknikal 1 hari seminggu

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

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

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

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

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

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

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

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

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

Заключение

Akhir sekali, saya ingin menekankan sekali lagi bahawa adalah mustahil untuk dilakukan tanpa hutang teknikal dalam pembangunan perisian, kerana ia adalah sebahagian daripada pembangunan seperti itu. Walau bagaimanapun, walaupun sifat teknikalnya, TD masih menjadi masalah yang disebabkan oleh faktor manusia dalam pembangunan. Dan walaupun anda tidak akan dapat melakukannya tanpanya sepenuhnya, jumlah hutang teknikal boleh dikurangkan sebanyak mungkin jika anda menulis kod "bersih" dan mendekati proses pembangunan dengan bertanggungjawab dan profesional yang mungkin. Inilah yang kami harapkan untuk semua orang!