Технічний борг під час розроблення ПЗ

Технічний борг – це повсякденне поняття під час розробки програмного забезпечення. Але те, як ваша команда розв’язує і керує кожним типом технологічного боргу, визначає, як це вплине на результат вашого програмного продукту.

Хоча деякі технічні борги є навмисними, інших типів можна повністю уникнути. Чи вживає ваша команда розробників необхідних заходів для виявлення, моніторингу та управління технічним боргом?

У цій статті від онлайн школи Foxminded основна увага приділяється тому, technical debt що це, його різним типам, причинам, наслідкам, технічному боргу в Agile та прикладам технічного боргу. Ознайомтеся з нею та отримайте всі необхідні знання про те, як уникнути технічних зобов’язань.

Що таке технічний борг?

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

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

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

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

Визначення технічного боргу

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

Технічний борг в Agile і Scrum

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

Згідно з керівництвом Scrum:

• Власник продукту несе відповідальність за максимізацію цінності та роботи команди розробників.
• Журнал невиконаних вимог продукту є єдиним активом вимог, над яким працюватиме команда розробників, і він має містити в собі все, що потрібно для доступності продукту.
• Під час планування спринту власник продукту обговорює елементи беклогу продукту, які підходять для досягнення мети спринту.

Компанія може запобігти технічному боргу в agile шляхом:

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

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

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

Отже, робота з технічним боргом у Scrum є обов’язком Scrum-команди загалом і, як така, є чудовим прикладом Scrum, вбудованого в систему стримувань і противаг.

FoxmindEd – це навчальний центр, що має велику різноманітність напрямків курсів для новачків та програмістів з досвідом!

Тільки починаєте свій шлях в ІТ? Спробуйте курси Start

Вже маєте базові навички програмування? Тоді
курси Junior саме для вас.

Хочете поглибити свої знання в ІТ? Ми маємо курси Middle/Senior

Види технічного боргу

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

Умисний технічний борг

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

Випадковий/застарілий технологічний борг проєктування

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

Давній технічний борг

Технический долг ухудшается со временем, потому что компонент или система постепенно усложняются из-за множества дополнительных изменений, часто когда над ними работают несколько человек, которые могут не до конца понимать первоначальный дизайн.

Причини технічного боргу

Technical code debt зазвичай виникає, коли рішення з проєктування та впровадження програмного забезпечення суперечать бізнес-цілям і діям.

Технічні борги можуть бути викликані:

• Тиском часу
• Занадто складною технічною конструкцією
• Поганою відповідністю стандартам
• Відсутністю навичок
• Неоптимальним кодом
• Відкладеним рефакторингом
• Недостатнім тестуванням

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

Приклади технічного боргу

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

• Технічний борг у самому коді

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

Проте розробник може написати потворний код або використовувати довгі методи і безліч тимчасових змінних.

• Технічний борг у документації

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

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

• Зміна дизайну системи без зміни організаційної структури

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

• Занадто мало або занадто багато автоматичних тестів

Недостатнє тестове покриття – класична проблема. Складний код складно змінити або провести рефакторинг, а проблеми важче виявити й усунути без автоматичного тестування на рівні інтеграції. Код стає стійким до змін, звідси й технічний обов’язок.

• Переростання моделей баз даних

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

Висновок

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