Бағдарламалаудағы жаман карма. Техникалық қарыз дегеніміз не және оны қалай түзетуге болады

Техникалық қарыз. Өз мамандығы бойынша белсенді жұмыс істейтін бағдарламашылардың көпшілігі осы терминмен айналысуы керек. Көптеген адамдар үшін оны еске түсіру тіпті бас ауруын тудыруы мүмкін, сонымен қатар дененің басқа бөліктеріндегі ыңғайсыздықты тудыруы мүмкін, ол жобада жұмыс істеу кезінде техникалық қарызмен айналысқан кезде пайда болады. Сондықтан бүгін біз техникалық қарыз (ТД) туралы сөйлесетін боламыз: бұл не, ол қалай пайда болады, техникалық қарыздың қандай түрлері бар және оны қалай тиімді басқару керек.

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

Дегенмен, алдымен терминологияны түсінейік. Техникалық қарыз - бұл бағдарламалық жасақтаманың codeында немесе архитектурасында жинақталған проблемаларға арналған бағдарламалық жасақтаманы әзірлеудегі сапаны елемеу салдарынан және болашақта қосымша еңбек шығындарын тудыратын бағдарламалық қамтамасыз ету инженериясының метафорасы. Бұл Википедия берген техникалық қарыздың анықтамасы . Қарапайым тілмен айтсақ, техникалық қарыз - бұл әзірлеуде оңайлатылған және қысқа мерзімді шешімдерді қолданудың нәтижесі, бұл кейінірек үнемі өсіп келе жатқан (әрине, қарыз «өтілген» болмаса) ақша шығындары мен кейінгі нақтылау үшін уақыт, codeты қайта жазу немесе өнімді оның бар түрінде сақтау. Қарапайым бағдарламашылар әлемінде техникалық қарыз теріс карманың түрлерінің бірі, демотиваторы және жаман codeты, балдақтарды және «уақытша» (бірақ шын мәнінде өте емес) шешімдерді пайдалану үшін жаза ретінде келетін қайғы көзі болып табылады. қысқа мерзімді мәселелерді шешуге және «несие бойынша» дамуды жеделдетуге, яғни болашақта өсіп келе жатқан проблемалардың есебінен. IT индустриясында техникалық қарыз айтарлықтай күрделі мәселе болып табылады. Жақында жүргізілген бір зерттеуге сәйкес , бүкіл әлем бойынша компаниялар жыл сайын нашар codeты түзетуге 85 миллиард доллардан астам қаражат жұмсайды. Ескірген жүйелер мен «нашар» бағдарламалық қамтамасыз етуді қолдауға байланысты жобаларға барлығы жылына шамамен 300 миллиард доллар жұмсалады. Бұл айтарлықтай сандар. Зерттеушілердің бағалауы бойынша, егер техникалық қарыздармен және оның салдарымен жұмыс істейтін барлық әзірлеушілердің күш-жігері «дұрыс» дамуға қайта бағытталса, бұл ағымдағы онжылдықта әлемдік ЖІӨ-ге шамамен 3 триллион доллар қосады.

Сыртқы көріністің себептері

Техникалық қарыз әрқашан жаман нәрсе емес екенін түсіну керек, мысалы, сіз бизнесті дамытуға (немесе стартапты іске қосуға ) несие алсаңыз, қаржылық қарызға түсу оң болуы мүмкін . TD жағдайында, бұл, мысалы, табыстарын бағалау және нарық қажеттіліктерін зерттеу немесе жаңа тауашаларды тез басып алу үшін жаңа өнімдерді немесе қызметтерді тез және жиі шығаруды қажет ететін жылдам дамып келе жатқан компаниялар үшін қолайлы. Бірақ, қаржылық қарыз сияқты, техникалық қарызға да абай болу керек және оны қалай басқару керектігін білу керек, әйтпесе күрделі мәселелер туындауы мүмкін. Бағдарламалық өнімді әзірлеу кезінде неғұрлым көп техникалық қарыз жиналса, ол соғұрлым компанияға әсер етуі мүмкін, жаңа шығарылымдардың шығарылуын бәсеңдетеді, мұндай қарызды «қалпына келтіруге» жауап беретін қарапайым codeерлердің моральдық деңгейін төмендетеді және шығындарды арттырады. , бұл сайып келгенде тіпті компанияны жоюы мүмкін. Техникалық қарыздың пайда болу себептері өнімді тезірек аяқтауға немесе пайдаланушыларды жаңа шығарылыммен қуантуға деген асыл ниеттен басқа, көбінесе өнімді дұрыс басқару, нақты емес мерзімдер немесе ресурстарды шектеулер және, әрине, codeтаушының жалқаулығы болып табылады. , төмен біліктілікпен және негізгі даму принциптерін түсінбеумен қатар, көбінесе қарыздың өсуіне ықпал етеді. Көбінесе әзірлеушілердің өздері техникалық қарыздың бар екенін және үнемі өсіп келе жатқанын жақсы біледі, бірақ оны өзгертуге күші жетпейді немесе мұндай мәселенің болуы және оны шешудің маңыздылығы туралы басшылыққа ақпаратты жеткізе алмайды.

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

Жоғарыда айтылғандай, техникалық қарыз әртүрлі нысандарда келеді және анықтаманың өзі жай ғана метафора болғандықтан, техникалық қарыздың әртүрлі түрлерін әртүрлі тәсілдермен жіктеуге болады. Атап айтқанда, техникалық қарыз бойынша әлемдік сарапшылардың бірі болып саналатын Tapad компаниясының негізін қалаушы және техникалық директоры Даг Лиодден жыл сайынғы CTO саммитінде сөз сөйлеген кезде техникалық қарызды үш негізгі түрге бөлуді ұсынды .

1. Қасақана техникалық қарыз.

   Бұл әзірлеушілер ең жақсы шешімді әдейі таңдамайтын жағдайларда пайда болады, өйткені оны жүзеге асыру оңайырақ және жылдамырақ, бұл өз кезегінде нарыққа жаңа өнімді жылдам шығаруға көмектеседі.

   «Кейде біз әзірлеу уақытын қысқарту үшін әдейі техникалық қарыз аламыз. Егер сіз осы бағытқа баруды шешсеңіз, даму кезінде үнемдейтін уақытты ғана емес, сондай-ақ мұндай қарызды «төлеуге» кейінірек жұмсауға тура келетін уақытты да ескеріңіз. Сондай-ақ, мүдделі тараптар [компанияның топ-менеджменті] мұндай шешім болашақта басқа функциялардың іске қосылуын сөзсіз бәсеңдететінін білетініне көз жеткізіңіз», - деді Даг Лжодден.

   Техникалық қарыздың осы түрін шешу тәсілі

   Сарапшы жоба құрылымының ажырамас бөлігіне айнала отырып, осы техникалық қарызды жоғалтқанға дейін оларды қайтару және оларды түзету үшін мұндай жағдайларды мұқият құжаттандыруға кеңес береді.

2. Кездейсоқ немесе ескірген жоба архитектурасынан туындайтын Техникалық қарыз.

   Сондай-ақ, техникалық қарыз көбінесе жобаның архитектурасын құру кезеңіндегі қателер мен кемшіліктерге байланысты уақыт өте келе пайда болады. Жүйелер дамып, бағдарламалық жасақтамаға қойылатын талаптар өзгерген сайын, дизайн қателері айқынырақ болады және жаңа мүмкіндіктерді қосу көбірек уақыт пен күш жұмсауды талап етеді. Мұнда жобаның бастапқы архитектурасының сапасы маңызды рөл атқарады - ол қарапайым және функционалды болуы керек, содан кейін өзгерістерге бейімделу оңайырақ болады.

   Техникалық қарыздың осы түрін шешу тәсілі

   Техникалық қарыздың бұл түрінің жиналуын және сыни деңгейлерден аспауын болдырмау үшін Даг Ллодден жүйелі түрде рефакторингті ұсынады – шамамен екі жылда бір рет, жүйе тұрақты күйде болған кезеңдер. Команда жетекшілері мен өнім менеджерлері архитектураға және жобаға жиі өзгеретін талаптарға байланысты туындайтын техникалық қарыздың бұл түрін «төлеуге» уақыт бөлуі керек.

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ты жазып, әзірлеу процесіне мүмкіндігінше жауапкершілікпен және кәсіби түрде қарасаңыз, техникалық қарыздың көлемін барынша азайтуға болады. Барлығына тілегіміз осы!