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

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

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

Попросту он означает улучшение дизайна существующего кода без изменения его наблюдаемого поведения. Первоначально задуманная в сообществе 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 2017

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

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

До 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 помогает пользователям лучше знать, планировать и выполнять улучшение.

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