Як впоратися з технічним боргом? Обговорюємо 💭

Ставлення до технічного боргу може бути різним: для когось це результат недосконалих і компромісних рішень, а хтось вважає, що не існує ніякого технічного боргу — натомість є непродумана функціональність або завеликий обсяг обовʼязків, покладених на одного фахівця. Але незалежно від ставлення постає питання: що з цим робити?

Спільнота давно шукає відповідь на те, як розв’язувати проблеми з технічним боргом:

Тому діліться, чи є у вас на проєкті технічний борг, як з ним працюєте? Чи є сенс з ним боротись?

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

По-перше, щоб вирішити проблему, потрібно її визнати. Потрібно сформувати беклог, з описами (а не тільки саммері), естімейтами і пріоритетами. Додайте референси: лінки на тех статті, баги, які зумовлені цим боргом. Таким чином ПМ чи замовник (в т.ч. не технічні) можуть зрозуміти проблему. Буває, щоб закрити одну таску, треба спочатку закрити іншу. Нехай цей план буде наглядним.
Коли є беклог, його треба «продати». Не обов’язково починати з масштабних рефакторингів. Почніть з чогось тривіальнішого, наприклад зменшити дублювання коду. Після закриття декількох простіших тасок і появи розуміння і/або довіри в ПМа чи замовника, можна переходити до складніших.
Самі пропонуйте додавання тасок в спринти. Майте під рукою дві-три таски. Вразі блокерів роботи над фічами до вас постукають, якщо будуть знати, що ви маєте, що докинути.
І важливим є також демо закритих тех боргів, наприклад: мінус декілька сотень (чи більше тисячі, раз бачив) рядків коду, закриті баги, пришвидшення CI/CD, зменшення помилок в Sentry.

Коли працював у маленькій геймдев студії, то ми руками інтегрували тексти локалізації — і дуже кортіло якийсь валідатор, щоб не очами то переглядати. Описав необхідні фічі, але воно депріоритизувалося менеджером на фоні інші задач. Що спрацювало, так це докидувати всі локалізаційні баги до тієї задачі і постити у слак «а цю штуку нам би міг валідатор попередити». Десь на п’ятому випадку додали валідатор у спрінт)

По-перше, тре домовитися що технічний борг != застарілі технгології

У вас є якийсь внутрішній сервіс на фреймворку 2010 року? Або ж якийсь сервіс все ще живе в дата центрі? У нього нема CI/CD pipeline? Ці факти, саме по собі, ще не технічний борг.
В багатьох випадках «особливості роботи» старих систем краще задокументувати а не переписувати. Важливий аспект: я про функціонуючі системи, в які не потрібно вносити зміни, не треба додавати нові функціі.

Я вважаю що потрібно зосереджуватися над таким боргом який з`їдає нашу продуктивність щодня. Відповідно, в ідеальному світі, мав би бути перелік «боргів» з кількістю годин які вони відняли в кожну ітерацію. Босс босса дивився б на цей графік, який постійно росте, згадував би кому скільки платитьс я за годину, і сам би прибігав з проханнями взхятися за борги.

Нажаль, не реально, тому можна спиратися на наступні code smells:

— класи/компоненти які постійно потребують втручання. Якщо якийсь файл мінявся більше 50 разів на рік? Він точно SOLID? Скоріше, кандидат на технічний борг.
— занотовувати аналіз багів (регресій) які виявлялися в прод (або ж затримували реліз). Чому розробник зробив помилку? Чому вона не була викрита під час автоматичних етапів тестування? Яка важливість багу (збиток, втрата доходу, втрата даних)? Навіть якщо ви зараз не приймаєте ніяке рішення така інформація знадобиться в майьутньому.
— Security / PII issues окремим рядком. Тут вже можна формувати профсоюз, давити на те що вам всім совість не дозволяє дивитися на незашифровані паролі користувачів в базі даних [, і якщо це буде виправлено ви всі звільнитеся]

---
Історія з життя
Був клас який валідував параметри запиту клієнта. Але складність логіки росла, кількість крайових у мов теж росла... всі зміни проходили детальне code review з 3 рівнями схвалення і прям якихось конкретних лаж там не було.
Але кожен раз коли хтось додавав новий параметр в запит створення інстансу додавався код, який перевіряв сумісність цього конкретного параметру з десятками інших параметрів і станом системи. За три роки моєї роботи цей клас виріс десь з 9000 рядків до 13-14К, будучи при цьому однією функцією.
В такій ситуаціі вже 10%, або ж практика «пишіть код трошки краще» не спрацюють, потірбно було достукатися вгору.
Проаналізувавши результати регресій на prod за 3 місяці я з’ясував що помилки валідаціі були відповідальні за 50% всіх патчей прода, от і була мотивація запланувати рефакторинг (правда робив його вже хтось інший)

Просто коли працюю в якомусь проблемному місці то стараюсь його поправити, а коли зʼявляєтся вільний час, то прошу його виділити на покращення якихось глобальних або структурних проблем. Так як я з 0 пишу проект в самотності, в якого всі фічі описані словами на 3 сторінках, і дизайн присутній лише для 1 сторінки, а всі правки і зміни течуть безкінечним потоком то здебільшого добре знаю всі проблемні місця, де треба було щось швидко зробити, або було прийняте погане рішення. В репортах відмічаю що і де було покращено і чому це зайняло стільки часу і всіх покищо все влаштовує. А в загальному просто роблю свою роботу і стараюсь робити її добре.

1) методичное убеждение всех, с примерами, вот мол тут и тут эта проблема потому что проигнорировали в прошлом то и то. Без истерик, но с упором на факты.

2) Если не получиться добиваться регулярного выделения времени на работу с ТД, в роли аварийной меры — легкое раздувание оценок
+10% скажем, которые тратить на устранение ну самых плохих моментов, которые в будущем в ногу будут стрелять очень сильно. Чтобы проект совсем не превратился в кучу

1) і тут постає питання метрик. Якшо маємо метрику- умовно метрику по кавереджу тестами і по кількості багів знайдених на продакшені, і можемо показати як вони корелюють одна з одною, то аргументація для бізнесу стає зрозуміліша)

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

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

З іншого боку, якщо такий новий стек/технології/фреймворк/тощо зменшить витрати на хостинг «Прод» середовища, чи скоротить час додавання нових фіч і тд — проблем не буде.

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

Якщо тільки фронт чи тільки бек — можна по-тихеньку своє рефакторити в рамках теми тікетів.
Коли треба переписати усе разом:
— кажеш що треба переписати
— відповідають що не бачать сенсу
— потім 15% юзерів застрягнуть так, що не зможуть зробити замовлення
— і сенс раптом з’являється

Просто нужно переписать все с нуля. Дайте время и бюджет.

Недавно піднімали цю тему. Колега сказав класну пораду — в кожному спринті можна виділяти якийсь час — 10% спринта наприклад (кожна друга п’ятниця — це якраз 10% спринта) — на технічний борг.

Але, блін, якщо в технічному борзі лежить якась важка задача, на яку треба годин 80++, то її робити, тестувати, та деплоїти відрізками часу «по 1 дню раз в два тижні» — це дуже неефективно. Таку задачу краще комусь дати, щоб людина занурилась в тему, та зробила за 10 робочих днів підряд.

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

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

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

перш за все хочеться згадати фразу «A mess is not a technical debt. A mess is just a mess» by Uncle Bob. думаю, що проблема не в байдужості розробників, а в відсутності процесу його менеджменту. Від того, що ми вважаємо боргом, як ми його генеруємо (намірено, ненамірено і тд), як ідентифікуємо, хто є його овнером, в якому беклозі зберігаємо і як той беклог власне менеджеримо. імхо не менеджер має бути овнером тех дебту, а архітектор, якшо такий є, або тех лід, якшо архітектора нема. Робота овнера буде власне донести бізнесу (і можливо, менеджменту, якшо його компетенція закінчується на перетягуванні тасочок в джирі) всі можливі ризики, і різонінг за тими чи іншими рішеннями. Враховуючи, шо покращувати теж можна до безкінечності, і є категорія людей, які б завжди покращували, то важливо той тех борг правильно пріорітезувати, ідентифікувати зони, де він для нас найкритичніший (стикався з цікавими метриками по частоті зміни коду і від того пріорітезації тех дебту) і мати достатньо аргументів для того, шоб брати чи не брати його в роботу(аргументів як для бізнесу так і для інженерної команди)

Повністю підтримую. Грамотний менеджмент — це дуже важливо. Думаю, він грає навіть вирішальну роль.

Маю приклад, коли менеджмент в стилі «Сліпий лось несеться через палаючий ліс» приводив навіть хороших девелоперів до написання гівна нашвидкуруч, тому що «у нас немає 80 годин, зробіть на завтра», вимоги в стилі «самі придумайте, що апка має робити», і т.п. І в людей тупо нема виходу, тому що ефективно та красиво працювати в умовах врізаних втричі термінів та тотальної невизначеності — тупо нереально.

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

Якщо хтось зараз скаже — міняй контору (ага, в теперішній час )) ), чи бери процеси в свої руки: люди, відкрийте ОСББ чат та постарайтесь навести там лад. Вийшло? Ото ж бо ;-)

Підписатись на коментарі