Погана карма у програмуванні. Що таке технічний обов'язок і як його усувати

Технічний обов'язок. З цим терміном доводиться мати справу більшості програмістів, які працюють за фахом. У багатьох його згадка може навіть викликати біль голови, а також неприємні відчуття в інших частинах тіла, які з'являються щоразу, коли в ході роботи над проектом маєш справу з технічним боргом. Тому сьогодні поговоримо про технічний обов'язок (ТД): що це таке, як він з'являється, які види технічного боргу бувають і як ним ефективно управляти.

Що таке технічний обов'язок?

Проте спочатку розберемося з термінологією. Технічний обов'язок — це метафора програмної інженерії, що позначає накопичені в програмному коді або архітектурі проблеми, пов'язані з нехтуванням якості при розробці програмного забезпечення та викликають додаткові витрати праці в майбутньому. Таке визначення технічного обов'язку даєВікіпедія. Якщо висловлюватись простіше, технічний борг — це результат застосування спрощених і короткострокових рішень у розробці, які пізніше призводять до витрат, що постійно зростають (якщо, звичайно, борг не «погасити»), і часу на подальше доопрацювання, переписування коду або підтримку продукту в існуючому вигляді . У світі рядових програмістів технічний обов'язок — це один із різновидів негативної карми, демотиватор і джерело смутку, яке приходить як розплата за поганий код, використання мабоць та “тимчасові” (а насправді не дуже) рішення, які допомагають вирішувати короткострокові завдання та прискорювати розробку "в кредит," тобто за рахунок зростаючого клубку проблем у майбутньому. В ІТ-індустрії технічний борг — це досить серйозна проблема. За даними одного з недавніх досліджень, компанії по всьому світу щорічно витрачають понад $85 мільярдів на рік лише на роботу над виправленнями неякісного коду. А всього на проекти, пов'язані з підтримкою застарілих систем та "поганого" програмного забезпечення, йде близько $300 мільярдів на рік. Це значні цифри. Дослідники підрахували, що якщо зусилля всіх розробників, які працюють із технічним боргом та його наслідками, перефокусувати на “правильну” розробку, це додасть до світового ВВП близько 3 трильйонів доларів протягом поточного десятиліття.

Причини появи

Слід розуміти, що технічний борг - це не завжди погано, так само, як і влазіння у фінансові борги може бути позитивним, якщо ви, наприклад, берете кредит на розвиток бізнесу (або запуск стартапу )). У випадку з ТД, це прийнятно для компаній, що швидко ростуть, яким потрібно випускати нові продукти або послуги оперативно і часто, щоб оцінювати їх успішність і вивчати потреби ринку, або швидко захоплювати нові ніші, наприклад. Але, як і у випадку з фінансовими боргами, з технічним боргом потрібно бути обережним і вміти ним керувати, інакше можуть з'явитися серйозні проблеми. Чим більше при розробці програмного продукту накопичується технічний обов'язок, тим сильніше це може позначитися на компанії, уповільнюючи випуск нових релізів, знижуючи мораль рядових кодерів, на плечі яких лягає "зміст" такого боргу, і збільшуючи витрати, що в кінцевому рахунку може навіть занапастити компанію . Причинами виникнення технічного обов'язку, крім благородного бажання закінчити продукт якнайшвидше або порадувати користувачів новим релізом, часто служить поганий продукт-менеджмент, нереалістичні терміни або ресурсні обмеження, ну і звичайно, кодерська лінь разом з низькою кваліфікацією і нерозумінням ключових принципів розробки теж часто вносить у зростання боргу свій внесок. Часто буває і так, що самі розробники добре обізнані про наявність та постійне зростання технічного боргу, але не мають достатньо влади, щоб це змінити, або не можуть донести до керівництва інформацію про наявність такої проблеми та важливість її вирішення.

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

Як уже сказано вище, технічний борг буває різним, а оскільки саме це визначення є лише метафорою, класифікувати різні види технічного боргу можна по-різному. Зокрема, Даг Льодден (Dag Liodden), співзасновник та СТО компанії Tapad, який вважається одним із світових експертів з технічного боргу, під час виступу на щорічному заході CTO Summit запропонував розділяти технічний борг на три основні види .

1. Навмисний технічний обов'язок.

   З'являється в тих випадках, коли розробники усвідомлено вибирають не найкраще рішення, тому що його простіше і швидше реалізувати, що, своєю чергою, допоможе оперативніше випустити новий продукт на ринок.

   Іноді ми навмисне беремо на себе технічні борги, щоб зменшити час розробки. Якщо ви вирішуєте піти цим шляхом, беріть до уваги не тільки той час, що вдасться заощадити при розробці, але й той, який доведеться витратити потім, щоб погасити такий борг. Крім того, переконайтеся, що зацікавлені сторони [топ-менеджмент компанії] знають про те, що таке рішення неминуче уповільнить запуск інших функцій у подальшому,” – зазначив Даг Льодден.

   Підхід до вирішення цього типу технічного боргу

   Експерт радить ретельно документувати такі випадки, щоб повернутися до них і виправити доти, доки цей технічний борг не загубився, ставши невід'ємною частиною структури проекту.

2. Випадковий або технічний борг, що виник через застарілу архітектуру проекту.

   Також технічний борг часто виникає з часом, через помилки та недоробки на етапі створення архітектури проекту. У міру розвитку систем та змін до вимог програмних продуктів помилки в дизайні проекту починають ставати більш явними, а додавання нових функцій потребує все більше часу та зусиль. Тут важливу роль відіграє якість початкової архітектури проекту — вона має бути одночасно простою та функціональною, тоді її буде легше адаптувати до змін.

   Підхід до вирішення цього типу технічного боргу

   Щоб технічний борг цього виду не накопичувався і перевищував критичних обсягів, Даг Льодден рекомендує регулярно проводити рефакторинг — приблизно на два роки, у періоди, коли система перебуває у стійкому стані. Тимліди і продакт-менеджери повинні виділяти час на “погашення” такого роду технічного боргу, який виникає через архітектуру та вимоги до проекту, що часто змінюються.

3. Технічний обов'язок, що виникає з часом.

   Експерт називає такий технічний борг "довгогниючим." Він накопичується з часом, коли компонент або система поступово стають все складнішими через безліч змін, що постійно додаються. Часто це посилюється, якщо над системою різних етапах працюють різні люди, які розуміють оригінальну архітектуру.

   Підхід до вирішення цього типу технічного боргу

   Це єдиний із трьох типів технічного обов'язку, якого слід намагатися уникати на постійній основі шляхом регулярного рефакторингу, каже експерт. В ідеалі команда розробників повинна виділяти час на те, щоб досконало вивчити архітектуру системи, з якою працює, навіть якщо спочатку створювали її інші люди. Розуміння системи дозволить поступово покращувати та виправляти поганий код, не доводячи проект до стадії “гниття”.

Рішення для керування технічним боргом

Існує багато варіантів ефективного управління технічним боргом, але всі експерти сходяться на думці, що робити це треба обов'язково, оскільки ТД є невід'ємною частиною практично будь-якої розробки, а ті компанії, які ігнорують його, на більш пізніх етапах незмінно стикаються з проблемами. Ось кілька ефективних рішень та підходів до управління технічним боргом для команди розробників.

1. Виділяти фіксовану частку робочого дня працювати над технічним боргом.

   Особливість технічного обов'язку в тому, що на роботу з його усунення ніколи не знаходиться часу (бо завжди є пріоритетніші завдання), якщо не займатися цим цілеспрямовано. Тому хорошим рішенням буде виділити для цього фіксований відсоток робочого часу — близько 20-25%.

   Робити це можна по-різному.

2. Працювати над технічним боргом 1 день на тиждень

   Якщо виділяти на роботу над усуненням ТД всією командою один день на тиждень, це буде близько 20% від загального робочого часу. Для деяких команд такий підхід працює просто відмінно і, кажуть, навіть підвищує мораль, адже цього конкретного дня тижня вся команда займається вирішенням проблем, які дістають їх весь час розробки.

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

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

4. Перехідна роль

   Ще одним підходом до проблеми усунення технічного боргу призначатиме на це завдання різних членів команди по черзі, щоб рівномірно розподілити цю подекуди далеко не найприємнішу роботу серед членів колективу. Кількість розробників, призначених займатися "розгрібанням" ТД, може бути різною - для команди з 4-5 осіб буде достатньо одного, тоді як колективи більше можуть призначати двох-трьох. Але суть залишається незмінною — на роботу над ТД має йти близько 20-25% усіх ресурсів та людино-годин.

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

   Правило бойскаутів полягає в тому, щоб завжди залишати туристичний табір (стоянку для наметів) у кращому стані, ніж він був до їхнього приходу, тобто прибирати навіть те сміття, яке було залишено не ними. Цей принцип, як з'ясували заокеанські кодери, чудово підходить і для керування технічним обов'язком. Згідно з цим правилом, усі члени команди повинні займатися виправленням ТД щоразу, коли стикаються з ним у тому чи іншому вигляді. Звичайно, це правило потрібно застосовувати розумно, щоб час, що йде на виправлення ТД, не перевищував "розумні" 25-30% від загальних часових ресурсів.

6. Приоритизація "дорогого" технічного боргу

   Також експерти в своїй масі рекомендують не забувати про те, що технічний борг може відрізнятися навіть за важливістю. Не кожен тип ТД вимагає негайного усунення, тому важливо працювати над класифікацією різних видів технічного боргу і пріоритезацією роботи з ними відповідно. Простіше кажучи, насамперед закривати треба ті борги, які прямо впливають на швидкість розробки продукту, будучи частиною його базової архітектури. Такі борги є найнебезпечнішими, тому що ведуть до появи нових боргів, які можуть зростати як снігова куля.

Висновок

Насамкінець хотілося б ще раз наголосити, що зовсім без технічних боргів у розробці ПЗ не обійтися, адже вони є невід'ємною частиною девелопменту як такого. Втім, незважаючи на свою технічну сутність, ТД — це проблема, що викликається людським фактором у девелопменті. І хоча зовсім обійтися без нього не вийде, обсяги технічного боргу можна максимально скоротити, якщо писати чистий код і підходити до процесу розробки максимально відповідально та професійно. Чого ми всім бажаємо!