2. • CTO at HeadHunter
• CTO at Softline Development
• Автор книги «Гибкие
методологии разработки»
• Спикер (несколько десятков
выступлений)
• Опыт тренера
– Более 20 команд
– Более 150 человек
2
3. • Технический долг
• Виды технического долга
• Стратегии сокращения технического долга
– Технический налог
– Выделенная команда
• Выводы
3
4. Условия
Проекты с длинным • От 2 лет
жизненным циклом • Периодические релизы
• 50-200 человек
Средние коллектив
• Разбит на небольшие команды
4
5. • Design Patterns
• Extreme Programming
• Wiki
• Fit
• Technical Debt
5
6. Что стоит относить к техническому долгу?
• Архитектурные решения
– «Дешевые» сейчас, «дорогие» потом
– Старые технологии
• «Мертвые» фичи
• Мелкие баги
• Тесты
6
7. Как появляется технический долг?
Быстрее Качественнее
• Жертвуем • Жертвуем
внутренним сроками
качеством
7
11. Мелкие баги
• Небольшие минорные баги
• Не относятся к основному функционалу
• Не мешают пользователям
– Пользователи о них могут
даже и не знать
11
13. Тесты
• «Нет времени писать сейчас, напишем позже»
• Нет понимания влияния тестов на дизайн
• Возрастает хрупкость системы
• Изменения становятся очень дорогими
13
14. Старые технологии
1. Старые библиотеки и фреймворки
– Server Side: Apache Torque → Hibernate
– Client Side: Prototype → jQuery
2. Обновление библиотек и фреймворков
– Lucene 2 → Lucene 3
3. Замена «велосипедов» на готовые
библиотеки
14
15. Алгоритм возврата долгов
1. Посчитайте, сколько вы должны
2. Определите, как не увеличивать долг
3. Выберите стратегию по сокращению долга
15
16. Варианты оценок техналога
1. Количество технических задач
2. Общий размер технических задач
3. Эмпирическая оценка задач по рефакторингу
16
18. Выделенная команда
Плюсы Минусы
• Жестко выделенная • Плохое
команда без других распространение
задач заний
• Простота • Быстрое
планирования «выгорание»
команды
18
19. Технический налог
1. Выделенной команды нет
2. Все команды тратят N процентов времени на
уменьшение технологического долга
19
20. Технический налог
Плюсы Минусы
• Распространение • Сложное планирование
знаний между всеми • Низкий приоритет
командами задач по рефакторингу
по сравнению с
продуктовыми
20
21. Когда действительно стоит брать в долг?
1. Близкий релиз с жесткими сроками
– Жесткость сроков реальна
– Срок релиза ~ несколько месяцев
2. Заранее выделить время на последующий
рефакторинг
21
22. Выводы
1. Измеряйте и контролируйте технический долг
2. Не увеличивайте, а лучше сокращайте
технический долг
22
