Рефакторинг (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; } } }

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

George Carrette

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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

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

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

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

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