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

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

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

Цей підхід має принаймні такі переваги:

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

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

Які позитивні переваги ви побачили від очищення бази коду та позбавлення себе технічної заборгованості? Які методи ви використовували для виконання роботи?

Я можу навести один приклад зі свого досвіду.

Близько 10 чи 12 років тому я успадкував заявку від команди розробників, яка врешті-решт покинула компанію (занадто довго, щоб потрапити сюди ...). Ця система була великою системою генерації звітів про домашнє виробництво. Він проводився щовечора ввечері і генерував близько двох десятків звітів Excel для вищих керівників компанії Fortune 500. Коли я успадкував це, то пробіг близько 5-6 годин, і протягом будь-якого тижня не вдалося принаймні 2 ночі.

Я не був щасливим туристу, який мені дав цей безлад.

Спочатку мій план полягав у тому, щоб просто зупинити кровотечу та виправити головну причину збоїв. Після того, як мені стало комфортніше з базою коду, я почав шукати місця, де я міг би переробити та додати стабільність та продуктивність. Протягом 2-х років я зробив багато, багато змін у системі. Ми віддалили цю систему пару років тому, і в цей момент весь процес зайняв 45 хвилин, і протягом багатьох років не виникало жодних проблем.

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

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

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

усунення технічної заборгованості дає меншу технічну підтримку та кращу основу для покращення

завжди

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

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

Щодо останніх двох моментів: я розумію, звідки це походить, як це було пояснено у його початковій публікації :

Або можливо переназначити деяких розробників для виконання цих технічних питань, тоді як інша частина команди продовжує роботу, орієнтовану на користувача? Це може вплинути на швидкість команди, але що робити?

"Отже, що" дорівнює: власник продукту та інші бізнесмени стають нещасними. А коли мама нещасна, всі нещасні.

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

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

Найбільша вигода, яку отримуватиме організація внаслідок погашення технічного боргу, - це уникати складних відсотків. У наведеному нижче блозі є приклад, який показує, як основна сума боргу за технічну заборгованість перейшла з 160 тис. До 430 тис. Доларів лише за п'ять років. Потрібен був би штатний програміст, виключно присвячений обслуговуванню такої суми боргу. Це допоможе поставити його в перспективу для осіб, які приймають рішення!

З blog.acrowire.com .