Що таке технічний борг?
Технічний борг – це абстрактний термін з великою кількістю визначень, що плавають навколо. Вікіпедія пояснює це як “Концепція в розробці програмного забезпечення, яка відображає передбачувані витрати на додаткові переробки, спричинені вибором простого рішення зараз, замість використання кращого підходу, який зайняв би більше часу”.
Інші визначають це як “Попередні технічні рішення, які вже не працюють належним чином для технічної групи, і створюють перешкоду під час створення та впровадження нових функцій, головним чином пов’язаних з ремонтопридатністю коду”. Технічний борг схожий на фінансовий борг, де відсотки виникають у формі дорожчих, повільніших та вкрай неефективних зусиль з розвитку.
На ранніх стадіях запуску існує великий тиск на розробників, щоб вони виривали функції за межі дверей. Здебільшого найкращі практики кодування та архітектури ігноруються, а кути скорочуються, щоб скоротити час виходу на ринок та скористатися альтернативною вартістю.
Ця поспішна розробка програмного забезпечення веде до застарілого коду. Спадковий код не має нічого спільного з епохою програмного забезпечення. Однорічна архітектура може стати спадщиною; все зводиться до того, наскільки важко вдосконалити програмне забезпечення, додаючи нові функції в розумні терміни.
Поширене твердження керівників підприємств, яке ви будете неодноразово чути, полягає в тому, що в перші дні бізнесу функції товару використовувались протягом одного-двох тижнів, а сьогодні це займає 2-3 місяці. Як правило, це супроводжується параноїєю навколо розробників, які стали самозадоволеними. У більшості випадків керівники підприємств не враховують зростаючу складність програмного забезпечення, проблеми, пов’язані з масштабами та продуктивністю, невирішені помилки, залежності та сукупний ефект накопичення технічної заборгованості з часом, що призводить до погіршення ефективності. Це обумовлює більше часу на технічне обслуговування та поступове вдосконалення застарілих систем.
Часто керівникам технологій стає важко переконати своїх колег в інших бізнес-підрозділах у важливості виправлення проблем, випускаючи менше функцій. Це здається марним зусиллям для інших команд, поки щоденний індекс продуктивності не падає настільки, що стає дуже дорогим та трудомістким для розгортання чогось значущого.
Ви починаєте ховати під технічним боргом?
Ось деякі загальні симптоми, які можуть допомогти вам зрозуміти ступінь технічної заборгованості вашої організації:
Значне збільшення часу на випуск нових функцій.
Нові функції та зміни часто порушуються у виробничому середовищі.
Помітне зниження продуктивності програмного забезпечення з часом.
Додавання нових функціональних можливостей призводить до появи невідомих помилок.
Тестування старих і нових функцій стає складнішим із додаванням нових функцій.
Низький моральний дух інженерної команди та високий рівень стресу під час випуску будь-якої нової головної функції.
Відсутність довіри між інженерною командою та іншими підрозділами.
Інші бізнес-підрозділи стають нетерплячими і відмовляються від своїх запитів посередині або починають чинити більше тиску на технічний персонал.
Новим працівникам потрібні місяці, щоб пришвидшити роботу зі застарілою кодовою базою.
Технологічні ініціативи та функції впроваджуються з такою затримкою, що галузь розвивається, а програмне забезпечення застаріває.
Технічний борг зазвичай відображає операційну проблему, а швидкість доставки або продуктивність інженерної групи обернено пропорційна технічній заборгованості.
Деякі загальні причини виникнення технічної заборгованості:
Агресивні бізнес-цілі, які потребують швидкого випуску функцій без належного планування, впровадження чи тестування на ранніх етапах розробки програмного забезпечення.
Надмірне машинобудування є загальною причиною, яка збільшує технічний борг, коли створюється більше функцій, ніж потрібно, і це призводить до збільшення складності.
Постійно зростає потреба додавати більше функцій, майже не враховуючи вдосконалення та обслуговування коду
Зміна пріоритетів та зміна контексту під час розробки ключових функцій.
Відсутність процесів, які заповнюють розрив між бізнесом та технічними потребами, і те, як одна сфера впливає на іншу.
Монолітні програми або негнучка платформа, створені для невеликих випадків використання, але інженерні команди повинні масштабувати їх до нових потреб бізнесу без належного рефактора коду або додаткових оновлень.
Відсутність належних вимог, документації, проектування, випробувань, автоматизації, критеріїв прийнятності, планування потужності, вимог до продуктивності тощо протягом життєвого циклу проекту
Затримка рефакторингу та культури в команді, що заохочує швидкі виправлення порівняно із запланованою довгостроковою оптимізацією коду.
Неправильне використання інструментів та платформ, а також відсутність розуміння молодшими членами команди впливу їх роботи на ціле програмне забезпечення.
Відсутність тренувань та тренувань у команді на різних рівнях.
Отримання коду від сторонніх або підрядних команд, яким потрібна термінова оптимізація коду для тривалого використання перед інтеграцією з поточною екосистемою програмного забезпечення.
Програмна інженерія слідує подібним теоріям з другим законом термодинаміки, який описується як Ентропія програмного забезпечення. Простіше кажучи, коли програмне забезпечення розвивається, його складність зростатиме, якщо не докладати зусиль для його мінімізації, що може призвести до деградації програмного забезпечення. Це схоже на прибирання домашніх справ (миття посуду, винос сміття, прибирання тощо). Якщо це трапляється місяцями, то краще зателефонувати професійній прибиральній бригаді і подумати про новий початок.
Процес рефакторингу коду може призвести до поступового зменшення ентропії програмного забезпечення і, в свою чергу, зменшення технічного боргу.
15 ключових кроків від технічного боргу до технічного багатства:
Навчіть власників товарів та інших підрозділів про справжню вартість технічної заборгованості та чітко сформулюйте цінності бізнесу та їх вплив.
У спринті кількість історій P0 для нових функцій не повинна бути дуже великою. Якщо першочергові нові функції, заплановані для спринту, складають більше 25-30% від загальної кількості функцій, то скорегуйте підхід до планування продукту.
Переконайтесь, що дорожня карта продукту та планування спринту відображають справжню цінність та вплив роботи та враховують вирішення існуючого технічного боргу.
Рефактуйте та модулюйте свій код та архітектуру, розбиваючи монолітні програми на мікросервіси з часом, щоб зменшити ентропію програмного забезпечення.
Впровадити програмування пар для ключових функцій, забезпечити примусове огляд коду, доопрацювати та задокументувати технічні вимоги та вимоги до продукту перед початком розробки та уникнути змін вимог в останню мить.
Не робіть інженерні завдання та оптимізацію коду громадянами другого класу у спринтському плануванні. Як заявив Джоель Спольскі, одним із ключових кроків для вдосконалення коду є виправлення помилок перед додаванням нових функціональних можливостей. Виправте помилки, проблеми з продуктивністю та проблеми масштабування, перш ніж вони стануть перешкодою для продуктивності.
Роз’єднайте функції та вдосконалюйте UI / UX з часом.
Оцініть, використовуючи нові інструменти, мови програмування та фреймворки, які вирішують деякі поточні проблеми безпосередньо замість того, щоб витрачати години на їх вирішення вручну.
Майте чіткі критерії прийнятності або визначення виконаного для нових та існуючих функцій.
Створіть комплексні набори тестів, включаючи модульні, функціональні, інтеграційні та димові випробування. Впроваджуйте безперервну доставку, автоматизоване тестування, тестову розробку для підвищення якості коду.
Вирішуйте швидкі перемоги та створюйте правильну комбінацію функцій, що випускають, з необхідною оптимізацією коду.
Створіть невеликі команди для роботи в різних сферах: а) Оперативні технічні операції та виправлення помилок, б) Впровадження нових додаткових функцій, в) Оптимізація коду та виправлення боргів техніки. Нехай вони працюють без зайвих перебоїв або зміни пріоритетів.
Постійно оцінюйте напрямки вдосконалення, зменшуйте вузькі місця, автоматизуйте ручні завдання, щоб отримати технічне багатство.
Щотижня надавайте розробникам час поза проектами, щоб вивчити та впровадити нові технології та навички для професійного розвитку.
Нагороджуйте членів команди за тих, хто приділяє пильну увагу деталям, порівняно з тими, хто витрачає довгі години, але виробляє неакуратну роботу.
3 пс:
Перестаньте думати про програмне забезпечення як про разовий проект. Подумайте про це як про створення компанії з правильним поєднанням людей, процесів та продуктів (3 P), що буде відповідати довгостроковому баченню компанії. Навчіть керівників підприємств думати про розробку програмного забезпечення, наприклад, про модернізацію вашого будинку з часом – коли щось у будинку ламається, ви виправляєте або замінюєте його на кращі деталі. Не ігноруйте вдосконалення до того моменту, коли вам доведеться знести весь будинок і побудувати його з нуля.
Коли бізнес досягає певної межі, зрозумійте необхідність стабільності та масштабності порівняно з випуском нових функцій у вигляді надмірних наворотів, що справляють незначний вплив.
Охоплюючи технічне багатство на Junglee Games
Протягом багатьох років не тільки інженерна команда, а й усі керівники Junglee Games створили культуру, яка охоплює концепцію технічного багатства. Це, у свою чергу, дозволило нам створювати продукти, масштабні завдяки видатному зростанню компанії. Від написання ігрової платформи на базі мікропослуг до підходу до великих даних для бізнес-аналітики; кожен відділ Junglee Games використовував згадані тут кроки для створення ігор, у які грають мільйони користувачів, і створив глобальну ігрову платформу, позбавлену технічних боргів.
За короткий проміжок часу ми перейшли від 0 до майже 20 мільйонів користувачів, і ми щороку бачимо сотні мільйонів доларів вступних внесків у наших іграх. Як технологічні лідери, ми несемо відповідальність за інвестування часу для узгодження всіх ключових зацікавлених сторін, щоб прийняти постійні зміни як частину створення дивовижної компанії, керованої технологіями.
Це наша подорож, і я з нетерпінням чекаю про вашу подорож від технічного боргу до технічного багатства. Пам’ятайте – ніколи не пізно поставити колеса.
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/every-startups-journey-from-tech-debt-wealth-rajat-teotia/.
Rajat Teotia люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 