В конференционном блоке слета IT Campus 2014 (Калужская обл., 25 – 27 июля 2014 г.) состоялся доклад Алексея Петрова на тему «Как перестать беспокоиться и погасить технический долг?». Из него слушатели узнали, что такое «технический долг» проекта и почему разработчики — не единственные, кто должен про него знать; что нужно для выплаты долга, в чём состоят «техническая инфляция» и «техническое банкротство»; когда можно принимать «технический долг» и чего следует опасаться; как оценить «технический долг» и как его правильно погашать. Завершило дискуссию обсуждение мифов и заблуждений, сопровождающих метафору «технического долга», и рассмотрение личного опыта докладчика и участников слета.

1. Как перестать беспокоиться…
и погасить «технический долг»?
Алексей Петров
25 июля 2014 г.

2. Разрешите представиться
АЛЕКСЕЙ ПЕТРОВ
тренер и консультант, эксперт-практик в области
программирования на языках высокого уровня, системного
анализа и программной инженерии, архитектуры ПО,
проектирования средств и методов взаимодействия и БД
2014 — наст. вр.:
преподаватель «Академии информационных систем»
(г. Москва), автор семинара «Как измерить архитектуру ПО?»
2013:
докладчик конференций Stratoplan TECH & BUSINESS
Summit (поток «Проектирование и анализ») и DEV Labs C++
2012 — наст. вр.:
преподаватель НОЦ «Технопарк информационных
технологий», ассистент кафедры «Информационные
технологии и телекоммуникации» НИУ МГТУ им. Н.Э. Баумана
2011 — наст. вр.:
автор серии курсов по разработке, прикладной и
корпоративной архитектуре ПО
2005 — 2011:
участник более 10 проектов внедрения корпоративных ИС,
моделирования бизнес-процессов и ИТ-аудита организаций
2
©Ю.Зайкина,2012

3. О чем пойдет речь?
3
1
2
Когда можно принимать
«технический долг»?
Чего следует опасаться? Проекты с нулевым
долгом
Что такое «технический долг»
проекта?
Почему разработчики — не единственные, кто
должен про него знать?
В чем состоят «техническая инфляция» и
«техническое банкротство»?
3
Признаки чрезмерного долга
Как оценить «технический долг» и как его
правильно погашать? Какие инструменты могут
прийти на помощь?
4
«Технический долг»: мифы и
заблуждения
Личный опыт в enterprise-разработке

4. Знакомьтесь!.. «Технический долг»
Уорд
Каннингем
1992
Назначение метафоры
возможность обсуждения
«неправильной разработки» с
заинтересованными сторонами
нетехнического профиля
1
2
Содержание
временные архитектурные решения
устаревающие и устаревшие
технологии
ошибки и «мертвый» код
нереализованные тесты
невыполненные работы по
рефакторингу продукта
Опасность
выплата «технического долга» стоит
денег, времени и усилий со
стороны разработчиков и
заинтересованных сторон
3
4

5. Принятие «технического долга»
«Да» «Нет»
 Краткосрочное ускорение разработки
 Утрата гибкости и усложнение
изменений
 Рост затрат спонсоров
 Неконтролируемый и «грязный» код
низкого качества
 Чрезмерная специализация
разработчиков
 Возможное «техническое банкротство»
— неизбежная потребность в полном
переписывании продукта
 Замедление разработки
 Упрощение будущих изменений,
гибкость продукта
 Поддержание качественной кодовой
базы и качественного дизайна
 Отсутствие затрат времени на
изучение и рефакторинг кода
 Отсутствие «технической инфляции» —
технологического отставания от
индустрии
5

6. Когда можно принимать
«технический долг»?
1
2
3
Быстрая отгрузка системы
… важнее «чистого» кода («исправим позднее»)
e.g. Близость релиза; реакция на изменения
законодательства
«Одноразовый» код
… принципиально не требует выплат
e.g. Некоторые ETL-процедуры; проекты,
принципиально не предполагающие поддержки
Стратегическое видение
дизайна
… позволяет ценой долга получить оперативный
отклик заказчика и сформировать требуемый
дизайн
e.g. Стремление захватить рынок или создать прототип
6

7. Когда можно брать в долг: график
Сложность
архитектуры
Функциональные
возможности
𝑥0
❶ Стратегическое
видение
𝑓0
𝑓1
𝑥′
𝑥′
′
Хорошая новость
значение 𝐱 𝟎 существует
1
2
Плохая новость
никто не знает, где
𝐱 𝟎 расположена
Удачная архитектура
Неудачная архитектура
𝑥′′
− 𝑥′
— долг
Мартин
Фаулер
7

8. Признаки чрезмерного долга

Дублирование кода и нечитаемый код
Нарушают принципы ОО-проектирования DRY [Don’t Repeat
Yourself] (ср. Single Point of Maintenance) и SCP [Speaking Code
Principle]
Ведут к аномалиям обновления и маскировке истинных целей,
проблемам понимания кода и заставляют разработчиков тратить
больше времени на чтение, чем это необходимо
Панический страх изменений
Добавление новых функций с каждым разом стоит
только дороже
Проблемный дизайн
Содержит «обходные пути» и побуждает к «трюкам»
при разработке
Зависит от знаний одного разработчика
Реализован в коде с множеством пометок на
доработку и исправление
Неверный выбор технологий и библиотек
Предпочтение должно отдаваться новейшим, зрелым и наиболее
«дешевым» в модификации технологиям
ПО устаревает и со временем влечет накопление долга


 8

9. Как оценить «технический долг?»
9

10. Стратегии погашения долга
1
2
3
«Технический налог»
 Эффективное распространение знаний
 Сложность планирования и расстановки
приоритетов
Выплата долга
Основной объем — рефакторинг
Проценты — время, потраченное не на написание
кода
Выделенная команда
 Удобство управления ресурсами и планирования
 Слабость в передаче знаний об архитектуре и коде
 Нарастающая психологическая усталость
10

11. Проекты с нулевым долгом (1 / 2)
1
2
Попытка доказательства
 Проектный треугольник
Гипотеза
 Проекты, реализуемые внутренней командой
(insourcing), накапливают «технический долг»
 Проекты, реализуемые подрядной организацией
(outsourcing), накапливают «технический долг»
 Проекты, реализуемые сообществом
(crowdsourcing), не накапливают «технический долг»
11
Состав работ
(требования), 𝒔
𝛾0 100
0
100
100
0
𝒔 = 𝐜𝐨𝐧𝐬𝐭


12. Проекты с нулевым долгом (2 / 2)
1
2
Попытка доказательства
 Проектный треугольник
Гипотеза
 Проекты, реализуемые внутренней командой
(insourcing), накапливают «технический долг»
 Проекты, реализуемые подрядной организацией
(outsourcing), накапливают «технический долг»
 Проекты, реализуемые сообществом
(crowdsourcing), не накапливают «технический долг»
12
3
Доказательство
 Шестиугольник проектных
ограничений
Бюджет
Состав работ
Краудсорсинговый проект

13. «Технический долг»:
личный опыт enterprise-разработки
1
2
«Технический налог»
Расширенные технические советы
Энтузиазм разработчиков
Оптимально — 1 день в 2 недели (один и тот же,
если позволяет план-график) или в спринте
Продуктовая разработка
Проекты с длительным циклом разработки рано
или поздно всегда переписываются «с нуля»
10%
13

14. Спасибо за внимание!
14
Алексей Петров
Академия информационных
систем: www.infosystems.ru
Россия, 105203, Москва
ул. Первомайская, 126
Тел: +7 (495) 231-30-49
E-mail: security@infosystem.ru

15. Источники
• Вольфсон Б. Стратегия сокращения технического долга // Форум технологий Mail.Ru
Group, 2012.
• Фаулер М. Рефакторинг: улучшение существующего кода. — СПб.: Символ-Плюс,
2003. — 432 с.
• Ergin, L. Technical Debt: Do Not Underestimate the Danger.
• Foote, B., Opdyke, W. ”Life Cycle and Refactoring Patterns that Support Evolution and
Reuse,” First Conference on Patterns Languages of Programs (PLoP’94), Aug. 1994.
• Refactoring. URL: http://refactoring.com
• SonarQube. URL: http://www.sonarqube.org
15
В ходе подготовки доклада использовались:
материалы авторского семинара А.В. Петрова
«Как измерить архитектуру ПО?»
(«Академия информационных систем», 2014)