Виграш неможливий. Тільки ви вирішуєте, наскільки швидко програти
Який наступний хід?
Багатьом подобається тетріс, мені теж. Пам’ятаю, як зіграв в перший раз на Nintendo Game Boy мого друга. Можливо, у вас в голові теж застрягла та мелодія. Тетріс не тільки одна з кращих ігор всіх часів, але й чудова аналогія для технічного боргу. Вона дає загальне розуміння технічного боргу та його впливу.
Розповім ще історію з особистого досвіду, як моя команда зменшила технічний борг в якомусь биллинговом коді і при цьому виправила помилку на мільйон доларів на рік.
Спочатку простіші завдання, на низькому рівні складності
В софтверних компаніях менеджери по продуктах/проектів разом з розробниками визначають код, який буде написаний і відправлений клієнтам в найближчому релізі. Завершення рядка в тетрисе схоже на випуск функції.
Складні функції цілком можуть бути реалізовані майже без збільшення технічного боргу
Випуск складної функції вимагає завершення декількох рядків.
Часто бізнес-потреби (нові функції, нові продукти) ведуть до компромісів у коді (хакі, обхідні шляхи), щоб не прострочити дедлайн. Чи зміни в стратегії продукту несумісні з попереднім дизайном, вимагаючи додаткових зусиль для міграції клієнтів або підтримки «нової», так і «старої» логіки.
Невеликий технічний борг є нормальним і керованим
Подібні сценарії створюють технічний борг в рамках коду. Прихований пропуск в тетрисе являє собою технічний борг.
У будь-якого коду є технічний борг. Це нормально. Ви можете продовжувати грати з декількома пропусками.
Похований в технічному борг
Занадто великий технічний борг не дозволяє за розумний час випустити нову функцію або виправити помилку.
Цю проблему не вирішити додаванням нових розробників або, що більш драматично, заміною існуючих. Це називається технічним боргом: у якийсь момент його доведеться виплатити.
Погашення технічного боргу робить вас конкурентоспроможними. Це тримає вас у грі.
Game over
Подібно управління бізнесом, в тетрисе складність з часом зростає. Фігури рухаються швидше, і за ними важче наздогнати.
Як і в бізнесі, тут неможливо виграти. Немає реальної фінішної риси. Питання тільки в тому, як скоро ви програєте.
Подібно бізнесу, занадто багато прогалин у тетрисе веде до програшу.
Баг на мільйон доларів
Не так давно моїй команді доручили відновити логіку виставлення рахунків/інвойсів в коді нашого продукту для підтримки нових цінових планів, нового платіжного процесора і поліпшення всього процесу виставлення рахунків в цілому. Деякі деталі ще з’ясовувалися, тому ми використали цей час для глибокого занурення в існуючий код, щоб дати більш точні оцінки майбутніх змін.
Основне завдання цього коду полягала в тому, щоб пройти по рахунках усіх клієнтів, розрахувати кожного — і відправити інформацію в API для виставлення інвойсів. Система була написана з великою обережністю і благими намірами — не стільки неохайно, скільки негнучке. Монолітна функція. Ніяких тестів. Дуже мало логів. Документація практично відсутня. Відбувалася якась незрозуміла рандомізація. Систему написав більше п’яти років тому один із засновників. Єдині зміни з тих пір зробив один з перших співробітників, який вже був у компанії.
Була проблема взагалі? Рахунки виставлялися. Компанія заробляла гроші. Не було ніяких ознак проблеми. Все це говорило проти рефакторінгу, але ми знали, що настають великі зміни: ця функція не зможе масштабуватися для наших потреб, і буде набагато простіше рухатися далі, якщо спростити цю частину.
За один спринт ми переробили функцію і додали деякі настільки необхідні логи. Тоді-то ми і виявили, що насправді полагодили. Хтось з бухгалтерів зупинився у наших столів і запитав, чому кількість вихідних інвойсів несподівано збільшилася. Старий код нишком відвалювався по таймеру — і деякі клієнти не оброблялися. Дивна рандомізація? Вона приховувала будь-які моделі, які могли б дати зрозуміти, що якомусь клієнту не виставили інвойс. Коли ми провели оцінку, то нарахували відсутніх інвойсів більш ніж на $1 млн за рік.
Виплата не завжди окупається
Хоча історія повністю правдива, виплата технічного боргу не завжди має такий драматичний ефект. Нам пощастило.
Знайти правильний баланс технічного боргу
Хотів би я дати мудру пораду, коли потрібно розплачуватися з технічним боргом. На жаль, відповідь у тому, що це складно, і це завжди зводиться до балансу. У вас може бути найчистіший, самий добре протестований код в світі, але не бути клієнтів. І навпаки, ваша компанія може працювати дійсно в брудному коді, але який радує клієнтів, а гроші течуть рікою.
Я можу тільки сказати, що і власники продукту, і розробники повинні розуміти суть технічного боргу і що його не можна уникнути назавжди. Зрештою, як і в тетрисе, тут ви ніколи не зможете перемогти.
