– Вы когда-нибудь чинили автомобиль при помощи скотча и скрепок? – поинтересовался Джастин. – Так вот, это похожий случай.
Все переглянулись и поняли: впереди много бессонных ночей.
Основные практики ХР
Существует 13 основных практик экстремального программирования, которые могут помочь команде найти входы и выходы в разработке программного обеспечения и создавать легко изменяемый код. В отличие от scrum-практик, многие ХР-практики имеют особенности и направлены на решение самых распространенных проблем, провоцирующих создание плохого кода. В этих практиках все настолько тесно связано с программированием, что многие люди ошибочно считают: XP – это только для высококвалифицированных специалистов.
В этой главе мы поговорим о 10 основных практиках XP. Эти 10 практик разделены на четыре категории – программирование, интеграция, планирование и команда, – чтобы их легче было понять и удержать вас от заблуждения, будто методика XP пригодна только для суперразработчиков.
Две основные практики XP – разработка через тестирование и парное программирование – предназначены специально для программистов и помогают им писать более качественный код. Они сосредоточены на нескольких важных аспектах разработки программного обеспечения. Созданием автоматизированных тестов перед написанием кода и его последующим тестированием команды повышают качество программного обеспечения. Работая вдвоем на одном компьютере, разработчики более тщательно вычитывают код в поиске ошибок.
Когда программист делает разработку через тестирование, которую обозначают аббревиатурой TDD (test-driven development), он создает автоматизированный тест перед тем, как начнет писать код. И пока код продукта не написан, тест будет завершаться провалом. Программист понимает, что код работает, когда тест оказывается пройден. Это создает петлю жесткой обратной связи, помогающую предотвратить появление дефектов: сначала написание проверочных тестов, затем создание кода, способного их пройти, поиск проблем и путей их решения и написание дополнительных проверочных тестов. Такие автоматизированные тесты обычно называют модульными. Слово «модуль» используется неслучайно: почти во всех языках программирования код очевидным образом разделяется на модули (классы, методы, функции, подпрограммы и т. д.), и практически любой язык предоставляет как минимум один способ создания и запуска автоматических тестов, которые привязаны к каждому из этих модулей. Создав вначале тесты, программист гарантирует, что все написанные им модули будут работать корректно.
Разработка через тестирование позволяет убедиться лишь в том, что каждый отдельно взятый модуль работает. Это также помогает командам предотвратить некоторые из самых распространенных и серьезных проблем, которые могут создать трудности в ходе поддержки кода. Можно внести изменения в одну часть кода и обнаружить, что неожиданно появились ошибки в другой части, которая, казалось бы, никак не связана с первой. И это только потому, что разработчик не подозревал о существовании зависимости между ними. Когда программист пишет модульные тесты, использующиеся каждый раз при сборке кода, эти автоматизированные тесты помогают избежать появления зависимостей, которые, оставшись невыявленными, приведут к немедленному сбою. Тесты помогают программисту заметить проблему, прежде чем она окажется встроенной в общий код и ее будет трудно удалить. Кроме того, модульные тесты помогают разработчикам писать код, который легче использовать повторно. Например, программист может создать класс Java, работа с которым чрезмерно усложнена: использовать в нем сбивающие с толку имена, неудобную инициализацию или другие структурные проблемы, которые смогут легко пробраться в код любого разработчика. Когда программист создает модульный тест, использующий такой класс, изъян может стать очевидным и, так как код класса еще не написан, разработчику несложно устранить этот изъян. Затем модульный тест становится частью исходного кода, так что другие программисты могут опираться на него, чтобы увидеть, как этот метод предполагалось использовать.