Как перестать беспокоиться…

и погасить «технический долг»?

Алексей Петров

25 июля 2014 г.

Разрешите представиться

АЛЕКСЕЙ ПЕТРОВ тренер и консультант, эксперт-практик в области программирования на языках высокого уровня, системного анализа и программной инженерии, архитектуры ПО, проектирования средств и методов взаимодействия и БД

2014 — наст. вр.: преподаватель «Академии информационных систем» (г. Москва), автор семинара «Как измерить архитектуру ПО?»

2013: докладчик конференций Stratoplan TECH & BUSINESS Summit (поток «Проектирование и анализ») и DEV Labs C++

2012 — наст. вр.: преподаватель НОЦ «Технопарк информационных технологий», ассистент кафедры «Информационные технологии и телекоммуникации» НИУ МГТУ им. Н.Э. Баумана

2011 — наст. вр.: автор серии курсов по разработке, прикладной и корпоративной архитектуре ПО

2005 — 2011: участник более 10 проектов внедрения корпоративных ИС, моделирования бизнес-процессов и ИТ-аудита организаций

2

© Ю

. За

йк

ин

а,

2012

О чем пойдет речь?

3

1

2

Когда можно принимать «технический долг»? Чего следует опасаться? Проекты с нулевым

долгом

Что такое «технический долг» проекта? Почему разработчики — не единственные, кто

должен про него знать?

В чем состоят «техническая инфляция» и «техническое банкротство»?

3

Признаки чрезмерного долга Как оценить «технический долг» и как его

правильно погашать? Какие инструменты могут прийти на помощь?

4

«Технический долг»: мифы и заблуждения Личный опыт в enterprise-разработке

Знакомьтесь!.. «Технический долг»

Уорд

Каннингем

1992

Назначение метафоры возможность обсуждения

«неправильной разработки» с заинтересованными сторонами нетехнического профиля

1

2 Содержание временные архитектурные решения

устаревающие и устаревшие технологии

ошибки и «мертвый» код

нереализованные тесты

невыполненные работы по рефакторингу продукта

Опасность выплата «технического долга» стоит

денег, времени и усилий со стороны разработчиков и заинтересованных сторон

3

4

Принятие «технического долга»

«Да» «Нет»

Краткосрочное ускорение разработки

Утрата гибкости и усложнение изменений

Рост затрат спонсоров

Неконтролируемый и «грязный» код низкого качества

Чрезмерная специализация разработчиков

Возможное «техническое банкротство» — неизбежная потребность в полном переписывании продукта

Замедление разработки

Упрощение будущих изменений, гибкость продукта

Поддержание качественной кодовой базы и качественного дизайна

Отсутствие затрат времени на изучение и рефакторинг кода

Отсутствие «технической инфляции» — технологического отставания от индустрии

5

Когда можно принимать «технический долг»?

1

2

3

Быстрая отгрузка системы … важнее «чистого» кода («исправим позднее»)

e.g. Близость релиза; реакция на изменения законодательства

«Одноразовый» код … принципиально не требует выплат

e.g. Некоторые ETL-процедуры; проекты, принципиально не предполагающие поддержки

Стратегическое видение дизайна … позволяет ценой долга получить оперативный

отклик заказчика и сформировать требуемый дизайн

e.g. Стремление захватить рынок или создать прототип

6

Когда можно брать в долг: график

Сложность

архитектуры

Функциональные

возможности

𝑥0

❶ Стратегическое

видение

𝑓0

𝑓1

𝑥′ 𝑥′′

Хорошая новость значение 𝐱𝟎 существует

1

2 Плохая новость никто не знает, где

𝐱𝟎 расположена

Удачная архитектура

Неудачная архитектура

𝑥′′ − 𝑥′ — долг

Мартин

Фаулер

7

Признаки чрезмерного долга

Дублирование кода и нечитаемый код Нарушают принципы ОО-проектирования DRY [Don’t Repeat

Yourself] (ср. Single Point of Maintenance) и SCP [Speaking Code Principle]

Ведут к аномалиям обновления и маскировке истинных целей, проблемам понимания кода и заставляют разработчиков тратить больше времени на чтение, чем это необходимо

Панический страх изменений Добавление новых функций с каждым разом стоит

только дороже

Проблемный дизайн Содержит «обходные пути» и побуждает к «трюкам»

при разработке

Зависит от знаний одного разработчика

Реализован в коде с множеством пометок на доработку и исправление

Неверный выбор технологий и библиотек Предпочтение должно отдаваться новейшим, зрелым и наиболее

«дешевым» в модификации технологиям

ПО устаревает и со временем влечет накопление долга

8

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

9

Стратегии погашения долга

1

2

3

«Технический налог» Эффективное распространение знаний

Сложность планирования и расстановки приоритетов

Выплата долга Основной объем — рефакторинг

Проценты — время, потраченное не на написание кода

Выделенная команда Удобство управления ресурсами и планирования

Слабость в передаче знаний об архитектуре и коде

Нарастающая психологическая усталость

10

Проекты с нулевым долгом (1 / 2)

1

2 Попытка доказательства Проектный треугольник

Гипотеза Проекты, реализуемые внутренней командой

(insourcing), накапливают «технический долг»

Проекты, реализуемые подрядной организацией (outsourcing), накапливают «технический долг»

Проекты, реализуемые сообществом (crowdsourcing), не накапливают «технический долг»

11

Состав работ

(требования), 𝒔

𝛾 0 100

0

100

100

0

𝒔 = 𝐜𝐨𝐧𝐬𝐭

Проекты с нулевым долгом (2 / 2)

1

2 Попытка доказательства Проектный треугольник

Гипотеза Проекты, реализуемые внутренней командой

(insourcing), накапливают «технический долг»

Проекты, реализуемые подрядной организацией (outsourcing), накапливают «технический долг»

Проекты, реализуемые сообществом (crowdsourcing), не накапливают «технический долг»

12

3

Доказательство Шестиугольник проектных

ограничений

Бюджет

Состав работ

Краудсорсинговый проект

«Технический долг»: личный опыт enterprise-разработки

1

2

«Технический налог» Расширенные технические советы

Энтузиазм разработчиков

Оптимально — 1 день в 2 недели (один и тот же, если позволяет план-график) или в спринте

Продуктовая разработка Проекты с длительным циклом разработки рано

или поздно всегда переписываются «с нуля»

10%

13

Спасибо за внимание!

14

Алексей Петров

Академия информационных

систем: www.infosystems.ru

Россия, 105203, Москва

ул. Первомайская, 126

Тел: +7 (495) 231-30-49

E-mail: security@infosystem.ru

Источники

• Вольфсон Б. Стратегия сокращения технического долга // Форум технологий 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)