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

Так же просто, как это звучит, TDD и постоянная реорганизация кода переворачивают мир программирования вверх тормашками Неопытный программист может подумать: “Писать тест для несуществующего кода? Писать код, который проходит тест, а после этого еще и нуждается в реорганизации? Это же расточительный, бессистемный подход к созданию программного обеспечения!”

На самом деле все наоборот. TDD и непрерывная реорганизация кода обеспечивают лаконичный, итерационный и дисциплинированный стиль программирования, максимизирующий концентрацию, отдых и производительность. “Быстрая медлительность”, как описывает его Мартин Фаулер (Martin Fowler) [7], в то время как Вард Каннингем (Ward Cunningham) объясняет, что это более похоже на непрерывный анализ и проектирование, чем на тестирование.

Изучение правильного ритма TDD и непрерывной реорганизации кода требует практики. Мой знакомый программист Тони Мобли (Tony Mobley), описывая этот стиль разработки, считает его таким же большим изменением парадигмы (если не большим), как и переход от структурного программирования к объектно-ориентированному. Как бы долго вы ни привыкали к этому стилю разработки, привыкнув, вы найдете, что создание кода любым другим способом дает ощущение необычности, дискомфорта и даже непрофессионализма. Многие из тех, кто программирует с использованием TDD и непрерывной реорганизации кода, находят, что это позволяет получать такие преимущества:

• снижать количество ошибок;

• без опасений проводить реорганизацию кода;

• создавать более простой и совершенный код;

• программировать без стрессов.

Для изучения всех за и против TDD обратитесь к [4,7]. Чтобы научиться проводить непрерывную реорганизацию кода, достаточно изучить [15] (особенно первую главу), а также примеры реорганизации кодов из этой книги.

Рефакторинг и шаблоны

В различных проектах я наблюдал, какой код реорганизуется и как это делают мои коллеги и я. Используя многие из описанных в [15] примеров реорганизации кода, мы находили места, в которых шаблоны помогали нам улучшать проекты. В такие моменты мы проводили рефакторинг, используя шаблоны и изменяя их применение в нем, при этом мы не заботились о разработке чрезмерно гибких или излишне сложных решений.

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

Эта мотивация может быть легко утрачена, если вы изучите только часть шаблонов проектирования. Например, каждый шаблон в [12] включает раздел, известный как Назначение. Авторы [12] описывают этот раздел так: ’’Краткое утверждение, которое отвечает на такие вопросы: что делает шаблон проектирования, в чем его логическое обоснование и цель, к какому отдельному вопросу или проблеме проектирования он адресован” [12, с. 6]. Несмотря на такое описание, для многих шаблонов проектирования раздел назначения только намекает на то, какую основную проблему решает шаблон. Вместо этого наибольшее внимание уделяется тому, что он делает. Приведу два примера.