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

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

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

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

Какой код надо рефакторить

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

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

В вашей программе есть очень длинные методы/функции. Как правило, человек не может полностью воспринимать и оценивать правильность кода, если этот код занимает больше 2-3 десятков строк. Такие методы и функции следует разделять на несколько более мелких и делать одну общую функцию, которая будет последовательно вызывать эти методы. Никогда не пытайтесь сократить длину кода записывая по несколько операторов в одной строке!!! Это один из самых худших вариантов организации программы и я вам даю 100% гарантию, что такой код в итоге приведёт к ошибкам!

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

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

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

Много “беспорядочно” хранящихся данных, которые связаны логически и их можно было бы объединить в структуру, либо класс. Логически связанные данные всегда стоит хранить в структурах/классах, даже если это всего 2-3 переменных – хуже от этого никому не станет, а вот код станет значительно понятнее.

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

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

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

При создании приложений многие разработчики сначала заботятся об их функциональности, а когда она обеспечена, переделывают приложения таким образом, чтобы они были более управляемыми и удобочитаемыми. Это называется рефакторингом (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; } } }

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

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

Если вы хоть немного разделяете мои ощущения, то нам есть о чём поговорить. Дело в том, что со временем что-то внутри меня начало подсказывать, что рефакторить всё подряд, везде и всё время - не самая лучшая идея. Поймите меня правильно, код должен быть хорошим (а лучше бы ему быть идеальным), но в условиях суровой реальности не всегда разумно постоянно заниматься улучшением кода. Я вывел для себя несколько правил о своевременности рефакторинга. Если у меня начинают чесаться руки что-нибудь улучшить, то я оглядываюсь на эти правила и начинаю думать: «А действительно ли сейчас тот момент, когда нужно нарефакторить?». Давайте порассуждаем о том, в каких же случаях рефакторинг уместен, а в каких - не очень.

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

Слишком ранний рефакторинг

Можете ли вы припомнить, когда у вас последний раз было постоянное ТЗ, которое месяцами не менялось? У меня вот такое вспомнить не очень получается. Мы живём в реальном мире, требования всё время меняются. Причём это не обязательно внешние требования - это могут быть ваши собственные требования к проекту. Поясню мысль на примере: допустим, вы взяли задачку среднего размера на один-два дня. Первые несколько классов уже написаны, но запустить пока нечего - идёт процесс написания суровой архитектурной части. И тут вы замечаете, что одна из частей проекта написана не особо универсально: «А вот если через полгода понадобится сделать X, то все будут страдать». Вполне разумно, что вам не хочется отправлять в репозиторий хреновый код, чтобы другие разработчики потом вспоминали вас плохим словом. И вы начинаете рефакторить ещё не готовую фичу . Иногда это оправдано, но на подобном пути следовало бы повесить табличку «ОПАСНОСТЬ». Вот поправите вы одну штуку, потом другую, потом третью. Неделя прошла, фича всё ещё не запускается, а вы говорите: «Как-то всё неправильно сделано. Но теперь я точно понял , как надо делать. Сейчас быстренько всё перепишу с нуля». Основная проблема заключается в том, что фидбека по фиче ещё не получено, а вы уже начали работать над улучшением кодовой базы. Подобный подход редко приводит к успеху. Не знаю, как у вас, а у меня часто бывает, что после реализации фичи я начинаю понимать, что работать всё должно несколько иначе. И это не из-за того, что я такой глупый, заранее не смог нормально продумать. Просто некоторую функциональность нужно «пощупать», чтобы понять как всё должно быть в релизе. Иногда нужен небольшой прототипчик (пусть даже с говнокодом и багами), чтобы обсудить фичу с коллегами. Иногда нужно что-то показать заказчику, чтобы он мог сказать: «Не, ну я не так хотел, всё должно быть наоборот». Порой пользователями не нравятся нововведения, они хотят всё как было. Проблема новых фич в том, что сложно предсказать их судьбу. Нередко случается так, что все наработки отправляются в помойку, т. к. после обсуждения первой версии коллектив принял решение делать всё иначе. Общий вывод: не стоит рефакторить код слишком рано, особенно если вы не уверены, что этот код 100 % останется в проекте.

Нецелевой рефакторинг

Скорее всего, у вас есть план разработки на ближайшее время. Вполне вероятно, что у вас есть сроки (даже если вы их поставили сами). Релизы нужно делать вовремя, затягивать разработку не стоит. Нужно контролировать себя, нужно заниматься теми вещами, которые входят в ваши непосредственные цели. Допустим, у вас есть кусок кода, который выглядит как полное… Ну, в общем, плохо выглядит. Но, продолжим наше допущение, вы с ним сейчас не работаете. Этот плохой кусок кода стабильно работает, успешно справляется со своими задачами и никак не связан с вашей текущей задачей. Ну так и не трогайте его! Да, вас может крайне печалить то обстоятельство, что на другом конце проекта всё очень плохо . Но заметьте, что прямо сейчас вам это никак не мешает. У вас есть текущие задачи, занимайтесь ими. Конечно, бывают задачи по улучшению кодовой базы, но нечасто - зачастую важнее добавлять новый функционал или фиксить баги. Концентрируйтесь на текущих задачах и не бросайте их из-за того, что где-то там что-то как-то не так.

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

Ок, вы пришли к выводу, что нужно обязательно отрефакторить часть проекта. Хорошо, давайте отрефакторим. Вроде бы запланированные улучшения выполнены, но тут возникает мысль: «А что я могу ещё улучшить? Ага, вон ту штуку». А после вон той штуки появится вот эта штука, а потом ещё одна, а потом ещё и т. д. Нужно понимать, что есть плохой код, есть хороший код, есть идеальный код. Последнего в большом проекте у вас никогда не будет. Это не значит, что не нужно к нему стремиться, но нужно понимать его недостижимость. Обычно задача стоит в написании хорошего кода, а не идеального. Допустим, после рефакторинга у вас получился вполне читаемый код, который работает более или менее очевидным образом, в котором нет костылей и которым не так сложно пользоваться. Задайте себе вопрос: «А может, пора остановиться?». Да, код можно улучшать. Причём в достаточно большом проекте его можно улучшать до бесконечности. Но вот прямо сейчас он справляется со своими функциями, им удобно пользоваться, он практически не вызывает у вас дискомфорта. Очень важно определить для себя приемлемое качество кода, после которого вы перестанете его улучшать (до тех пор, пока свойство приемлемости не будет утрачено). Вспомните, что есть ещё так много разных клёвых штук, которые можно дописать. Не нужно рефакторить ради самого рефакторинга, ради идеального кода. Нужно рефакторить, когда у вас есть веские причины на это: код сложно прочитать, код сложно поддерживать, код сложно развивать, код сложно использовать и т. п. Если ни одного «сложно» не возникает, то веских причин тратить время на рефакторинг у вас нет.

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

Бывает так, что релиз послезавтра/завтра/сегодня/должен был быть вчера (нужное подчеркнуть). Это важный момент в жизни проекта. Нужно уделить особое внимание тестированию, фиксам критических багов, финальным доделкам. Поверьте, это действительно плохая идея - перерабатывать кодовую базу (а ещё хуже - качественно перерабатывать) в тот момент, когда нужно отдавать проект в продакшн. Опытная практика подсказывает, что нужно зарелизиться, а потом с чистой совестью спокойно улучшать код. Некоторые спросят: «А почему?». Если такой вопрос возник, то, наверное, вам ещё не приходилось делать сложный рефакторинг. Подскажу: при переписывании код не всегда обязательно улучшается - иногда он может сломаться. Да что там сложный рефакторинг - бывает, поправишь один метод на пять строк, не уследишь за какой-нибудь зависимостью, а на другом конце проекта выползет бага, с которой сразу же встретятся ваши любимые пользователи. Вот вроде бы ничего плохого и не делаешь, а тут внезапно на тебя нападает зверь «Это было неочевидно» и топит тебя в пруду ложной первоначальной оценки. Хотя, может, это просто я такой плохой программист - люблю что-нибудь сломать. Вполне возможно, что вы всегда рефакторите всё абсолютно правильно и с полным контролем всего проекта. В таком случае я могу вас поздравить, но от совета с запретом предрелизного рефакторинга всё-таки не откажусь. Поверьте, за несколько дней рефакторинг никуда не убежит, а сон у всей команды будет чуточку, но спокойней.

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

Вопрос тяжёлый, очень тяжёлый. Ситуация: есть огромное количество ужасных строк кода, которые достались вам от старых разработчиков (возможно, этими старыми разработчиками были вы несколько лет назад, ещё до того, как научились писать всё правильно и сразу). Код приходится поддерживать. То там, то тут возникают костыли и дублирования, энтропия растёт. С каждым днём всё больше хочется выкинуть всё и переписать с нуля. В такой момент нужно очень хорошо подумать о рисках. Да, вполне вероятно, что в перспективе такая деятельность будет полезна. Но в какой именно перспективе и насколько полезна? Скорее всего, в процессе большого рефакторинга или переписывания отдельных частей вы замените старый работающий говнокод новым, идеально написанным кодом, но с багами. И вовсе не из-за того, что вы плохой программист и пишете плохо. Просто вы можете не знать этот код в достаточной мере . Вы можете не знать, почему автор написал всё именно так, а ведь причины могли быть. Иногда приходится писать очень странный и кривой код. Я могу придумать очень много примеров: подавление хитрых оптимизаций процессора, подстройка под баги сторонней библиотеки, подавление каких-нибудь многопоточных косяков и т. д. Я не говорю, что нельзя все эти проблемы решить нормально. Просто иной раз при переписывании казалось бы абсурдного кода на нормальный появляются баги. Да, можно было всё сделать нормально, но вы можете просто не осознать всё величие шалаша из костылей вместо палок, если не узнаете у автора кода, почему он написал именно так (а подобная возможность предоставляется далеко не всегда). Будьте осторожны, когда переписываете старый код, который понимаете не до конца (а особенно, если думаете, что понимать там нечего).

А когда рефакторить-то?

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

• Нечего делать. Бывают спокойные времена простоя, когда все важные задачи закрыты, а новых пока не поставлено. Ну, не то чтобы совсем нечего делать, но определённое количество свободного времени есть. Потратьте его на улучшение кода. Дайте сущностям понятные имена, избавьтесь от дублирования, перепишите неудачный кусок архитектуры. Хоть нового функционала и не добавляется, но вы вкладываете свою лепту в душевное спокойствие разработчиков, которые будут продолжать проект. Поверьте, это важно.
• Каждодневные страдания. А бывает так, что есть кусок проекта, который заставляет вас тяжело вздыхать каждый день. А из-за соседних столов слышатся тяжёлые вздохи ваших коллег. Конечно, хоть и релиз и не завтра, но важных задач хватает. Тем не менее, за неделей проходит неделя, а смотреть на этот кусок проекта всё грустнее. Скажите себе: «Хватит это терпеть!». Если бизнес-план составляет начальник, то объясните ему, что этот код просто необходимо переписать. Если работаете на заказчика, то убедите его, что потраченная на рефакторинг неделя позволит сэкономить много времени на разработку в будущем. Если работаете на пользователей, то примите решение о том, что лучше бы этим пользователям в этот раз подождать релиза на недельку больше, но зато потом наслаждаться стабильным ПО и регулярными обновлениями. Да, договориться со всеми и с самим собой не всегда просто, но вы уж постарайтесь.
• Проблема запоздалого рефакторинга. Не стоит абсолютизировать правило про слишком ранний рефакторинг. Некоторые считают так: «Я вот сейчас наулучшаю чего-нибудь, а оно не пригодится - обидно же будет». Нужно понимать, что в ядре программы вполне могут быть важные части, которым лучше бы быть написанными хорошо. Помните, что чем позже вы проводите рефакторинг - тем выше его цена, ведь вы потратите больше времени и сил на переписывание. Критические базисные вещи (которые используются по всему проекту) должны быть в максимально хорошей форме постоянно. Будет просто прекрасно, если в вашей команде будет работать тезис «Рефакторинг не опаздывает. Он приходит строго тогда, когда считает нужным» .
• Встреча с монстром. Вы начинаете пилить новый функционал, который должен использовать старый кусок проекта, который выглядит как настоящий монстр: вам становится страшно только при взгляде на внешний интерфейс. Если время позволяет, то поправьте сперва базовую часть кода, чтобы потом сосредоточиться на новом функционале и не отвлекаться на то, чтобы вбить пяток костылей ради повторного использования кода.
• Разумный перфекционизм. Заметили плохой кусок кода? Хочется его поправить? Очень хочется его поправить? Ну, если прям очень хочется, то можно. Но обратите внимание на слово «разумный». Соотносите время, потраченное на рефакторинг, с выгодой от улучшения кода. Не стоит срывать сроки и зарываться в бесконечные улучшения. Однако если своевременно и в меру заниматься рефакторингом, то проекту от этого станет только лучше.

Вместо заключения

Всё вышеперечисленное является чисто субъективным обобщением опыта работы над рядом проектов. Разумеется, я покрыл далеко не все жизненные ситуации. В каждой команде свои требования к коду, свой бизнес-план и свои правила. Уверен, что у многих найдётся пяток историй из серии «А вот у меня был случай, когда все эти советы не работают». Это абсолютно нормально, так и должно быть. Нет универсальной серебряной пули для определения количества усилий на улучшение кода («Мы будем каждый день 47 минут 23 секунды заниматься рефакторингом - и всё у нас будет хорошо»). Вам нужно исходя из собственного опыта в вашем конкретном проекте, в вашей конкретной команде попытаться найти золотую середину между написанием нового кода и улучшением старого. Я агитирую только за то, чтобы ко всему было рациональное отношение без фанатизма («Зачем улучшать код, нового функционала от этого не появится» / «Нужно срочно весь код сделать идеальным, чтобы потом с ним можно было нормально работать»). Подходите разумно к распределению времени на работу над существующим кодом - и всё у вас будет хорошо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ход выполнения работы

1. Изучить теоретические сведения.
2. Выполнить анализ программного кода разрабатываемого ПО и модульных тестов с целью выявления плохо организованного кода.
3. Используя шаблоны рефакторинга, выполнить реорганизацию программного кода разрабатываемого ПО и модульных тестов.
4. Проверить успешность выполнения всех модульных тестов.
5. Выполнить описание произведенных операций рефакторинга (было-стало-шаблон рефакторинга).
6. В случае необходимости скорректировать проектную документацию (диаграммы классов, последовательностей).
7. Сделать выводы по результатам выполнения работы.

Требования к содержанию работы

1. Название работы.
2. Цель работы.
3. Краткая формулировка индивидуального задания.
4. Таблица изменений дизайна ПО.
5. Скорректированные диаграммы классов, последовательностей, в случае необходимости.
6. Выводы.

Теоретические сведения

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

Это не набор четких правил, а описание мест, на которые надо обращать внимание при рефакторинге.

Дублирующийся код

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

В простейших случаях вам поможет Extract Method. При работе с наследованием используйте Pull Up Field. Если код похож, но не в точности, надо применить Extract Method, а затем Form Template Method. Если методы делают одно и то же разными способами, выберите один из них и используйте Substitute Algorithm. Если у вас есть дублирующийся код в несвязанных классах, подумайте о возможности Extract Class.

Длинный Метод

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

Мы следуем эвристике: как только мы чувствуем, что надо написать комментарий, мы вместо этого пишем метод. В 99% случаев для того, чтобы сократить метод, вам достаточно будет применить Extract Method. Локальные переменные и параметры могут препятствовать вам, так что, возможно, вам понадобится Replace Temp With Query, Introduce Parameter Object и Preserve Whole Object.

Кроме комментариев, циклы и условия также являются хорошими знаками. Используйте Decompose Conditional для условий, а для циклов - выносите тело цикла в отдельный метод.

Большой класс

Когда класс делает слишком много всего, у него обычно слишком много полей.

Можно использовать Extract Class или Extract Subclass, чтобы выделить некоторые переменные. При определении того, что выносить, обращайте внимание на общность в названии переменных, а также на то использует ли класс их все одновременно.

Кроме того, класс, в котором слишком много кода, также является рассадником дублирования и хаоса. Здесь также применяйте Extract Class или Extract Subclass.

Если ваш большой класс - это GUI класс, то попытайтесь отделить поведение от данных. Вам может понадобиться Duplicate Observed Data.

Длинный список параметров

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

Используйте Replace Parameter with Method, Preserve Whole Object и Introduce Parameter Object.

Расходящееся изменение

Расходящееся изменение - это когда один класс подвержен различным изменениям.

Мы структурируем наше ПО, чтобы было легче его изменять. Если мы хотим что-то изменить, мы ищем единственное место, где мы можем сделать изменение. Если мы не можем этого сделать - мы ощущаем плохой запах. Вы можете смотреть на класс и думать: "вот эти три метода я меняю каждый раз когда подключаю новую БД, а эти четыре - при добавлении финансового инструмента". Для того, чтобы привести это в порядок, находите все, что меняется в данном частном случае и используйте Extract Class.

Хирургия дробовиком

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

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

Используйте Inline Class, если необходимо. Расходящееся изменение - это когда один класс подвержен различным изменениям, тогда как хирургия дробовиком - это когда одно изменение затрагивает несколько классов.

Зависть по функции

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

Просто используйте Move Method, чтобы перенести его туда, где он должен быть. Если только часть метода страдает завистью, используйте сначала Extract Method.

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

Использование некоторых сложных шаблонов, таких как Strategy и Visitor, нарушает эти правила. Общая рекомендация - всегда соблюдать баланс между сложностью и необходимой гибкостью.

Группы данных

Если вы видите, что элементы данных всегда путешествуют вместе, объедините их в один объект. Используйте Extract Class для полей, Preserve Whole Object и Introduce Parameter Object для параметров методов.

Хороший метод проверки: если вы удалите один из элементов данных, будут ли остальные иметь смысл? Если да, то здесь должен быть рожден объект.

Одержимость примитивами

Начинающие объектные программисты обычно избегают использовать маленькие объекты для маленьких задач, таких как валюта, диапазоны, специальные строки для телефонных номеров и т.п. Вы можете выйти из пещер в цивилизованный мир объектов с помощью Replace Data Value with Object, Replace Array with Object, если это код типа, то используйте Replace Type Code with Class, Replace Type Code with Sublasses и Replace Type Code with Strategy.

Оператор Switch (Case)

Хороший объектный код очень редко использует операторы Switch. Часто вы видите один и тот же Switch в разных местах. Если вам надо добавить еще один выбор, вам придется искать все операторы Switch.

В большинстве таких случаев лекарством является полиморфизм. Если Switch переключается по коду типа, используйте Replace Type Code with Sublasses или Replace Type Code with Strategy. Вам может понадобиться Extract Method и Move Method чтобы изолировать Switch и поместить его в нужный класс. Когда вы настроите структуру наследования, используйте Replace Conditional with Polymorphism.

Параллельные иерархии наследования

Параллельные иерархии - это частный случай хирургии дробовиком. Каждый раз, когда вы добавляете потомок класса, вы вынуждены добавлять потомок другому классу. Сначала сделайте так, что экземпляры одной иерархии ссылались на соответсвующие экземпляры другой. Потом используйте Move Method и Move Field и вторая иерархия исчезнет понемногу.

Ленивый класс

Каждый созданный класс стоит вам денег - на его понимание и содержание. Класс, который не делает достаточно, чтобы окупить себя, должен быть уничтожен. Часто это класс, который раньше окупался, но был урезан при рефакторинге. Если он является потомком другого класса, используйте Collapse Hierarchy. Почти бесполезные классы должны подвергнуться Inline Class.

Спекулятивное обобщение

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

Если у вас есть абстрактные классы, которые ничего не делают, используйте Collapse Hierarchy. Ненужная делегация может быть удалена с помощью Inline Class. Методы с неиспользуемыми параметрами должны быть подвергнуты Remove Parameter.

Временное поле

Иногда вы встречаете код, в котором переменные экземпляра используются только в определенных случаях. Это очень затрудняет понимание.

Используйте Extract Class, чтобы сделать дом для бедных сироток. Поместите туда весь код, относящийся к этим полям. Также вы можете избавиться от условного кода с помощью Introduce Null Object, для создания альтернативного объекта на случай, когда эти поля не имеют смысла.

Цепочка сообщений

Если вы видите код, когда клиент просит объект у другого объекта, затем у этого объекта следующий объект и т.п. Это может быть длинная строка getThis методов или последовательность временных переменных. В любом случае, при подобных вызовах, мы явно предполагаем знание о структуре объектов в цепочке. Любое изменение во взаимосвязях повлечет изменение этого кода. Здесь надо использовать Hide Delegate. Посмотрите, зачем используется результат вызова. Используйте Extract Method и затем Move Method , чтобы продвинуть его дальше по цепочке. Некоторые выступают против любой цепочки методов. Мы выступаем за умеренность.

Посредник

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

Однако, это может зайти слишком далеко. Вы смотрите на интерфейс класса и видите, что половина его методов просто делегируют вызовы другим классам. Время использовать Remove Middle Man и напрямую говорить с объектами, которые знают что происходит. Если только некоторые методы делегируют, то напустите на них Inline Method. Если кроме делегации добавляется поведение, используйте Replace Delegation with Inheritance.

Неоправданная близость

Иногда классы становятся слишком близки и проводят слишком много времени с приватными частями друг друга.

Используйте Move Method и Move Field для разделения частей и уменьшения близости. Посмотрите, нельзя ли организовать Change Bidirectional Association to Unidirectional. Если у классов действительно есть общий интерес, используйте Extract Class, чтобы положить общие части в одно место.

Наследование часто ведет к неоправданной близости. Потомки всегда знают о предках больше, чем хотелось бы предкам. Используйте Replace Inheritance with Delegation, когда пора покидать дом.

Неполный библиотечный класс

Зачастую библиотечный класс не совсем нас устраивает, но мы не можем применить что-то типа Move Method к нему. Если вам надо добавить пару методов, используйте Introduce Foreign Method. Если добавлять надо много, вам понадобится Introduce Local Extension.

Класс для данных

Бывают классы, которые содержат только поля и методы для доступа к ним. Это просто тупые контейнеры для данных и скорее всего, другие классы слишком детально ими манипулируют. Во-первых, примените Encapsulate Field и Encapsulate Collection, пока никто не видел. Посмотрите, где данные класса используются. Попробуйте применить Move Method, чтобы перенести этот код в сам класс данных. Классы для данных как дети. Они нужны на начальных этапах. Но чтобы вести себя как взрослый объект, они должны брать на себя ответственность.

Отвергнутое наследство

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

Традиционный ответ - иерархия плохая. Вам нужно создать новый порожденный класс и применить Push Down Method и Push Down Field. Но по нашему саркастическому использованию слова традиционный, вы догадались, что мы не будем это всегда советовать. Мы используем наследование для повторного использования. Оно сопровождается плохим запахом, но обычно он не очень силен. Если отвергнутое наследство представляет собой проблему, то воспользуйтесь традиционным советом.