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

Анализ и рефакторинг для создания чистого кода

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

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

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

Операция улучшения кода происходит примерно в следующих стадиях:

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

Непрерывный процесс управления качеством

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

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

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

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

Для примера эффективности рефакторинга существующего кода подсчитываем члены и операторы: (x - 1) * (x + 1) = x 2 - 1. Четыре термина против трех. Три оператора против двух. Однако выражение левой стороны проще понять, потому что оно использует более простые операции. Кроме того, он предоставляет больше информации о структуре функции f (x) = x 2 - 1, так как корни +/- 1, что было бы трудно определить, просто «глядя» с правой стороны.

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

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

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

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

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

Методы исправления:

1. Перемещение класса. Класс находится в неправильном пакете, поэтому его следует перенести в другой пакет, где он лучше подходит.
2. Извлечение. Длинный метод необходимо разбить на этапы, чтобы повысить читаемость и удобство обслуживания. Раздел кода с одной логической задачей заменяется вызовом на новый метод.
3. Экстракция суперкласса. Существующий класс предоставляет функциональные возможности, которые необходимо каким-то образом изменить. Абстрактный класс вводится, как родитель текущего класса, а затем общее поведение «подтягивается» к этому новому родителю.
4. Замена условного значения с полиморфизмом. Методы в классе могут проверять некоторое значение (если или оператор switch), чтобы определить правильное действие для выполнения.

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

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

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

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

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

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

Даже если разработчик программного обеспечения стремится реорганизовать какой-то плохо структурированный код. Его менеджер может иметь совершенно другую перспективу выполнения ПО и может выступать против любой попытки изменить рабочий код.

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

Автоматизация процесса

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

1. Система, из которой реорганизованный код является частью, может быть быстро восстановлена.
2. Существуют автоматические «регрессионные» тесты, которые можно часто запускать.

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

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

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

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

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

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

До Visual Studio 2012 большинство этих видов анализа и тестирования кода требовали сторонних инструментов и ручных задач сборки, тестирования, анализа, повтора для разработчика. Сегодня Visual Studio имеет довольно прочные инструменты для анализа. Кроме того, есть отличные инструменты, которые помогут разработчику углубиться в приложение для тестирования производительности и оптимизации, шаблонов проектов, которые имеют эффективные зависимости и встроенные тестовые среды, а также надежные инструменты для интеграции автоматизированного анализа и тестирования в рабочих процессах сборки и выпуска.

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

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

Пользователь найдет информацию о сборе данных и профилировании во время выполнения метода не только для традиционных приложений.NET Framework, но также для продуктов JavaScript, ASP.NET и веб-сайтов, высокопроизводительных вычислений (HPC) и тестирования нагрузки.

Другим инструментом, которым с удовольствием пользуются разработчики, выступает рефакторинг кода c PerfView для анализа производительности. Моррисон является старшим архитектором в Microsoft и написал PerfView для внутреннего анализа производительности и настройки командами, создающими.NET Framework и Visual Studio. Теперь это инструмент с который по-прежнему находится в активной разработке.

Дополнительные механизмы для профилирования и отладки

Помимо инструментов, доступных от Microsoft, используются сторонние инструменты, предназначенные для удовлетворения потребностей в тонкой настройке:

1. Jains dotTrace Profiler помогает отслеживать время выполнения, сбор мусора, распределение рабочей нагрузки, производительность ввода-вывода. Есть 10-дневная пробная версия, доступная для выполнения пробных шагов.
2. Redgate ANTS Performance Profiler - еще один популярный инструмент для проектов на базе.NET Framework обеспечивает такой же анализ синхронизации кода, как и другие инструменты, но также углубляется в производительность запросов к базе данных с поддержкой расширенного профилирования доступа к данным с поддержкой Oracle, MySQL, и PostgreSQL.
3. DevExpress CodeRush - еще один инструмент анализа и рефакторинга для баз данных C #, Visual Basic и XAML. Инструменты анализа CodeRush не только работают с основными решениями, но также имеют встроенную интегральную тестовую интеграцию, поддерживающую рамки NUnit, xUnit, MSpec и MSTest, а также тестовые примеры CoreCLR в среде DNX.
4. Microsoft Code Analysis 2017 дает встроенный доступ к более чем 100 наиболее популярным правилам FxCop в качестве живых анализаторов. Анализаторы смотрят код C # или Visual Basic по мере ввода и предоставляют советы по производительности, безопасности и лучшим практикам, а также доступ к словарю быстрого исправления кода.
5. Microsoft DevSkim - это более комплексная и гибкая структура модулей и анализаторов кода, ориентированных на встроенный анализ безопасности кода при вводе. Потенциальные проблемы безопасности выделяются в коде ссылками на дополнительную информацию одним кликом к безопасному альтернативному коду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.

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

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

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

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

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

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

Выделение метода (extract method)

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

Перемещение метода (move method)

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

Замена условного оператора полиморфизмом (replace conditional with polymorphism)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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