Про роботу · 27 листопада 2023, 16:00 2384

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

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

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

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

Теми: технічний борг

👍ПодобаєтьсяСподобалось3

До обраногоВ обраному2

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Олег Дорожко 12.03.2024 22:38

Пишу тут собі алгоритм для трейдингу — код страшний, брудний (хоч і робочий)
І прийшла думка — «а може тут треба ось так зробити: спочатку пишемо код, а тоді його робимо красивим. Це дві задачі, які дуже розрізняються між собою. Можливо треба делегувати.»
І тоді може взагалі у IT виробництві потрібні не тільки дебагери (ті що баги вловлені юзерами відшукують та виправляють) але й прикрашальники коду
Якщо нема окремих дебагерів та прикрашальників — то буде борг.
Це як не прибирати робоче місце — буде засмічене воно.

Відповісти

Підтримати

Andriy Vankovych Frontend developer в Kindgeek 01.12.2023 23:20

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

Відповісти

Підтримати

Olena Sharovar Node.js/JS в Waverley 11.03.2024 23:12

Ага. Ти підготував беклог з 50 тасками по техборгу, а замовник придумав 50 нових фіч які він хоче імплементувати, вгадайте — які тікети ви будете робити в наступному спринті?

Якщо воно не крітікал, замовник завжди поставить свої задачі вище пріоритетом ніж ваше/наше «зменшив рядки коду» чи «прискорив на 30 секунд білд»

Відповісти

Підтримати

Andriy Vankovych

Volodya Novostavsky Працює в EPAM 12.03.2024 11:40

Продукт під замовлення (аутсорс, сервісний бізнес), як правило, роблять для якогось замовника, і він для нього має виконувати якісь задачі, а не «милувати око який він красивий і досконалий». Часто замовник краще знає що ЙОМУ потрібно для бізнесу, ніж розробник. Часто буває, що нова фіча важливіша, за покращення старого, яке і так якось працює. Така правда життя. Хто платить гроші, той замовляє ~~музику~~ розробку.

Відповісти

Підтримати

BodjaSyper QA Engineer 12.03.2024 11:53

Так, і правильно зробить. Багато іт-шників живуть в свому світі і не розуміють що є потреби бізнесу, що код пишеться не заради коду. Є конкретні бізнес потреби які потрібно вирішувати, і тому рефакторити якийсь функціонал яким майже не користуються, тоді коли бізнес чекає нову фічу щоб залучити нових клієнтів і нові гроші — не гуд.
Звісно, як і кожену дискусію, цю можна завершити «we just need to find a right balance», тому так, тех борг треба теж зменшувати періодично. Просто спостереження з моєї сторони полягає в тому що багато працівників не шарять за бізнес а якому працюють. Закривати тікети в джирі — приносить гроші виключно індивідувально їм, не компанії.

Відповісти

Підтримати

Mykola Konovalov 29.11.2023 10:14

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

Відповісти

Підтримати

Сергій Осипчук 29.11.2023 08:59

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

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

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

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

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

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

Відповісти

Підтримати

Володимир Цюмра Junior Java/Gosu Developer 11.03.2024 22:05

Теж маю такий приклад:
В нас в проекті є закінчення платіжки по страхівці де все проходить через один метод. Через те, що маємо кілька сценаріїв, такі як модифікація, поновлення, і створення нової стахівки. Ну і кожен раз треба щось додати в цей метод, бо їм треба інакший план перевірити, то треба для поновлення страхівки якийсь новий документ зробити, чи платіжний метод, який для інакшого плану не треба. І додавалась вона не окремими методами, а просто if і все буде в порядку.
Вже почали задавати собі питання коли метод був 300+ рядочків з 15 if і різними приватними методами в придачу.
Бачив там і код який немає змісту (object.setValue(object.getValue) + то все не було покрито тестами.
Рефракторинг десь зайняв тиждень, зменшив все в 3 рази напевно, поділив на сервіси, відповідно до сценарію і кроку, покрив тестами.
Хоча і так до ідеалу ще б додатковий тиждень треба було. Але менеджери тиснули що вже треба і на вчора.
І то виділили час на поправку після 10 багу в стилі, при зміні страхівки там щось не працює, а коли поправили перестало працювати для створення нової.

Відповісти

Підтримати

Сергій Осипчук

Melissa O Huynh 28.11.2023 16:20

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

Відповісти

Підтримати

Dmitry 28.11.2023 15:08

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

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

Відповісти

Підтримати

Yaroslav Mota Solutions Architect, Head of Engineering Excellence в N-iX 28.11.2023 15:50

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

Відповісти

Підтримати

serhii 28.11.2023 14:58

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

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

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

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

Відповісти

Підтримати

Олег Front End Lead 28.11.2023 14:53

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

Відповісти

Підтримати

Aaron A. Stockton 28.11.2023 13:53

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

Відповісти

Підтримати

Olena Sharovar Node.js/JS в Waverley 27.11.2023 23:17

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

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

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

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

Відповісти

Підтримати

anonymous 28.11.2023 14:38

-

Відповісти

Підтримати

Renatö Koločenko 27.11.2023 21:37

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

Відповісти

Підтримати

Yaroslav Mota Solutions Architect, Head of Engineering Excellence в N-iX 27.11.2023 16:29

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

Відповісти

Підтримати

Pavlo Osypov Mobile Flutter dev (iOS/Android) в Intobi 28.11.2023 13:50

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

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

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

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

Відповісти

Підтримати

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

Ваша пошта

Не підписуватись