Dasturlashda yomon karma. Texnik qarz nima va uni qanday tuzatish kerak

Texnik qarz. O'z mutaxassisligi bo'yicha faol ishlayotgan dasturchilarning aksariyati ushbu atama bilan shug'ullanishlari kerak. Ko'pchilik uchun uning eslatilishi hatto bosh og'rig'iga olib kelishi mumkin, shuningdek, loyiha ustida ishlayotganda texnik qarz bilan shug'ullanganingizda paydo bo'ladigan tananing boshqa qismlarida noqulaylik tug'diradi. Shuning uchun, bugun biz texnik qarz (TD) haqida gapiramiz: bu nima, u qanday paydo bo'ladi, texnik qarzning qanday turlari mavjud va uni qanday samarali boshqarish kerak.

Texnik qarz nima?

Biroq, avval terminologiyani tushunaylik. Texnik qarz - bu dasturiy ta'minotni ishlab chiqishda sifatni e'tiborsiz qoldirish va kelajakda qo'shimcha mehnat xarajatlarini keltirib chiqarishi sababli dasturiy ta'minot kodi yoki arxitekturasida to'plangan muammolar uchun dasturiy ta'minot muhandisligi metaforasi. Bu Vikipediya tomonidan berilgan texnik qarz ta'rifi . Oddiy qilib aytganda, texnik qarz - bu rivojlanishda soddalashtirilgan va qisqa muddatli echimlarni qo'llash natijasi bo'lib, bu keyinchalik doimiy ravishda o'sib borishiga olib keladi (albatta, qarz "to'lanmagan" bo'lsa), keyinchalik takomillashtirish uchun pul va vaqt xarajatlari, kodni qayta yozish yoki mahsulotni mavjud shaklda saqlash. Oddiy dasturchilar dunyosida texnik qarz salbiy karma turlaridan biri, demotivator va qayg'u manbai bo'lib, u yomon kod, tayoqchalardan foydalanish va "vaqtinchalik" (lekin unchalik emas) echimlar uchun qasos sifatida keladi. qisqa muddatli muammolarni hal qilishda yordam berish va rivojlanishni "kredit asosida", ya'ni kelajakda tobora kuchayib borayotgan muammolar evaziga tezlashtirish. IT sohasida texnik qarz juda jiddiy muammo hisoblanadi. Yaqinda o'tkazilgan bir tadqiqotga ko'ra , butun dunyo bo'ylab kompaniyalar har yili faqat noto'g'ri kodni tuzatish uchun 85 milliard dollardan ko'proq mablag 'sarflaydilar. Umuman olganda, yiliga taxminan 300 milliard dollar eskirgan tizimlar va "yomon" dasturiy ta'minotni qo'llab-quvvatlash bilan bog'liq loyihalarga sarflanadi. Bu muhim raqamlar. Tadqiqotchilarning hisob-kitoblariga ko'ra, agar texnik qarzlar va uning oqibatlari bilan ishlaydigan barcha ishlab chiquvchilarning sa'y-harakatlari "to'g'ri" rivojlanishga yo'naltirilsa, bu joriy o'n yillikda global yalpi ichki mahsulotga taxminan 3 trillion dollar qo'shadi.

Tashqi ko'rinish sabablari

Shuni tushunish kerakki, texnik qarz har doim ham yomon narsa emas, xuddi moliyaviy qarzga tushish ijobiy bo'lishi mumkin, masalan, biznesni rivojlantirish uchun kredit olsangiz (yoki startapni ishga tushirsangiz ). TD misolida, bu o'z muvaffaqiyatlarini baholash va bozor ehtiyojlarini o'rganish yoki yangi bo'shliqlarni tezda egallash uchun tez va tez-tez yangi mahsulot yoki xizmatlarni chiqarishi kerak bo'lgan tez rivojlanayotgan kompaniyalar uchun maqbuldir. Ammo, moliyaviy qarzda bo'lgani kabi, siz texnik qarz bilan ehtiyot bo'lishingiz va uni qanday boshqarishni bilishingiz kerak, aks holda jiddiy muammolar paydo bo'lishi mumkin. Dasturiy ta'minot mahsulotini ishlab chiqish jarayonida qancha ko'p texnik qarz to'plangan bo'lsa, u kompaniyaga shunchalik ko'p ta'sir qilishi mumkin, yangi nashrlarning chiqarilishini sekinlashtiradi, bunday qarzni "saqlash" uchun mas'ul bo'lgan oddiy kodlovchilarning ma'naviyatini pasaytiradi va xarajatlarni oshiradi. , bu oxir-oqibatda kompaniyani ham yo'q qilishi mumkin. Texnik qarzning paydo bo'lishining sabablari, mahsulotni iloji boricha tezroq tugatish yoki foydalanuvchilarni yangi nashr bilan xursand qilish istagidan tashqari, ko'pincha mahsulotni noto'g'ri boshqarish, haqiqiy bo'lmagan muddatlar yoki resurslarni cheklash va, albatta, koderning dangasaligidir. , past malaka va asosiy rivojlanish tamoyillarini tushunmaslik bilan birga, ko'pincha qarzning o'sishiga hissa qo'shadi. Ko'pincha ishlab chiquvchilarning o'zlari texnik qarzning mavjudligi va doimiy o'sishini yaxshi bilishadi, lekin uni o'zgartirish uchun etarli kuchga ega emaslar yoki bunday muammoning mavjudligi va uni hal qilish muhimligi to'g'risida rahbariyatga ma'lumot etkaza olmaydilar.

Tasniflash

Yuqorida aytib o'tilganidek, texnik qarz juda ko'p turli xil shakllarda bo'ladi va ta'rifning o'zi shunchaki metafora bo'lganligi sababli, texnik qarzning har xil turlarini turli yo'llar bilan tasniflash mumkin. Xususan, texnik qarzlar bo'yicha jahon ekspertlaridan biri sanalgan Tapad kompaniyasi asoschisi va texnik direktori Dag Liodden yillik CTO sammiti tadbiridagi nutqi davomida texnik qarzni uchta asosiy turga bo'lishni taklif qildi .

1. Qasddan texnik qarz.

   Bu ishlab chiquvchilar ataylab eng yaxshi echimni tanlamagan hollarda paydo bo'ladi, chunki uni amalga oshirish osonroq va tezroq, bu esa o'z navbatida bozorga yangi mahsulotni tezda chiqarishga yordam beradi.

   "Ba'zan biz ishlab chiqish vaqtini qisqartirish uchun ataylab texnik qarz olamiz. Agar siz ushbu yo'ldan borishga qaror qilsangiz, nafaqat rivojlanish vaqtida tejash vaqtini, balki keyinchalik bunday qarzni "to'lash" uchun sarflashingiz kerak bo'lgan vaqtni ham hisobga oling. Shuningdek, manfaatdor tomonlar [kompaniyaning yuqori rahbariyati] bunday qaror kelajakda boshqa funksiyalarni ishga tushirishni muqarrar ravishda sekinlashtirishini bilishlariga ishonch hosil qiling”, — dedi Dag Ljodden.

   Ushbu turdagi texnik qarzni hal qilish uchun yondashuv

   Mutaxassis, ushbu texnik qarzni yo'qotishdan oldin, loyiha tuzilmasining ajralmas qismiga aylanib qolguncha, ularga qaytish va ularni tuzatish uchun bunday holatlarni diqqat bilan hujjatlashtirishni maslahat beradi.

2. Tasodifiy yoki eskirgan loyiha arxitekturasidan kelib chiqadigan texnik qarz.

   Shuningdek, texnik qarz ko'pincha vaqt o'tishi bilan loyiha arxitekturasini yaratish bosqichidagi xatolar va kamchiliklar tufayli yuzaga keladi. Tizimlar rivojlanishi va dasturiy ta'minotga bo'lgan talablarning o'zgarishi bilan dizayndagi xatolar yanada aniq bo'ladi va yangi xususiyatlarni qo'shish ko'proq vaqt va kuch talab qiladi. Dastlabki loyiha arxitekturasining sifati bu erda muhim rol o'ynaydi - u ham oddiy, ham funktsional bo'lishi kerak, keyin o'zgarishlarga moslashish osonroq bo'ladi.

   Ushbu turdagi texnik qarzni hal qilish uchun yondashuv

   Ushbu turdagi texnik qarzlarning to'planib qolmasligi va kritik darajadan oshmasligi uchun Dag Llodden muntazam ravishda refaktoring qilishni tavsiya qiladi - taxminan ikki yilda bir marta, tizim barqaror holatda bo'lgan davrlarda. Jamoa rahbarlari va mahsulot menejerlari loyiha uchun arxitektura va tez-tez o'zgarib turadigan talablar tufayli yuzaga keladigan ushbu turdagi texnik qarzni "to'lash" uchun vaqt ajratishlari kerak.

3. Vaqt o'tishi bilan yuzaga keladigan texnik qarz.

   Mutaxassis bunday texnik qarzni "uzoq chirigan" deb ataydi. U vaqt o'tishi bilan to'planadi, chunki komponent yoki tizim doimiy ravishda qo'shiladigan ko'plab o'zgarishlar tufayli asta-sekin murakkablashadi. Agar turli odamlar tizimda turli bosqichlarda ishlasa va asl arxitekturani to'liq tushunmasa, bu ko'pincha kuchayadi.

   Ushbu turdagi texnik qarzni hal qilish uchun yondashuv

   Mutaxassisning aytishicha, bu texnik qarzning uchta turidan faqat bittasi bo'lib, siz muntazam ravishda refaktoring orqali doimiy ravishda qochishga harakat qilishingiz kerak. Ideal holda, ishlab chiquvchi guruh o'zlari ishlayotgan tizim arxitekturasini, hatto u dastlab boshqa odamlar tomonidan yaratilgan bo'lsa ham, chuqur tushunish uchun vaqt ajratishi kerak. Tizimni tushunish sizga loyihani "chirish" bosqichiga olib kelmasdan, yomon kodni bosqichma-bosqich yaxshilash va tuzatishga imkon beradi.

Qarzni boshqarish bo'yicha texnik echimlar

Texnik qarzni samarali boshqarishning ko'plab variantlari mavjud, ammo barcha mutaxassislar buni qilish kerak degan fikrga qo'shiladilar, chunki texnik qarz deyarli har qanday rivojlanishning ajralmas qismidir va uni e'tiborsiz qoldiradigan kompaniyalar keyingi bosqichlarda doimo muammolarga duch kelishadi. Rivojlanish guruhi uchun texnik qarzlarni boshqarish bo'yicha samarali echimlar va yondashuvlar.

1. Ish vaqtingizning belgilangan foizini texnik qarz bilan ishlashga ajrating.

   Texnik qarz haqida gap shundaki, agar siz buni maqsadli bajarmasangiz, uni yo'q qilish ustida ishlashga hech qachon vaqt bo'lmaydi (chunki har doim ustuvor vazifalar mavjud). Shuning uchun, ushbu maqsadlar uchun ish vaqtining ma'lum bir qat'iy foizini - taxminan 20-25% ni ajratish yaxshi echim bo'ladi.

   Bu turli yo'llar bilan amalga oshirilishi mumkin.

2. Haftada 1 kun texnik qarz ustida ishlang

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

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

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

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

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

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

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

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

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

Заключение

Va nihoyat, yana bir bor ta'kidlashni istardimki, dasturiy ta'minotni ishlab chiqishda texnik qarzlarsiz qilish mumkin emas, chunki ular rivojlanishning ajralmas qismidir. Biroq, texnik tabiatiga qaramay, TD hali ham rivojlanishdagi inson omili tufayli yuzaga kelgan muammodir. Garchi siz bu holda to'liq ishlay olmasangiz ham, agar siz "toza" kodni yozsangiz va rivojlanish jarayoniga imkon qadar mas'uliyatli va professional tarzda yondashsangiz, texnik qarz miqdori imkon qadar kamayishi mumkin. Biz hammaga shuni tilaymiz!