В 2003 году издательство "Символ-Плюс" сделало настоящий подарок разработчикам программного обеспечения - увидело свет русскоязычное издание книги Мартина Фаулера "Рефакторинг: улучшение существующего кода" (Refactoring: Improving the Design of Existing Code by Martin Fowler).

Что же такое рефакторинг? "Рефакторинг представляет собой процесс такого изменения программной системы, при котором не меняется внешнее поведение кода, но улучшается его внутренняя структура. При проведении рефакторинга вы улучшаете дизайн кода уже после того, как он написан".

Что дает рефакторинг? Вот некоторые преимущества:

• Рефакторинг улучшает композицию ПО. По мере развития программы то и дело приходится вносить изменения, которые обусловлены текущей необходимостью. Часто изменения вносят программисты, которые не до конца понимают архитектуру ПО, в целом. Поэтому постепенно код становится менее структурированным и разбираться в нем все труднее.
• Рефакторинг облегчает понимание ПО. Проведение рефакторинга обычно приводит к более глубокому пониманию того, как работает программа. Такое понимание существенно ускоряет процесс программирования.
• Рефакторинг помогает найти ошибки. Так как рефакторинг увеличивает понимание кода, то он и позволяет быстрее находить ошибки.
• Рефакторинг позволяет быстрее писать программы. Все вышеперечисленные пункты сводятся к тому, что рефакторинг позволяет быстрее разрабатывать код.

Рефакторинг является одной из основных практик экстремального программирования (XP) и, по сути дела, позволяет создавать хорошую архитектуру программы, но несколько непривычным путем. В традиционном подходе архитектура программы создается еще до того, как написана первая строчка кода. Архитекторы на основе требований к ПО создают диаграммы классов, взаимодействий и все то, что необходимо кодировщикам для написания кода. Конечно, обычно архитекторы - опытные разработчики, но все равно очень сложно сразу создать хорошую архитектуру.

Если полагаться на рефакторинг, то вначале можно сделать лишь предварительный набросок будущей системы, а детали выяснять в процессе разработки. Чем больше разработчики знают о системе, тем больше возникает мыслей по ее улучшению. Мелкие и средние изменения в коде наподобие переименования поля или метода, выделения метода, замены массива объектом, выделения подкласса, выделения иерархии классов и т.п. сами по себе не оказывают огромного влияния на систему, но суммарный эффект часто превосходит все ожидания. Спустя несколько итераций архитектура системы становится стабильной и красивой. Когда программист чувствует целостность и внутреннюю красоту системы, он испытывает удовлетворение от работы.

Может показаться, что такой подход ненадежен. Действительно, для того, чтобы смело полагаться на рефакторинг, необходимо наличие следующих условий:

• Наличие автоматических тестов. Если таковые отсутствуют, то крайне сложно контролировать изменения. Например, вы изменили название метода. Теперь вам надо узнать, где он вызывается. При наличии автоматических тестов это делается элементарно. Если же изменения менее очевидные, то ценность автоматических тестов многократно возрастает.
• Система контроля исходного кода. Управление исходным кодом является одной из главных практик разработки ПО. Если у вас есть работающая версия системы, то вы можете без опасений вносить изменения, потому что всегда сможете вернуться к стабильной версии. Контроль кода дает свободу. Вряд ли кто-то захочет осуществлять рефакторинг, если есть риск потерять пару дней, восстанавливая все как было в случае неудачных изменений.
• Итерационная разработка. Конечно, рефакторинг можно проводить и при обычном водопадном процессе, но его ценность в таком случае несколько уменьшается. Итерации позволяют лучше организовать процесс рефакторинга и сделать его последовательным.
• Регулярность осуществления рефакторинга. Эпизодический рефакторинг - достаточно бесполезное занятие. Только методичное применение может принести ощутимую пользу. Эпизодический рефакторинг может быть даже опасным в случае отсутствия контроля исходного кода.

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

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

Рефакторинг - непростая практика разработки ПО. К счастью, Мартин Фаулер достаточно хорошо умеет объяснять, и в книге много примеров на языке Java. Постепенно после непродолжительной практики приходит понимание рефакторинга и становятся очевидными его преимущества. Читать отвлеченно можно лишь первую и третью части, вторая часть представляет собой справочник, который надо открывать по мере необходимости. Методы рефакторинга имеет смысл осваивать только на практике.

Книга написана замечательно. Издание тоже отличное: твердый переплет, качественный перевод и (ура!) белая бумага. Книга займет почетное место на полке любого хорошего программиста, который стремится к самосовершенствованию. Если вас интересует рефакторинг, много полезной информации можно найти на сайте www.refactoring.com. Сайт автора книги www.martinfowler.com. Саму книгу можно купить в электронном магазине OZ.by (www.oz.by/books/more105087.html).

Михаил ДУБАКОВ,
firefalcon@tut.by