TDD как инструмент уменьшения кадровых рисковНиколай ГребневКомпания «CUSTIS»
Содержание• Кадровые риски• Условия задачи• Test Driven Development• Факторы кадрового риска• Как и почему?• Что, где, когда и сколько?• Итоги
КАДРОВЫЕ РИСКИ
Кадры решают всеИ.В. Сталин
Риски• Незаменимый разработчик• «Не знал и сломал»• Квалификация ниже ожидаемой• Обучение новых сотрудников
УСЛОВИЯ ЗАДАЧИ
Команда
Билл Гейтс Мартин Фаулер Джеффри Рихтер Андерс Хейлсберг
Реальность
Отпуск
Проект
Смена сотрудника
Проект
Новый сотрудник
Проект
TEST DRIVEN DEVELOPMENT
Test Driven Development— техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест. (Wikipedia)
TDD
Написать тест
Написать реализацию
Запустить тесты
Тесты не прошли
Все тесты проходят
TDD – unit-тесты вперед!
Unit-тестирование• Тестируем:
– Класс• Поведение• Взаимодействие
Одновременно тестируем только один класс
ФАКТОРЫ КАДРОВОГО РИСКА
Причины• Сильносвязная архитектура• Позднее обнаружение ошибок• Плохая документированность
Сильносвязная архитектура
Правки исходного кода ведут к непредсказуемым последствиям
Изменения
Ошибки
Ошибки
Держать все в голове
Цена ошибки
Разработка
Тестирование
Эксплуатация
Тестирование
Эксплуатация
Разработка
Плохая документированность• Документация устаревает сразу после
своего написания• Никто не поддерживает актуальность
документации• Зачастую документация вообще отсутствует
КАК И ПОЧЕМУ?
Тестируем• Класс
– Поведение– Взаимодействие
Одновременно тестируем только один класс
Зависимость
Inversion of Control
Декомпозиция
Локализация ошибок
Изменения
Ошибки
Раннее обнаружение ошибок• Тесты запускаются:
– Регулярно во время разработки– До окончания этапа разработки
Раннее обнаружение ошибок
Тестирование
Эксплуатация
Разработка
Документация• Всегда актуальна• Автоматическая проверка соответствия
спецификациям
ЧТО, ГДЕ, КОГДА И СКОЛЬКО?
Что?• Высокое качество конечного продукта• Хороший дизайн кода• Уверенность при модификации• Снижение рисков от незаменимых и
неопытных разработчиков
Где?• Длительные проекты• Высокие требования к качеству• Опытная команда (есть опыт
использования TDD)
Когда?• С начала проекта• На изолированных участках в
существующем проекте
Сколько?• Нет опыта применения TDD:
– Дорого• Есть опыт использования TDD:
– Тратим время на написании теста– Экономим на отладке и сопровождении
ПОДВОДИМ ИТОГИ
Вспомним риски• Незаменимый разработчик• «Не знал и сломал»• Квалификация ниже ожидаемой• Обучение новых сотрудников
Незаменимость vs TDD• Любого человека возможно заменить:
– Система хорошо документирована– Слабая связность– Покрытие тестами
«Не знал и сломал» vs TDD• Любые правки исходного кода безопасны:
– Высокая изолированность классов– Обнаружение ошибок на этапе разработки– Жесткое соблюдение контракта класса
Обучение и TDD• Обучение на «боевых» задачах
– Скорость обучения возрастает– Слабая связность– Формально документированное
взаимодействие в системе
Recommended
