Читать «Рефакторинг с использованием шаблонов» онлайн - страница 15

1. Вы быстро предоставляете версию 1.0 системы с бредовым кодом.

2. Вы предоставляете версию 2.0 системы, и этот бредовый код только тормозит вашу работу.

3. Как только вы пытаетесь поставить будущие версии, то работаете все медленнее и медленнее, так как никуда не годный код множится. Заканчивается тем, что люди теряют веру в систему, программистов и даже не дорожат больше своими рабочими местами.

4. Где-то в версии 4.0 или немного позже вы осознаете, что не можете победить свою же программу, и начинаете задумываться о том, чтобы полностью переписать весь код.

Этот опыт в весьма значительной степени присущ всей нашей индустрии. Увы, он слишком дорог и делает организации намного менее конкурентоспособными, чем они могли бы быть.

Управляемая тестами разработка и постоянная реорганизация кода

Управляемая тестами разработка (test-driven development) [7] и постоянная реорганизация кода — два из множества превосходных ХР-приемов, поразительно улучшивших мою методику создания программного обеспечения. Я обнаружил, что эти два приема помогли мне и моей организации тратить существенно меньше времени на избыточное и недостаточное проектирование и уделять больше времени созданию высококачественного, функционально богатого кода, причем выпущенного в установленный срок.

Управляемая тестами разработка (TDD) и постоянная реорганизация кода делают возможным результативную эволюцию работающего кода путем превращения программирования в диалог.

• Вопрос. Вы задаете вопрос системе с помощью написанных тестов.

• Ответ. Вы отвечаете на вопросы путем написания кода, успешно проходящего тест.

• Улучшение. Консолидируя идеи, избавляясь от несущественного и проясняя неопределенности, вы улучшаете ответ.

• Повтор. Вы поддерживаете диалог, задавая следующий вопрос.

Такой ритм программирования направляет умственные способности в абсолютно новое русло. Используя TDD, вместо того чтобы тратить много времени на раздумья о проекте, который будет работать для всех нюансов системы, теперь я трачу секунды или минуты, разрабатывая примитивные примеры поведения, корректно работающие перед реорганизацией кода, и выделяя их в следующий необходимый уровень модернизации.

“Красный, зеленый, реорганизация кода,” — заклинание Кента Бека (Kent Beck), направленное на использование TDD и непрерывную реорганизацию кода. Цвета указывают, что вы видите, когда пишете и запускаете тест на выполнение в средстве тестирования модулей (подобных JUnit). Процесс протекает следующим образом.

1. Красный. Вы создаете тест, выражающий то, что ожидается от вашего кода. Тест не проходит (включился красный).

2. Зеленый. Ваша программа исправлена и отлажена каким-то образом, чтобы пройти тест (включился зеленый). В этот момент вы не утруждаете себя написанием простого, ясного проекта без дублирования. Это станет вашей целью позднее, когда тест будет пройден и вы сможете комфортабельно экспериментировать с улучшенными проектами.

3. Реорганизация кода. Вы улучшаете проект кода, прошедшего тест.