Karma ala ing pemrograman. Apa utang teknis lan carane ndandani

Utang teknis. Umume programer sing aktif ing spesialisasine kudu ngatasi istilah kasebut. Kanggo akeh, sebutan kasebut bisa uga nyebabake sirah, uga rasa ora nyaman ing bagean awak liyane sing katon nalika sampeyan ngatasi utang teknis nalika nggarap proyek. Mulane, dina iki kita bakal pirembagan bab technical utang (TD): apa iku, carane katon, apa jinis utang technical ana, lan carane ngatur iku èfèktif.

Apa utang teknis?

Nanging, pisanan ayo ngerti terminologi kasebut. Utang teknis minangka metafora rekayasa piranti lunak kanggo masalah sing dikumpulake ing kode piranti lunak utawa arsitektur amarga nglirwakake kualitas ing pangembangan piranti lunak lan nyebabake biaya tenaga kerja tambahan ing mangsa ngarep. Iki minangka definisi utang teknis sing diwenehake dening Wikipedia. Cukup, utang teknis minangka asil nglamar solusi sing disederhanakake lan jangka pendek ing pembangunan, sing banjur nyebabake tambah akeh (kajaba, mesthi, utang kasebut "dibayar") biaya dhuwit lan wektu kanggo panyulingan sabanjure, nulis maneh kode utawa njaga produk ing wangun sing wis ana. Ing jagad programer biasa, utang teknis minangka salah sawijining jinis karma negatif, demotivator lan sumber sumelang sing teka minangka retribusi kanggo kode ala, panggunaan kruk lan "sementara" (nanging nyatane ora banget) solusi sing mbantu ngatasi masalah jangka pendek lan nyepetake pembangunan "kredit," yaiku, kanthi biaya masalah sing saya tambah akeh ing mangsa ngarep. Ing industri IT, utang teknis minangka masalah sing cukup serius. Miturut salah sawijining panaliten anyar , perusahaan ing saindenging jagad saben taun mbuwang luwih saka $85 milyar saben taun mung kanggo ndandani kode sing ala. Secara total, kira-kira $ 300 milyar saben taun digunakake kanggo proyek sing ana gandhengane karo ndhukung sistem sing wis lawas lan piranti lunak "ala". Iki nomer pinunjul. Peneliti ngira yen upaya kabeh pangembang sing nggarap utang teknis lan akibate difokusake maneh ing pembangunan "tengen", bakal nambah babagan $ 3 triliun menyang PDB global sajrone dekade saiki.

Alasan kanggo katon

Perlu dimangerteni yen utang teknis ora mesthi dadi perkara sing ala, kayadene utang finansial bisa dadi positif yen, contone, sampeyan njupuk utang kanggo ngembangake bisnis (utawa miwiti wiwitan ). Ing kasus TD, iki bisa ditampa kanggo perusahaan sing berkembang kanthi cepet sing kudu ngeculake produk utawa layanan anyar kanthi cepet lan asring supaya bisa ngevaluasi sukses lan sinau kabutuhan pasar, utawa cepet nangkep ceruk anyar, contone. Nanging, kaya utang finansial, sampeyan kudu ati-ati karo utang teknis lan ngerti carane ngatur, yen masalah serius bisa muncul. Utang teknis sing luwih akeh akumulasi sajrone pangembangan produk piranti lunak, luwih akeh bisa mengaruhi perusahaan, nyuda rilis rilis anyar, nyuda moral coders biasa sing tanggung jawab kanggo "pangopènan" utang kasebut, lan nambah biaya. , sing pungkasane bisa ngrusak perusahaan. Alasan kanggo kedadeyan utang teknis, saliyane kepinginan mulia kanggo ngrampungake produk kasebut sanalika bisa utawa nyenengake pangguna kanthi rilis anyar, asring manajemen produk sing ora apik, tenggat wektu sing ora nyata utawa watesan sumber daya, lan mesthi, kesed coder. , ditambah karo kualifikasi kurang lan lack of pangerten saka prinsip pembangunan tombol, uga asring kontribusi kontribusi kanggo wutah saka utang. Asring kedadeyan yen para pangembang dhewe ngerti babagan anané lan tuwuhing utang teknis sing terus-terusan, nanging ora duwe kekuwatan sing cukup kanggo ngganti, utawa ora bisa ngirim informasi menyang manajemen babagan anane masalah kasebut lan pentinge ngrampungake.

Klasifikasi

Kaya kasebut ing ndhuwur, utang teknis teka ing macem-macem formulir, lan amarga definisi kasebut mung minangka metafora, macem-macem jinis utang teknis bisa diklasifikasikake kanthi cara sing beda-beda. Utamane, Dag Liodden, co-founder lan CTO saka Tapad, sing dianggep minangka salah sawijining ahli ing donya babagan utang teknis, sajrone pidato ing acara Summit CTO taunan, ngusulake mbagi utang teknis dadi telung jinis utama.

1. Utang teknis sing disengaja.

   Katon ing kasus ing ngendi pangembang kanthi sengaja ora milih solusi sing paling apik, amarga luwih gampang lan luwih cepet kanggo dileksanakake, sing bakal mbantu cepet ngeculake produk anyar menyang pasar.

   "Kadhangkala kita sengaja njupuk utang teknis kanggo nyuda wektu pangembangan. Yen sampeyan arep menyang rute iki, nimbang ora mung wektu sampeyan bakal nyimpen sak pembangunan, nanging uga wektu sampeyan kudu nglampahi mengko kanggo "mbayar mati" utang kuwi. Uga, priksa manawa para pemangku kepentingan [manajemen ndhuwur perusahaan] ngerti manawa keputusan kasebut mesthi bakal nyuda peluncuran fungsi liyane ing mangsa ngarep, "ujare Dag Ljodden.

   Pendekatan kanggo ngrampungake utang teknis iki

   Pakar kasebut menehi saran kanthi tliti ndokumentasikake kasus kasebut supaya bisa bali lan mbenerake sadurunge utang teknis iki ilang, dadi bagean integral saka struktur proyek.

2. Sengaja utawa njedhul saka arsitektur project outdated. Utang technical.

   Uga, utang teknis asring muncul saka wektu, amarga kesalahan lan kekurangan ing tahap nggawe arsitektur proyek. Nalika sistem berkembang lan syarat piranti lunak diganti, kesalahan desain dadi luwih jelas lan nambah fitur anyar mbutuhake wektu lan gaweyan luwih akeh. Kualitas arsitektur proyek awal nduweni peran penting ing kene - kudu gampang lan fungsional, mula bakal luwih gampang adaptasi karo owah-owahan.

   Pendekatan kanggo ngrampungake utang teknis iki

   Kanggo nyegah jinis utang teknis saka akumulasi lan ora ngluwihi tingkat kritis, Dag Llodden nyaranake refactoring ajeg - kira-kira sapisan saben rong taun, sak periode nalika sistem ing negara stabil. Pimpinan tim lan manajer produk kudu nyedhiyakake wektu kanggo "mbayar" jinis utang teknis sing muncul amarga arsitektur lan syarat sing kerep diganti kanggo proyek kasebut.

3. Utang teknis sing muncul liwat wektu.

   Pakar kasebut nyebat utang teknis kasebut "bosok suwe." Iku accumulates liwat wektu minangka komponen utawa sistem mboko sithik dadi luwih Komplek amarga akeh owah-owahan sing terus-terusan ditambahake. Iki asring diperparah yen wong sing beda-beda nggarap sistem ing tahapan sing beda-beda lan ora ngerti arsitektur asline.

   Pendekatan kanggo ngrampungake utang teknis iki

   Iki mung siji saka telung jinis utang teknis sing kudu dicegah terus-terusan liwat refactoring biasa, ujare ahli. Saenipun, tim pangembang kudu njupuk wektu kanggo mangerteni arsitektur sistem sing lagi ditindakake, sanajan asline digawe dening wong liya. Ngerteni sistem kasebut bakal ngidini sampeyan nambah lan mbenerake kode sing ala tanpa nggawa proyek kasebut menyang tahap "rotting."

Solusi Manajemen Utang Teknis

Ana akeh opsi kanggo èfèktif ngatur utang technical, nanging kabeh ahli setuju sing iki kudu rampung, wiwit utang technical minangka bagéan integral saka meh wae pembangunan, lan perusahaan sing nglirwakake iku tansah ngadhepi masalah ing tahap mengko. Mangkene sawetara solusi lan pendekatan sing efektif kanggo ngatur utang teknis kanggo tim pangembangan.

1. Alokasi persentase tetep wektu kerja kanggo nggarap utang teknis.

   Babagan babagan utang teknis yaiku ora ana wektu kanggo ngilangi (amarga ana tugas prioritas sing luwih dhuwur) kajaba sampeyan nindakake kanthi sengaja. Mulane, solusi sing apik bakal nyedhiyakake persentase tetep tartamtu saka wektu kerja kanggo tujuan kasebut - kira-kira 20-25%.

   Iki bisa ditindakake kanthi cara sing beda-beda.

2. Nggarap utang teknis 1 dina seminggu

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

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

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

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

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

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

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

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

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

Заключение

Pungkasan, aku pengin nandheske maneh yen ora bisa ditindakake tanpa utang teknis ing pangembangan piranti lunak, amarga minangka bagean integral saka pangembangan kasebut. Nanging, senadyan alam teknis, TD isih dadi masalah sing disebabake dening faktor manungsa ing pembangunan. Lan sanajan sampeyan ora bakal bisa nindakake tanpa rampung, jumlah utang teknis bisa dikurangi sabisa yen sampeyan nulis kode "resik" lan nyedhaki proses pangembangan kanthi tanggung jawab lan profesional. Iki sing dikarepake kanggo kabeh wong!