З усіх модних термінів, які вигадав софтверний бізнес, технічний борг є найбільш дратівливим. Я знаю, що це буде спірно, і вже можу уявити, як ревнителі чистої архітектури лютують. Тож дозвольте мені пояснити свою думку.
Що таке технічний борг?
Я запитую під час співбесіди "Яке визначення технічного боргу?" і дивно, що кожен кандидат дає різну відповідь. Схоже, що галузь ще не зійшлася на єдиному визначенні. Я класифікував відповіді наступним чином:
Ось кілька проблем з цими відповідями:
- Відповіді є вагомими, наприклад, що таке "старий код"? 6 місяців, рік...
- Відповіді фокусуються на симптомах, а не на кореневі причині. Наприклад, "код, який ніхто не хоче змінювати?" чому ніхто не хоче до нього доторкатися? через те, що він важкий для зрозуміння, через втрату знань чи через те, що це критична частина для бізнесу і тиск великий?
- Відповіді, де проблема не зовсім зрозуміла. "Код працює повільно" - це проблема? Я працював над скриптом обслуговування, який запускався раз на місяць для очищення дублікатів в історії бази даних. Це займало 3 години. Я не був експертом у SQL і впевнений, що скрипт можна було б оптимізувати, але скрипт виконував свою роботу і ніхто не скаржився.
Я навіть не говорю про егоістичного інженера, який сказав мені, що "код, написаний іншими", є технічним боргом.
Незважаючи на визначення, кожна компанія має технічний борг. Завжди є кусок коду, до якого ніхто не хоче торкатися, який не оптимізований або використовує застарілий фреймворк. Коли я працював на Amazon у 2014 році, частина роздрібного веб-сайту була написана на Perl. Java була новою нормою. Цей код мав 9 років, і всі завжди боялися його змінювати. Ніхто вже не знав Perl, але він працював і щоденно використовувався сотнями тисяч клієнтів.
Одне згодження
Незважаючи на так багато різних визначень, є щось спільне.
Технічний борг поганий! Навколо цього концепту існує багато негативу. Кандидати, які запитали мене "У вас є технічний борг?", були вкрай занепокоєні, коли я відверто сказав так. Деякі навіть сказали, що не хочуть працювати в компанії, яка має технічний борг.
Технічний борг є дорогим
Основним аргументом для виправдання того, що технічний борг поганий, є вартість. Тож я спробував зрозуміти цю вартість. Проте на відміну від позики, де відсоткова ставка вказана в угоді, важко виміряти технічний борг. Я намагався оцінити швидкість команди за бали історій.
Я помітив, що швидкість команди, яка працює над монолітом, була повільнішою, ніж у тієї, яка працює над мікросервісною архітектурою. Через декілька місяців я зрозумів, що проблема була не в технічному боргу. Просто кількість функцій, які треба було підтримувати. Як тільки ми досягли 3 мікросервісів, друга команда стала повільнішою за моноліт, незважаючи на те, що всі казали, що код мікросервісу був чистим і добре архітектурованим. Обтяження утримання декількох сервісів стало проблемою.
На мобільній команді я порівнював швидкість роботи команд Android та iOS. Розробка iOS була швидшою з менше помилками, незважаючи на те, що не використовувалася принципів чистої архітектури.
Щоб бути справедливим, швидкість - поганий показник; вона нестабільна між командами і я дізнався, що не можна на неї покладатися. Якщо ви знаєте гарний показник для технічного боргу, дайте мені знати.
Поважайте те, що було до вас
Розмова про технічний борг може бути узагальнена як: "Вони допустили помилки в минулому, ми зараз знаємо краще". Я вважаю це передчасним. Я пам'ятаю розмову в Amazon у 2014 році. Інженер скаржився на те, що команда вибрала використання "Бівер", внутрішнього ключово-значеннєвого сховища Amazon, практично предка DynamoDB. Він продовжував скаржитися, що SDK для "Бівера" був незручним, а система дозволу не була досить деталізованою. Обидва скарги були справедливими.
Він агресивно запитав: «Чому команда вирішила використовувати це дер**но замість DynamoDB?», а інженер зі стажем у 20 років відповів: «DynamoDB була випущена в 2012 році, цей проект почався в 2009»...
Я вивчив припускати добрі наміри. Команда перед вами мала інші обмеження, але знала, що робила. Якщо ви не розумієте вибору, питайте про контекст рішення. Це могло бути єдиним обґрунтованим вибором на той час.
Чи насправді поганий технічний борг?
Технічний борг почався як метафора, натхненна фінансовою галуззю. Так само, як фінансовий борг, технічний борг нарощує інтерес, що означає, що чим довше він залишається невирішеним, тим більше роботи буде потрібно витратити на його виправлення пізніше. Це був хороший спосіб пояснити, як бізнес-команди пріоритизують роботу з обслуговування над новими функціями. Він перетворився на щось жахливе в екосистемі.
Але чи є борг проблемою? Щоб придбати будинок, ви берете іпотеку і платите щомісячні відсотки та основну суму. Це позитивно, оскільки ви не могли дозволити собі одноразовий платіж. Використання боргу дозволяє вам досягти мети.
Для заснування компанії необхідні початкові фінансування. Підприємці отримують похвалу, коли залучають кошти. Чим більше, тим краще, але вони просто позичають гроші від інвесторів, які очікують прибуток. Технічний борг дозволяє їм досягти цілі. Це як інструмент, це не погана річ. Ось як працює економіка. Це так само і для розробки програмного забезпечення.
Я приєднався до раннього стартапу в 2019 році, у команді було 8 розробників. Через два роки свіжопризначений розробник скаржився, що перший мобільний додаток був побудований за допомогою React Native, а не на нативній технології, наприклад, Swift для iOS. Мені довелося нагадати цій особі, що до того, як компанія перетворилася на швидкозростаючу з 100+ інженерів і 6 спеціалістів з розробки мобільних додатків, перший мобільний додаток створив єдиний фронт-енд інженер. Він не володів жодною носійною мовою, тому він використовував те, що вмів і випустив Мінімально Життєво Важливий Продукт менше ніж за місяць. Благодаря цьому швидкому MVP, компанія здобула тисячі клієнтів.
Разработка з технічним боргом: інструмент або прокляття?
Цей успішний продаж дозволив нам збирати серію B, і завдяки цим коштам ми найняли власного розробника мобільних додатків для створення нативного додатка. Його зарплата була буквально оплачена фінансовим боргом, який був залучений завдяки технічному боргу.
Висновок
Давайте віднесемося до технічного боргу з певним піднесенням. Це інструмент, він не поганий або добрий, все залежить від того, як ви його використовуєте. Якщо ви берете в борг занадто багато грошей і ніколи не сплачуєте відсотки, ви станете перепродані. Але брати довгострокові позики для інвестицій може дати вам час, залучити клієнтів та розблокувати проекти. Це може бути корисно. Тому не забудьте поважати те, що було до вас.
Перекладено з: The Controversial Truth about Tech Debt