Bad karma sa programming. Ano ang teknikal na utang at kung paano ayusin ito

Teknikal na utang. Karamihan sa mga programmer na aktibong nagtatrabaho sa kanilang espesyalidad ay kailangang harapin ang terminong ito. Para sa marami, ang pagbanggit nito ay maaaring maging sanhi ng sakit ng ulo, pati na rin ang kakulangan sa ginhawa sa ibang bahagi ng katawan na lumilitaw sa tuwing nakikitungo ka sa teknikal na utang habang nagtatrabaho sa isang proyekto. Samakatuwid, ngayon ay pag-uusapan natin ang tungkol sa teknikal na utang (TD): kung ano ito, kung paano ito lumilitaw, anong mga uri ng teknikal na utang ang mayroon, at kung paano ito epektibong pamahalaan.

Ano ang teknikal na utang?

Gayunpaman, unawain muna natin ang terminolohiya. Ang teknikal na utang ay isang metapora ng software engineering para sa mga problemang naipon sa software code o arkitektura dahil sa pagpapabaya sa kalidad sa pagbuo ng software at nagdudulot ng karagdagang mga gastos sa paggawa sa hinaharap. Ito ang kahulugan ng teknikal na utang na ibinigay ng Wikipedia. Sa madaling salita, ang teknikal na utang ay resulta ng paglalapat ng pinasimple at panandaliang solusyon sa pag-unlad, na kalaunan ay humahantong sa patuloy na pagtaas (maliban kung, siyempre, ang utang ay "binabayaran") na mga gastos sa pera at oras para sa kasunod na pagpipino, muling pagsulat ng code o pagpapanatili ng produkto sa dati nitong anyo. Sa mundo ng mga ordinaryong programmer, ang teknikal na utang ay isa sa mga uri ng negatibong karma, isang demotivator at isang pinagmumulan ng kalungkutan na nagmumula bilang kabayaran para sa masamang code, ang paggamit ng mga saklay at "pansamantalang" (ngunit sa katunayan hindi masyadong) mga solusyon na tumulong sa paglutas ng mga panandaliang problema at pabilisin ang pag-unlad "sa kredito," iyon ay, sa kapinsalaan ng lumalaking salu-salo ng mga problema sa hinaharap. Sa industriya ng IT, ang teknikal na utang ay isang medyo seryosong problema. Ayon sa isang kamakailang pag-aaral , ang mga kumpanya sa buong mundo taun-taon ay gumagastos ng higit sa $85 bilyon sa isang taon para lamang ayusin ang masamang code. Sa kabuuan, humigit-kumulang $300 bilyon sa isang taon ang ginagastos sa mga proyektong nauugnay sa pagsuporta sa mga lumang sistema at "masamang" software. Ang mga ito ay makabuluhang numero. Tinataya ng mga mananaliksik na kung ang mga pagsisikap ng lahat ng mga developer na nagtatrabaho sa teknikal na utang at ang mga kahihinatnan nito ay muling nakatuon sa "tama" na pag-unlad, ito ay magdaragdag ng humigit-kumulang $3 trilyon sa pandaigdigang GDP sa paglipas ng kasalukuyang dekada.

Mga dahilan para sa hitsura

Dapat na maunawaan na ang teknikal na utang ay hindi palaging isang masamang bagay, tulad ng pagkuha sa pinansiyal na utang ay maaaring maging positibo kung, halimbawa, kukuha ka ng pautang upang bumuo ng isang negosyo (o maglunsad ng isang startup ). Sa kaso ng TD, ito ay katanggap-tanggap para sa mabilis na lumalagong mga kumpanya na kailangang maglabas ng mga bagong produkto o serbisyo nang mabilis at madalas upang masuri ang kanilang tagumpay at pag-aralan ang mga pangangailangan sa merkado, o mabilis na makuha ang mga bagong niches, halimbawa. Ngunit, tulad ng utang sa pananalapi, kailangan mong mag-ingat sa teknikal na utang at malaman kung paano pamahalaan ito, kung hindi man ay maaaring lumitaw ang mga malubhang problema. Ang mas maraming teknikal na utang na naipon sa panahon ng pagbuo ng isang produkto ng software, mas maaapektuhan nito ang kumpanya, nagpapabagal sa pagpapalabas ng mga bagong release, nagpapababa sa moral ng mga ordinaryong coder na responsable para sa "pag-iingat" ng naturang utang, at pagtaas ng mga gastos , na sa huli ay maaari pang sirain ang kumpanya. Ang mga dahilan para sa paglitaw ng teknikal na utang, bilang karagdagan sa marangal na pagnanais na tapusin ang produkto sa lalong madaling panahon o upang masiyahan ang mga gumagamit sa isang bagong release, ay madalas na hindi magandang pamamahala ng produkto, hindi makatotohanang mga deadline o mga limitasyon ng mapagkukunan, at siyempre, katamaran ng coder. , kasama ng mababang kwalipikasyon at kakulangan ng pag-unawa sa mga pangunahing prinsipyo ng pag-unlad, ay madalas ding nag-aambag sa paglaki ng utang. Madalas na nangyayari na ang mga developer mismo ay nakakaalam ng pagkakaroon at patuloy na paglaki ng teknikal na utang, ngunit walang sapat na kapangyarihan upang baguhin ito, o hindi makapagbigay ng impormasyon sa pamamahala tungkol sa pagkakaroon ng naturang problema at ang kahalagahan ng paglutas nito.

Pag-uuri

Tulad ng nabanggit sa itaas, ang teknikal na utang ay dumating sa maraming iba't ibang anyo, at dahil ang kahulugan mismo ay isang metapora lamang, ang iba't ibang uri ng teknikal na utang ay maaaring uriin sa iba't ibang paraan. Sa partikular, iminungkahi ni Dag Liodden, co-founder at CTO ng Tapad, na itinuturing na isa sa mga eksperto sa mundo sa teknikal na utang, sa isang talumpati sa taunang kaganapan sa CTO Summit, na hatiin ang teknikal na utang sa tatlong pangunahing uri.

1. Sinadyang teknikal na utang.

   Ito ay lumilitaw sa mga kaso kung saan ang mga developer ay sadyang pumili ng hindi ang pinakamahusay na solusyon, dahil ito ay mas madali at mas mabilis na ipatupad, na, sa turn, ay makakatulong upang mabilis na mailabas ang isang bagong produkto sa merkado.

   "Minsan sinasadya nating kumuha ng teknikal na utang upang mabawasan ang oras ng pag-unlad. Kung magpasya kang pumunta sa rutang ito, isaalang-alang hindi lamang ang oras na iyong mai-save sa panahon ng pag-unlad, kundi pati na rin ang oras na kakailanganin mong gugulin sa ibang pagkakataon upang "mabayaran" ang naturang utang. Gayundin, siguraduhin na ang mga stakeholder [nangungunang pamamahala ng kumpanya] ay may kamalayan na ang naturang desisyon ay hindi maiiwasang magpapabagal sa paglulunsad ng iba pang mga function sa hinaharap, "sabi ni Dag Ljodden.

   Isang diskarte sa paglutas ng ganitong uri ng teknikal na utang

   Pinapayuhan ng dalubhasa ang maingat na pagdodokumento ng mga ganitong kaso upang maibalik sa kanila at itama ang mga ito bago mawala ang teknikal na utang na ito, na nagiging mahalagang bahagi ng istraktura ng proyekto.

2. Aksidente o nagmumula sa hindi napapanahong arkitektura ng proyekto. Teknikal na utang.

   Gayundin, ang teknikal na utang ay madalas na lumitaw sa paglipas ng panahon, dahil sa mga pagkakamali at pagkukulang sa yugto ng paglikha ng arkitektura ng proyekto. Habang nagbabago ang mga system at nagbabago ang mga kinakailangan sa software, nagiging mas maliwanag ang mga error sa disenyo, at nangangailangan ng mas maraming oras at pagsisikap ang pagdaragdag ng mga bagong feature. Ang kalidad ng paunang arkitektura ng proyekto ay gumaganap ng isang mahalagang papel dito - dapat itong parehong simple at functional, pagkatapos ay magiging mas madaling iakma sa mga pagbabago.

   Isang diskarte sa paglutas ng ganitong uri ng teknikal na utang

   Upang maiwasan ang ganitong uri ng teknikal na utang mula sa pag-iipon at hindi lalampas sa mga kritikal na antas, inirerekomenda ni Dag Llodden ang regular na refactoring - humigit-kumulang isang beses bawat dalawang taon, sa mga panahon na ang system ay nasa isang matatag na estado. Ang mga pinuno ng koponan at mga tagapamahala ng produkto ay dapat maglaan ng oras upang "bayaran" ang ganitong uri ng teknikal na utang na lumitaw dahil sa arkitektura at madalas na pagbabago ng mga kinakailangan para sa proyekto.

3. Teknikal na utang na lumilitaw sa paglipas ng panahon.

   Tinatawag ng eksperto ang gayong teknikal na utang na "matagal nang nabubulok." Naiipon ito sa paglipas ng panahon habang ang isang bahagi o sistema ay unti-unting nagiging mas kumplikado dahil sa maraming pagbabago na patuloy na idinaragdag. Madalas itong lumalala kung gumagana ang iba't ibang tao sa system sa iba't ibang yugto at hindi lubos na nauunawaan ang orihinal na arkitektura.

   Isang diskarte sa paglutas ng ganitong uri ng teknikal na utang

   Ito ang isa lamang sa tatlong uri ng teknikal na utang na dapat mong subukang iwasan sa patuloy na batayan sa pamamagitan ng regular na refactoring, sabi ng eksperto. Sa isip, ang isang development team ay dapat maglaan ng oras upang lubusang maunawaan ang arkitektura ng system na kanilang ginagawa, kahit na ito ay orihinal na nilikha ng ibang mga tao. Ang pag-unawa sa system ay magbibigay-daan sa iyong unti-unting pagbutihin at iwasto ang masamang code nang hindi dinadala ang proyekto sa yugto ng "nabubulok."

Mga Teknikal na Solusyon sa Pamamahala ng Utang

Maraming mga opsyon para sa epektibong pamamahala ng teknikal na utang, ngunit ang lahat ng mga eksperto ay sumasang-ayon na ito ay dapat gawin, dahil ang teknikal na utang ay isang mahalagang bahagi ng halos anumang pag-unlad, at ang mga kumpanyang hindi binabalewala ito ay palaging nahaharap sa mga problema sa mga susunod na yugto. Narito ang ilang epektibong solusyon at diskarte sa pamamahala ng teknikal na utang para sa isang development team.

1. Maglaan ng nakapirming porsyento ng iyong oras ng trabaho sa pagtatrabaho sa teknikal na utang.

   Ang bagay tungkol sa teknikal na utang ay na walang oras upang magtrabaho sa pag-aalis nito (dahil palaging may mas mataas na priyoridad na mga gawain) maliban kung gagawin mo ito nang may layunin. Samakatuwid, ang isang magandang solusyon ay ang paglalaan ng isang tiyak na nakapirming porsyento ng oras ng pagtatrabaho para sa mga layuning ito - mga 20-25%.

   Ito ay maaaring gawin sa iba't ibang paraan.

2. Magtrabaho sa teknikal na utang 1 araw sa isang linggo

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

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

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

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

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

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

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

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

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

Заключение

Sa wakas, nais kong bigyang-diin muli na imposibleng gawin nang walang teknikal na utang sa pagbuo ng software, dahil ang mga ito ay isang mahalagang bahagi ng pag-unlad tulad nito. Gayunpaman, sa kabila ng teknikal na katangian nito, ang TD ay problema pa rin na sanhi ng kadahilanan ng tao sa pag-unlad. At kahit na hindi mo magagawa nang wala ito nang buo, ang halaga ng teknikal na utang ay maaaring mabawasan hangga't maaari kung susulat ka ng "malinis" na code at lapitan ang proseso ng pag-unlad nang responsable at propesyonal hangga't maaari. Ito ang nais namin para sa lahat!