Весняний РОЗПРОДАЖ

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

Всі люди намагаються писати чистий код від початку проекту. Навряд чи знайдеться програміст, який буде навмисно плодити брудний код. Але чому тоді чистий код стає брудним?

Вперше метафору «технічного боргу», щодо брудного коду, запропонував Говард Канінгем.

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

Також, ви можете взяти декілька кредитів одночасно. Ба більше — ви можете набрати стільки кредитів, що сума відсотків переважить ваш сукупний дохід і зробить повне погашення неможливим.

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

Причини появи технічного боргу

Тиск зі сторони бізнесу

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

Відсутність розуміння наслідків технічного боргу

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

Відсутність боротьби з жорсткою обмеженістю компонентів

Це коли проект нагадує моноліт, а не зв’язок окремих модулів. У цьому випадку будь-які зміни однієї частини проекту зачіпають інші. Командна розробка утруднена, так як складно ізолювати ділянки роботи окремих людей.

Відсутність авто-тестів

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

Відсутність документації

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

Відсутність взаємодії між членами команди

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

Довготривала одночасна розробка в декількох гілках

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

Відкладений рефакторинг

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

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

Відсутність контролю за дотриманням стандартів

Кожен учасник проекту пише код так, як вважає за потрібне (так, як він писав на минулому проекті). В результаті код проекту перетворюється у салат зі стилів кодування, ускладнюючи розуміння коду для всіх членів команди.

Відсутність компетенції

Коли розробник просто не вміє писати якісний код.