Программалоодогу жаман карма. Техникалык карыз деген эмне жана аны кантип оңдоо керек

Техникалык карыз. Көпчүлүк программисттер өз адистиги боюнча жигердүү иштеген бул термин менен күрөшүүгө туура келет. Көптөр үчүн анын сөз болушу баш ооруну, ошондой эле дененин башка бөлүктөрүндө ыңгайсыздыкты жаратышы мүмкүн, ал долбоордо иштеп жатканда техникалык карыз менен күрөшкөн сайын пайда болот. Ошондуктан, бүгүн биз техникалык карыз (TD) жөнүндө сүйлөшөбүз: бул эмне, ал кантип пайда болот, техникалык карыздын кандай түрлөрү бар жана аны кантип натыйжалуу башкаруу керек.

Техникалык карыз деген эмне?

Бирок, адегенде терминологияны түшүнүп алалы. Техникалык карыз - бул программалык камсыздоону иштеп чыгууда сапатка көңүл бурбоо жана келечекте кошумча эмгек чыгымдарын пайда кылуудан улам программалык камсыздоонун codeунда же архитектурасында топтолгон көйгөйлөрдүн программалык инженериясынын метафорасы. Бул Wikipedia тарабынан берилген техникалык карыз аныктамасы болуп саналат . Жөнөкөй сөз менен айтканда, техникалык карыз өнүгүүдө жөнөкөйлөштүрүлгөн жана кыска мөөнөттүү чечимдерди колдонуунун натыйжасы болуп саналат, алар кийинчерээк ар дайым өсүп жаткан (албетте, карыз “төленбөсө”) акчага жана кийинки тактоо үчүн убакытка, codeду кайра жазуу же өнүмдү учурдагы түрүндө сактоо. Жөнөкөй программисттердин дүйнөсүндө техникалык карыз - бул терс карманын түрлөрүнүн бири, демотиватор жана жаман code үчүн өч алуу, балдактарды колдонуу жана "убактылуу" (бирок чындыгында анча эмес) чечимдерди колдонуу. кыска мөөнөттүү көйгөйлөрдү чечүүгө жана өнүгүүнү тездетүүгө "кредит боюнча", башкача айтканда, келечекте көйгөйлөрдүн курчушуна жардам берет. IT тармагында техникалык карыз кыйла олуттуу көйгөй болуп саналат. Акыркы бир изилдөөгө ылайык , дүйнө жүзү боюнча компаниялар жыл сайын жаман codeду оңдоого 85 миллиард доллардан ашык коротушат. Жалпысынан, эскирген системаларды жана “жаман” программалык камсыздоону колдоо менен байланышкан долбоорлорго жылына болжол менен 300 миллиард доллар сарпталат. Бул олуттуу сандар. Изилдөөчүлөрдүн баамында, эгерде техникалык карыз жана анын кесепеттери менен иштеген бардык иштеп чыгуучулардын күч-аракети “туура” өнүгүүгө багытталса, бул азыркы он жылдын ичинде дүйнөлүк ИДПга болжол менен 3 триллион долларды кошмок.

пайда болуу себептери

Техникалык карыз дайыма эле жаман нерсе эмес экенин түшүнүү керек, мисалы, сиз бизнести өнүктүрүү үчүн насыя алсаңыз (же стартапты ишке киргизсеңиз ), финансылык карызга түшүү оң болушу мүмкүн. TD учурда, бул, мисалы, ийгorгине баа берүү жана рыноктун муктаждыктарын изилдөө үчүн тез жана тез арада жаңы өнүмдөрдү же кызматтарды чыгарууга муктаж болгон тез өнүгүп жаткан компаниялар үчүн алгылыктуу. Бирок, каржылык карыз сыяктуу эле, техникалык карызга да сак болушуңуз керек жана аны башкарууну бorшиңиз керек, антпесе олуттуу көйгөйлөр келип чыгышы мүмкүн. Программалык продуктуну иштеп чыгууда канчалык көп техникалык карыз топтолсо, ал компанияга ошончолук көп таасир этиши мүмкүн, жаңы релиздердин чыгышын жайлатып, мындай карызды "колдоо" үчүн жооптуу катардагы codeерлордун моралдык абалын төмөндөтөт жана чыгымдарды көбөйтөт. , ал акырында компанияны жок кылышы мүмкүн. Техникалык карыздын пайда болушунун себептери, продуктуну мүмкүн болушунча эртерээк бүтүрүү же колдонуучуларды жаңы релиз менен кубануу каалоосунан тышкары, көбүнчө өнүмдөрдү начар башкаруу, реалдуу эмес мөөнөттөр же ресурстардын чектөөлөрү жана, албетте, codeдердин жалкоолугу. Квалификациянын төмөндүгү жана өнүгүүнүн негизги принциптерин түшүнбөстүк менен бирге, карыздын өсүшүнө салым кошот. Көбүнчө иштеп чыгуучулардын өздөрү техникалык карыздын бар экендигин жана тынымсыз өсүшүн жакшы бorшет, бирок аны өзгөртүүгө күчү жетпейт же мындай көйгөйдүн бар экендиги жана аны чечүүнүн маанилүүлүгү жөнүндө жетекчorкке маалымат жеткире алышпайт.

Классификация

Жогоруда айтылгандай, техникалык карыз ар кандай формаларда келет жана аныктама өзү жөн гана метафора болгондуктан, техникалык карыздын ар кандай түрлөрүн ар кандай жолдор менен классификациялоого болот. Тактап айтканда, техникалык карыз боюнча дүйнөдөгү эксперттердин бири деп эсептелген Tapad компаниясынын негиздөөчүсү жана техникалык директору Даг Лиодден жылдык CTO саммитинде сүйлөгөн сөзүндө техникалык карызды үч негизги түргө бөлүүнү сунуштады .

1. Атайын техникалык карыз.

   Бул иштеп чыгуучулар атайылап мыкты чечимди тандабаган учурларда пайда болот, анткени аны ишке ашыруу оңой жана тезирээк, бул өз кезегинде рынокко жаңы продуктуну тез арада чыгарууга жардам берет.

   «Кээде биз иштеп чыгуу убактысын кыскартуу үчүн техникалык карызды атайылап алабыз. Эгерде сиз бул жол менен барууну чечсеңиз, өнүгүү учурунда үнөмдөй турган убактыңызды гана эмес, ошондой эле кийинчерээк мындай карызды “төлөө” үчүн сарптай турган убактыңызды да эске алыңыз. Ошондой эле, кызыкдар тараптар [компаниянын топ-менеджменти] мындай чечим келечекте башка функцияларды ишке киргизүүнү сөзсүз жайлатат деп бorшине ынаныңыз», - деди Даг Лжодден.

   Техникалык карыздын бул түрүн чечүүгө болгон мамиле

   Эксперт долбоордун структурасынын ажырагыс бөлүгү болуп, бул техникалык карыз жоголгонго чейин аларды кайра кайтаруу жана аларды оңдоо үчүн, кылдаттык менен documentтештирүү сунуш кылат.

2. Кокусунан же эскирген долбоор архитектурасынан келип чыккан Техникалык карыз.

   Ошондой эле, техникалык карыз көп учурда долбоордун архитектурасын түзүү стадиясында каталар жана кемчorктерден улам, убакыттын өтүшү менен пайда болот. Системалар өнүккөн сайын жана программалык камсыздоого талаптар өзгөргөн сайын, дизайн каталары айкын болуп, жаңы функцияларды кошуу көбүрөөк убакытты жана күч-аракетти талап кылат. Бул жерде долбоордун баштапкы архитектурасынын сапаты маанилүү роль ойнойт - ал жөнөкөй жана функционалдык болушу керек, ошондо өзгөрүүлөргө көнүү оңой болот.

   Техникалык карыздын бул түрүн чечүүгө болгон мамиле

   Техникалык карыздын бул түрүнүн топтолушуна жана критикалык деңгээлден ашпашына жол бербөө үчүн Даг Ллодден рефакторингди үзгүлтүксүз жүргүзүүнү сунуштайт - болжол менен эки жылда бир жолу, система туруктуу абалда болгон мезгилде. Команда лидерлери жана продукт менеджерлери архитектура жана тез-тез өзгөрүп туруучу долбоорго талаптардан улам келип чыккан техникалык карыздын бул түрүн "төлөө" үчүн убакыт бөлүшү керек.

3. Убакыттын өтүшү менен пайда болгон техникалык карыз.

   Эксперт мындай техникалык карызды «узак чириген» деп атайт. Ал убакыттын өтүшү менен топтолот, анткени көп өзгөрүүлөр тынымсыз кошулуп тургандыктан, бир компонент же система акырындык менен татаалдашат. Бул системада ар кандай адамдар ар кандай этаптарда иштеп, баштапкы архитектураны толук түшүнбөсө, бул көбүнчө начарлайт.

   Техникалык карыздын бул түрүн чечүүгө болгон мамиле

   Бул техникалык карыздын үч түрүнүн жалгыз бири, аны үзгүлтүксүз рефакторинг аркылуу качууга аракет кылуу керек, дейт эксперт. Идеалында, иштеп чыгуу тобу, ал башында башка адамдар тарабынан түзүлгөн болсо да, алар иштеп жаткан системанын архитектурасын кылдат түшүнүү үчүн убакыт керек. Системаны түшүнүү сизге долбоорду "чирип кетүү" баскычына алып келбестен, начар codeду акырындык менен жакшыртууга жана оңдоого мүмкүндүк берет.

Карызды башкаруунун техникалык чечимдери

Техникалык карызды эффективдүү башкаруунун көптөгөн варианттары бар, бирок бардык эксперттер муну жасаш керек дегенге кошулушат, анткени техникалык карыз дээрлик бардык өнүгүүнүн ажырагыс бөлүгү болуп саналат жана аны этибар албаган компаниялар кийинки этаптарда дайыма көйгөйлөргө туш болушат. Бул жерде иштеп чыгуу командасы үчүн техникалык карызды башкаруу үчүн кээ бир натыйжалуу чечимдер жана ыкмалар болуп саналат.

1. Жумуш убактысынын белгиленген пайызын техникалык карыз боюнча иштөөгө бөлүңүз.

   Техникалык карыз жөнүндө нерсе, эгер сиз аны максаттуу түрдө кылмайынча, аны жоюу боюнча иштөөгө эч качан убакыт болбойт (анткени ар дайым артыкчылыктуу милдеттер бар). Ошондуктан, бул максаттар үчүн жумуш убактысынын белгилүү бир туруктуу пайызын бөлүү жакшы чечим болмок - болжол менен 20-25%.

   Бул ар кандай жолдор менен жасалышы мүмкүн.

2. Жумасына 1 күн техникалык карыз боюнча иштөө

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

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

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

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

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

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

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

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

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

Заключение

Акырында дагы бир жолу баса белгилеп кетким келет, программалык камсыздоону иштеп чыгууда техникалык карызсыз кылуу мүмкүн эмес, анткени алар өнүгүүнүн ажырагыс бөлүгү болуп саналат. Бирок, өзүнүн техникалык мүнөзүнө карабастан, ТД дагы эле өнүгүүдөгү адам фактору менен шартталган көйгөй болуп саналат. Ансыз толугу менен кыла албасаңыз да, эгер сиз "таза" codeду жазып, иштеп чыгуу процессине мүмкүн болушунча жоопкерчorктүү жана кесипкөй мамиле кылсаңыз, техникалык карыздын көлөмүн мүмкүн болушунча азайтууга болот. Бул баарыбызга тилегенибиз!