Что такое рефакторинг. Рефакторинг: кода, сроки проведения, применение

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

Энциклопедичный YouTube

1 / 5

✪ Рефакторинг кода

✪ Признаки плохого программиста

✪ Основа рефакторинга:: SOLID:: Single Respnosibility:: Spring

✪ Знакомство с JavaScript #8 - Рефакторинг

✪ Книги для программистов Java Enterprise

Субтитры

Цели рефакторинга

Цель рефакторинга - сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным.

Рефакторинг следует отличать от оптимизации производительности . Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет её работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу .

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

Причины применения рефакторинга

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

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

Признаки плохого кода

Во многом при рефакторинге лучше полагаться на интуицию, основанную на опыте. Тем не менее имеются некоторые видимые проблемы в коде (англ. code smells ), требующие рефакторинга:

длинный метод;
большой класс;
длинный список параметров;
«жадные» функции - это метод, который чрезмерно обращается к данным другого объекта;
избыточные временные переменные;
классы данных;
несгруппированные данные.

Рефакторинг кода

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

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

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

Методы рефакторинга

Выделение метода (Extract Method)

Выделение метода заключается в выделении из длинного и/или требующего комментариев кода отдельных фрагментов и преобразовании их в отдельные методы, с подстановкой подходящих вызовов в местах использования. В этом случае действует правило: если фрагмент кода требует комментария о том, что он делает, то он должен быть выделен в отдельный метод. Также правило: один метод не должен занимать более чем один экран (25-50 строк, в зависимости от условий редактирования), в противном случае некоторые его фрагменты имеют самостоятельную ценность и подлежат выделению. Из анализа связей выделяемого фрагмента с окружающим контекстом делается вывод о перечне параметров нового метода и его локальных переменных.

Перемещение метода (Move Method)

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

Замена условного оператора полиморфизмом (Replace Conditional with Polymorphism)

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

Основные принципы:

Проблемы, возникающие при проведении рефакторинга

проблемы, связанные с базами данных;
проблемы изменения интерфейсов;
трудности при изменении дизайна.

Цели рефакторинга

Цель рефакторинга - сделать код программы легче для понимания; без этого рефакторинг нельзя считать успешным.

Причины применения рефакторинга

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

Признаки плохого кода

Во многом при рефакторинге лучше полагаться на интуицию, основанную на опыте. Тем не менее имеются некоторые видимые проблемы в коде (англ. code smells ), требующие рефакторинга:

длинный метод;
большой класс;
длинный список параметров;
«завистливые» функции - это метод, который чрезмерно обращается к данным другого объекта;
избыточные временные переменные;
классы данных;
несгруппированные данные.

Рефакторинг кода

Иногда под рефакторингом неправильно подразумевают коррекцию кода с заранее оговоренными правилами отступа, перевода строк, внесения комментариев и прочими визуально значимыми изменениями, которые никак не отражаются на процессе компиляции, с целью обеспечения лучшей читаемости кода (см. code formatting).

Методы рефакторинга

Выделение метода (Extract Method)

Перемещение метода (Move Method)

Замена условного оператора полиморфизмом (Replace Conditional with Polymorphism)

Основные принципы:

Проблемы, возникающие при проведении рефакторинга

проблемы, связанные с базами данных;
проблемы изменения интерфейсов;
трудности при изменении дизайна.

Средства автоматизации рефакторинга

Технические критерии для инструментов рефакторинга:

базы данных программы;
деревья синтаксического разбора;
точность.

Практические критерии для инструментов рефакторинга:

скорость;
отмена модификаций;
интеграция с другими инструментами.

Примечания

См. также

Литература

Фаулер М. , Бек К., Брант Д., Робертс Д., Апдайк У. Рефакторинг: улучшение существующего кода = Refactoring: Improving the Design of Existing Code (2000). - Спб: Символ-Плюс, 2009. - 432 с. - 3000 экз. - ISBN 5-93286-045-6
Скотт В. Эмблер, Прамодкумар Дж. Садаладж Рефакторинг баз данных: эволюционное проектирование = Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series). - М .: «Вильямс», 2007. - 368 с. - ISBN 0-321-29353-3
Джошуа Кериевски Рефакторинг с использованием шаблонов = Refactoring to Patterns. - Вильямс, 2008. - 400 с. - ISBN 5-93286-045-6

Ссылки

Что такое рефакторинг? (англ.)
Домашняя страница Мартина Фаулера о рефакторинге (англ.)
Ксензов Михаил Рефакторинг архитектуры программного обеспечения: выделение слоев . - Рассматривается один из основных методов рефакторинга архитектуры ПО – выделение слоев, а также его место в контексте рефакторинга архитектуры как многошагового итеративного процесса. Архивировано из первоисточника 25 августа 2011. Проверено 30 ноября 2007.

Wikimedia Foundation . 2010 .

Смотреть что такое "Рефакторинг" в других словарях:

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

Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

- (паттерн, англ. design pattern) это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения. Паттерн не является законченным… … Википедия

Шаблоны проектирования (паттерн, англ. design pattern) это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения. Паттерн не … Википедия

Концепция «рефакторинга» (refactoring) возникла в кругах, связанных со Smalltalk, но вскоре нашла себе дорогу и в лагеря приверженцев других языков программирования. Поскольку рефакторинг является составной частью разработки структуры приложений (framework development), этот термин сразу появляется, когда «структурщики» начинают обсуждать свои дела. Он возникает, когда они уточняют свои иерархии классов и восторгаются тем, на сколько строк им удалось сократить код. Структурщики знают, что хорошую структуру удается создать не сразу - она должна развиваться по мере накопления опыта. Им также известно, что чаще приходится читать и модифицировать код, а не писать новый. В основе поддержки читаемости и модифицируемости кода лежит рефакторинг - как в частном случае структур (frameworks), так и для программного обеспечения в целом.

Так в чем проблема? Только в том, что с рефакторингом связан известный риск. Он требует внести изменения в работающий код, что может привести к появлению трудно находимых ошибок в программе. Неправильно осуществляя рефакторинг, можно потерять дни и даже недели. Еще большим риском чреват рефакторинг, осуществляемый без формальностей или эпизодически. Вы начинаете копаться в коде. Вскоре обнаруживаются новые возможности модификации, и вы начинаете копать глубже. Чем больше вы копаете, тем больше вскрывается нового и тем больше изменений вы производите. В конце концов, получится яма, из которой вы не сможете выбраться. Чтобы не рыть самому себе могилу, следует производить рефакторинг на систематической основе. В книге «Design Patterns» сообщается, что проектные модели создают целевые объекты для рефакторинга. Однако указать цель - лишь одна часть задачи; преобразовать код так, чтобы достичь этой цели, - другая проблема.

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

Что такое рефакторинг?

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

«Улучшение кода после его написания» - непривычная фигура речи. В нашем сегодняшнем понимании разработки программного обеспечения мы сначала создаем дизайн системы, а потом пишем код. Сначала создается хороший дизайн, а затем происходит кодирование. Со временем код модифицируется, и целостность системы, соответствие ее структуры изначально созданному дизайну постепенно ухудшаются. Код медленно сползает от проектирования к хакерству.

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

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

Правила рефакторинга

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

Самый важный урок, который должен преподать данный пример, это ритм рефакторинга: тестирование, малые изменения, тестирование, малые изменения, тестирование, малые изменения. Именно такой ритм делает рефакторинг быстрым и надежным.

Принципы рефакторинга

Рефакторинг (Refactoring): изменение во внутренней структуре программного обеспечения, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения.
Производить рефакторинг (Refactor): изменять структуру программного обеспечения, применяя ряд рефакторингов, не затрагивая его поведения.

Рефакторинг не меняет видимого поведения программного обеспечения. Оно продолжает выполнять прежние функции. Никто - ни конечный пользователь, ни программист - не сможет сказать по внешнему виду, что что-то изменилось.

Зачем нужно проводить рефакторинг?

Рефакторинг улучшает композицию программного обеспечения
Рефакторинг облегчает понимание программного обеспечения
Рефакторинг помогает найти ошибки
Рефакторинг позволяет быстрее писать программы

Когда следует проводить рефакторинг?

Рефакторингом следует заниматься постоянно понемногу. Надо не решать проводить рефакторинг, а проводить его, потому что необходимо сделать что-то еще, а поможет в этом рефакторинг.

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

Почему рефакторинг приносит результаты

Из-за чего бывает трудно работать с программами? В данный момент мне приходят в голову четыре причины:

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

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

Когда рефакторинг не нужен?

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

Явный признак необходимости переписать код - его неработоспособность. Это обнаруживается только при его тестировании, когда ошибок оказывается так много, что сделать код устойчивым не удается. Помните, что перед началом рефакторинга код должен выполняться в основном корректно.

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

Однако приближение срока окончания работ - единственный случай, когда можно отложить рефакторинг, ссылаясь на недостаток времени. Опыт работы над несколькими проектами показывает, что проведение рефакторинга приводит к росту производительности труда. Нехватка времени обычно сигнализирует о необходимости рефакторинга.

Рефакторинг и проектирование

Рефакторинг играет особую роль в качестве дополнения к проектированию. Если заранее подумать об архитектуре программы, то можно избежать последующей дорогостоящей переработки. Многие считают, что проектирование важнее всего, а программирование представляет собой механический процесс. Аналогией проекта служит технический чертеж, а аналогией кода - изготовление узла. Но программа весьма отличается от физического механизма. Она значительно более податлива и целиком связана с обдумыванием. Как говорит Элистер Кокберн (Alistair Cockburn):
«При наличии готового дизайна я думаю очень быстро, но в моем мышлении полно пробелов».

Существует утверждение, что рефакторинг может быть альтернативой предварительному проектированию. В таком сценарии проектирование вообще отсутствует. Первое решение, пришедшее в голову, воплощается в коде, доводится до рабочего состояния, а потом обретает требуемую форму с помощью рефакторинга. Такой подход фактически может действовать. Мне встречались люди, которые так работают и получают в итоге систему с очень хорошей архитектурой. Тех, кто поддерживает «экстремальное программирование» [ Beck , XP ], часто изображают пропагандистами такого подхода.
Подход, ограничивающийся только рефакторингом, применим, но не является самым эффективным. Даже «экстремальные» программисты сначала разрабатывают некую архитектуру будущей системы. Они пробуют разные идеи с помощью CRC-карт или чего-либо подобного, пока не получат внушающего доверия первоначального решения. Только после первого более или менее удачного «выстрела» приступают к кодированию, а затем к рефакторингу. Смысл в том, что при использовании рефакторинга изменяется роль предварительного проектирования. Если не рассчитывать на рефакторинг, то ощущается необходимость как можно лучше провести предварительное проектирование. Возникает чувство, что любые изменения проекта в будущем, если они потребуются, окажутся слишком дорогостоящими. Поэтому в предварительное проектирование вкладывается больше времени и усилий - во избежание таких изменений впоследствии.
С применением рефакторинга акценты смещаются. Предварительное проектирование сохраняется, но теперь оно не имеет целью найти единственно правильное решение. Все, что от него требуется, - это найти приемлемое решение. По мере реализации решения, с углублением понимания задачи становится ясно, что наилучшее решение отличается от того, которое было принято первоначально. Но в этом нет ничего страшного, если в процессе участвует рефакторинг, потому что модификация не обходится слишком дорого.
Рефакторинг предоставляет другой подход к рискам модификации. Возможные изменения все равно надо пытаться предвидеть, как и рассматривать гибкие решения. Но вместо реализации этих гибких решений следует задаться вопросом: «Насколько сложно будет с помощью рефакторинга преобразовать обычное решение в гибкое?» Если, как чаще всего случается, ответ будет «весьма несложно», то надо просто реализовать обычное решение.
Рефакторинг позволяет создавать более простые проекты, не жертвуя гибкостью, благодаря чему процесс проектирования становится более легким и менее напряженным. Научившись в целом распознавать то, что легко поддается рефакторингу, о гибкости решений даже перестаешь задумываться. Появляется уверенность в возможности применения рефакторинга, когда это понадобится. Создаются самые простые решения, которые могут работать, а гибкие и сложные решения по большей части не потребуются.

Рефакторинг и производительность

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

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

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

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

Разработка тестов

При проведении рефакторинга важным предварительным условием является наличие надежных тестов.

Правила разработки тестов

Делайте все тесты полностью автоматическими, так чтобы они проверяли собственные результаты.
Комплект тестов служит мощным детектором ошибок, резко сокращающим время их поиска.
Чаще запускайте тесты. Запускайте тесты при каждой компиляции - каждый тест хотя бы раз в день.
Получив сообщение об ошибке, начните с создания теста модуля, показывающего эту ошибку.
Лучше написать и выполнить неполные тесты, чем не выполнить полные тесты.
Подумайте о граничных условиях, которые могут быть неправильно обработаны, и сосредоточьте на них свои тесты.
Не забывайте проверять, чтобы в случае возникновения проблем генерировались исключительные ситуации.
Опасение по поводу того, что тестирование не выявит все ошибки, не должно помешать написанию тестов, которые выявят большинство ошибок.

Проблемы рефакторинга

Потребность вносить изменения в существующий код
Необходимость строго придерживаться поставленной задачи
Покрывать код проверочными тестами

Признаки, что Вам нужен рефакторинга

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

Методы рефакторинга

Инкапсуляция поля (Encapsulate Field);
Выделение класса (Extract Class);
Выделение интерфейса (Extract Interface);
Выделение локальной переменной (Extract Local Variable);
Выделение метода (Extract Method);
Генерализация типа (Generalize Type);
Встраивание (Inline);
Введение фабрики (Introduce Factory);
Введение параметра (Introduce Parameter);
Подъём поля/метода (Pull Up);
Спуск поля/метода (Push Down);
Замена условного оператора полиморфизмом (Replace Conditional with Polymorphism);
и так далее;

George Carrette

Определение и применение рефакторинга кода

Что такое рефакторинг кода понять несложно – определений в сети достаточно много. Наиболее удачное и полное, на мой взгляд, в википедии, и не только потому, что оно исчерпывающее, но и потому, что в нем рефакторинг противопоставляется таким этапам , как оптимизация и реинжиниринг. Познакомиться с этим вариантом определения легко, набрав в строке слово "Рефакторинг" и открыв (скорее всего первую) ссылку на сайт свободной энциклопедии.

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

Когда уместно проводить рефакторинг кода?

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

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

Как мне кажется, отдельного внимания, помимо прочих, должны быть удостоены и те части кода, которые давно не редактировались (не были затронуты в процессе исправления ошибок или расширения функциональности), поскольку вряд ли они настолько невосприимчивы к вносимым вами изменениям, хотя и сохраняют корректное поведение. Но это уже ответ скорее не на вопрос “Когда уместно…”, а на вопрос “Где искать…”

Кому может быть полезен рефакторинг кода?

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

Во-вторых, сложные программные компоненты часто разрабатываются совместно несколькими людьми. Инструментов для организации совместной существует много: например это Rational Suite, в состав которого входит bag-tracker Clear-Quest и инструмент контроля версий программных компонентов Clear-Case. В последних версий, например, есть замечательный инструмент Team Foundation Server. Понятно, что любой “зрелый” программный компонент должен сопровождаться подробным описанием его внешних программных интерфейсов (спецификаций), но нужно также понимать, что любой опытный разработчик, зная, как пишутся такие спецификации, захочет изучить логику работы вашего компонента, анализируя непосредственно его . Вот для этих целей хорошо было бы, чтобы ваш код был “читабельным”. Таким образом, можно сделать вывод, что рефакторинг кода может помочь ускорить процесс совместной разработки программного продукта.

Рефакторинг vs Реинжиниринг?

Если рефакторинг кода не меняет поведения программы, то реинжиниринг на такое способен. Можно рассматривать реинжиниринг, как крайнюю форму рефакторинга, но мне кажется, что это не вполне корректно. Скорее, рефактиринг может стать причиной легкого реинжиниринга. Рассмотрим вариант, когда периодический рефакторинг в процессе интенсивного тестирования программного продукта может привести к реинженирингу:

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

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

Рефакторинг vs Оптимизация

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

Именование переменных, свойств, методов и функций

Данная тема не имеет прямого отношения к рефакторингу кода, но, тем не менее, оказывает немалое влияние на его читабельность. Каждый разработчик со временем вырабатывает свой стиль кодирования и, как следствие, использует свои правила именования лексем, частично или полностью заимствованные из различных нотаций. Довольно часто используют соглашения так называемой венгерской нотации . Я не буду в этой статье перечислять все соглашения этой замечательной нотации, обсуждать ее плюсы и минусы, но сделаю акцент на основном, по моему мнению, преимуществе ее использования: обозначение переменной или константы, помимо ее семантики, также отражает ее тип и . Например: m_iIndex – переменная, член класса целочисленного типа; gc_bUseCache - глобальная константа булева типа и т.д. Согласитесь, это довольно серьезно может облегчить жизнь тому, кто пытается разобраться в чужом коде. Помимо использования соглашений венгерской нотации я также рекомендую следовать следующим правилам:

Наименования свойств и полей класса булева типа формировать с использованием модальных и вспомогательных глаголов в соответствии с их назначением, например: Is ReadOnly , Has Value , Can Restore и т.д.;

Наименования методов, выполняющих какие-либо служебные, не связанные со спецификой вашей программы операции стараться формировать с использованием таких же служебных, часто используемых для обозначения смысла этих операций глаголов: Update View , Evaluate Value , Refresh Context и т.д.

При именовании методов стоит учитывать наименование класса и не дублировать его в наименовании этих методов, например: для обозначения методов открытия и закрытия соединения с базой данных класса DbConnection стоит выбрать имена Open и Close , а не Open Connection и Close Connection , соответственно. Исключением могут являться случаи, когда действие, выполняемое методом специфично или вторично по отношению к основному функционалу класса, например: методы работы с журналом событий Open Log и Close Log для того же класса DbConnection .

Если метод или свойство открытое (public), а его назначение нетривиально (в том смысле, что не может быть сформулировано одним или двумя словами типа GetResource или SaveChanges), то скорее всего не стоит его именовать “склеиванием” сокращений нескольких слов типа GetNewClntProf – такой подход уместен для внутреннего использование, но не для метода, который “торчит наружу”, являясь частью открытого интерфейса - не все поймут правильно эту аббревиатуру, не говоря уже о том, что в разных языках (естественных) различные правила сокращения слов. Лучше не жалеть места и составить наименование, как конкатенацию всех слов целиком: GetNewClientProfile .

Для того, чтобы в контексте метода или функции отличать ее параметры от локальных переменных (глобальные переменные и члены класса и так выделяются префиксом типа m_ , c_ , g_ и т.д.) предлагаю имена этих локальных переменных начинать с подчеркивания “_” (естественно, если это позволяет синтаксис выбранного вами языка программирования) и дальше в соответствии с венгерской нотацией.

Рефакторинг кода

При создании приложений многие разработчики сначала заботятся об их функциональности, а когда она обеспечена, переделывают приложения таким образом, чтобы они были более управляемыми и удобочитаемыми. Это называется рефакторингом (refactoring) . Под рефакторингом понимается процесс переделки кода для повышения удобочитаемости и производительности приложений, а также обеспечения безопасности типов и приведения кода к такому виду, в котором он лучше соответствует рекомендуемым приемам объектно-ориентированного программирования. К счастью, теперь в Visual Studio 2010 можно достаточно хорошо автоматизировать этот процесс.

За счет использования меню Refactor (Рефакторинг) , которое становится доступным при открытом файле кода, а также соответствующих клавиатурных комбинаций быстрого вызова, смарт-тегов (smart tags) и/или вызывающих контекстные меню щелчков, можно существенно видоизменять код с минимальным объемом усилий. В следующей таблице перечислены некоторые наиболее распространенные приемы рефакторинга, которые распознаются в Visual Studio 2010:

Возможности рефакторинга кода

Прием рефакторинга	Описание
Extract Method (Извлечение метода)	Позволяет определять новый метод на основе выбираемых операторов программного кода
Encapsulate Field (Инкапсуляция поля)	Позволяет превращать общедоступное поле в приватное, инкапсулированное в форму свойство C#
Extract Interface (Извлечение интерфейса)	Позволяет определять новый тип интерфейса на основе набора существующих членов типа
Reorder Parameters (Переупорядочивание параметров)	Позволяет изменять порядок следования аргументов в члене
Remove Parameters (Удаление параметров)	Позволяет удалять определенный аргумент из текущего списка параметров
Rename (Переименование)	Позволяет переименовывать используемый в коде метод, поле, локальную переменную и т.д. по всему проекту

Чтобы увидеть процесс рефакторинга в действии, давайте модифицируем метод Main(), добавив в него следующий код:

Using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ConsoleApplication1 { class Program { static void Main(string args) { // Настраиваем консольный интерфейс (CUI) Console.Title = "Мое приложение"; Console.ForegroundColor = ConsoleColor.Yellow; Console.BackgroundColor = ConsoleColor.Blue; Console.WriteLine("Привет, это мой проект!"); Console.BackgroundColor = ConsoleColor.Black; Console.ReadLine(); } } }

В таком, как он есть виде, в этом коде нет ничего неправильного, но давайте представим, что возникло желание сделать так, чтобы данное приветственное сообщение отображалось в различных местах по всей программе. В идеале вместо того, чтобы заново вводить ту же самую отвечающую за настройку консольного интерфейса логику, было бы неплохо иметь вспомогательную функцию, которую можно было бы вызывать для решения этой задачи. С учетом этого, попробуем применить к существующему коду прием рефакторинга Extract Method (Извлечение метода) .

Для этого выделите в окне редактора все содержащиеся внутри Main() операторы, кроме последнего вызова Console.ReadLine() , и щелкните на выделенном коде правой кнопкой мыши. Выберите в контекстном меню пункт Refactor --- Extract Method (Рефакторинг --- Извлечь метод).

После этого метод Main() станет вызывать новый только что сгенерированный метод MyConfigCUI(), внутри которого будет содержаться выделенный ранее код:

Using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ConsoleApplication1 { class Program { static void Main(string args) { //Настраиваем консольный интерфейс (CUI) MyConfigCUI(); Console.ReadLine(); } private static void MyConfigCUI() { Console.Title = "Мое приложение"; Console.ForegroundColor = ConsoleColor.Yellow; Console.BackgroundColor = ConsoleColor.Blue; Console.WriteLine("Привет, это мой проект!"); Console.BackgroundColor = ConsoleColor.Black; } } }

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