Практика непрерывной интеграции заключается в использовании специального программного обеспечения, которое получает свежую версию исходного кода проекта и производит сборку. При наличии проблем выводится и рассылается соответствующее сообщение. Отмечу, что в сборку проекта обязательно входит запуск автоматических тестов. Побочным продуктом являются разного рода отчеты о проекте, которые позволяют проводить анализ его внутреннего качества.
Непрерывная интеграция является своеобразным скелетом экстремального программирования, на который затем добавляются «мускулы» в виде других практик.
Разработка через тестирование и разработка с тестами
Сначала обсудим более традиционную практику – разработку с тестами. При таком подходе программист пишет код, а затем – автоматизированные тесты для него для проверки корректности.
Экстремальное программирование идет дальше и превращает проверку качества в инструмент для создания спецификации и архитектуры. Для этого этап написания тестов переносится в начало цикла разработки.
Цикл разработки в рамках TDD
Такой подход называется разработкой через тестирование или разработкой через тесты (Test Driven Development). Процесс работы разбивается на три этапа:
• красный – пишем неработающий тест;
• зеленый – минимальными усилиями заставляем тест работать;
• рефакторинг – устраняем дублирования и приводим код в порядок.
Для выбора кода, который следует покрыть тестами, можно использовать следующую схему.
Схема для выбора кода
При разработке с тестированием хорошо сразу включить наличие тестов в критерии готовности истории пользователя. Это дисциплинирует разработчиков.
Лия Шабакаева, разработчик
• Простой код – это самый тривиальный код, в котором сложно допустить ошибки и который фактически не требует тестирования. Писать тесты для него необходимо только в минимальном количестве.
• Алгоритмы – это код, реализующий разного рода алгоритмы и бизнес-логику. Он достаточно независим от других частей, и тестировать его необходимо максимально тщательно.
• Связующий код – это код с максимальным количеством зависимостей, что сильно повышает стоимость поддержки модульных тестов для него, поэтому их необходимо писать в минимальных количествах.
• Сложный код – достаточно запутанный код, но для него нужны тесты. Как правило, его можно отрефакторить и сосредоточить в итоге свои усилия на алгоритмах.
В рамках TDD используется следующая практика из экстремального программирования – рефакторинг.
Рефакторинг
Рефакторинг – это изменения исходного кода без изменения функциональности для улучшения внутреннего качества (простота кода, гибкость архитектуры и т. д.). Для проведения рефакторинга желательно знать «запахи кода» и непосредственно приемы рефакторинга (подробнее – в книге «Рефакторинг. Улучшение существующего кода» Мартина Фаулера).
Структура процесса рефакторинга
Парное программирование
При парном программировании код пишется двумя разработчиками за одним компьютером, причем один из разработчиков играет роль «пилота», а второй – «штурмана».
Роли разработчиков при работе в паре
Формальные инспекции кода
Формальные инспекции кода не относятся к экстремальному программированию, эту практику представляет парное программирование. Однако, по статистике, данная практика позволяет находить наибольшее количество дефектов.
Для проведения формальной инспекции кода используют специальные чек-листы. В них указаны правила, которые должен соблюдать программист при разработке кода. Отмечу, что эти правила должны быть нетривиальными и не стоит включать в этот список правила, которые можно проверить автоматически при сборке проекта.
Простота архитектуры и метафора системы
Мы работаем итеративно, поэтому важно иметь максимально простую архитектуру, в которую быстро и дешево вносятся изменения.
