Что такое рефакторинг кода – База знаний Timeweb Community

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

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

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

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

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

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

Определение Мартина Фаулера

Вопрос «Что такое рефакторинг?» часто возникает у программистов-новичков, а иногда и у более опытных разработчиков. Поэтому он регулярно всплывает на форумах в духе StackOverflow. 

Там в качестве ответа на вопрос приводят цитату из книги «Refactoring: Improving the Design of Existing Code» за авторством Мартина Фаулера:

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

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

Что не является рефакторингом?

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

• простое переписывание кода,

• дебаггинг,

• улучшения функциональной составляющей ПО,

• оптимизация.

Первое имеет смысл при создании нового ПО или самотренировок. 

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

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

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

Но ни что из перечисленного выше не является рефакторингом, и зачастую каждая из процедур выполняется отдельно (за редким исключением, когда некорректное поведение ПО вызвано неправильно написанным кодом). 

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

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

Ожидаемые преимущества рефакторинга:

• Улучшение объективной читаемости кода за счет его сокращения или реструктуризации. 

• Провоцирование разработчиков на более вдумчивое написание ПО с соблюдением заданной стилистики и критериев. 

• Подготовка плацдарма для создания переиспользуемых кусков кода. 

• Упрощение поиска ошибок в большом объеме кода. 

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

В каких случаях нужен рефакторинг?

Есть ряд ситуаций, которые «кричат» о необходимости рефакторинга:

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

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

• Приходится выполнять идентичные процедуры в разных участках кода (объектах, классах) вместо того, чтобы внести изменение в одном классе, и оно возымело бы эффект в других участках ПО. 

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

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

На какие аспекты кода направлен рефакторинг?

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

Неиспользуемый код

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

Дубликаты

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

Переменные и функции названы неадекватно

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

Код, из которого невозможно что-либо понять

Избыточное количества текста в одном методе

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

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

Та же функция, но описанная одной строкой

Избыточное количество комментариев

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

Некорректно оформленные куски кода

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

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

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

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

• Red-Green-Refactor. Это некий аналог «На старт, внимание, марш!». Находим кусок кода для переработки, пишем юнит-тест, переходим к переписыванию. 

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

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

Сложности рефакторинга 

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

Опытные разработчики рекомендуют следующие практики:

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

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

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

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

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

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

Зачем нужен рефакторинг кода? | Университет СИНЕРГИЯ

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

Зачем нужен рефакторинг и нужен ли

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

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

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

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

Когда надо выполнять рефакторинг

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

Замусориватели

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

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

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

Раздувальщики

Категория включает элементы кода, классы и методы, которые в ходе разработки программы увеличиваются до таких больших размеров, что с ними больше нельзя продуктивно работать:

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

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

Нарушители ООП

Если разработчик не полностью либо неправильно использует возможности, которые ему дает объектно-ориентированное программирование, часто появляются перечисленные проблемы:

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

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

Утяжелители изменений

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

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

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

Другие признаки

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

• метод обращается к данным, относящимся к другому объекту гораздо чаще, чем к своим;
• класс выполняет всего одно действие, а именно передает работу другому классу;
• неуместная близость — один класс оперирует методами и служебными полями другого.

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

Эффективные методы рефакторинга

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

Составление методов

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

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

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

Организация данных

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

• Самоинкапсуляция поля. Разработчик формирует сеттер и геттер для поля, и в дальнейшем с целью доступа к полю пользуется исключительно ими.
• Значение вместо ссылки. Большое количество одинаковых экземпляров, относящихся к одному классу, заменяется одним объектом-ссылкой.
• Ссылка вместо значения. Неизменяемый и чрезмерно малый объект-ссылку подменяется объектом-значением, чтобы сделать управление его жизненным циклом более простым.
• Замена связей. Добавляется недостающая связь в класс в случае, если нужно использовать возможности двух классов. Иногда рефакторинг заключается в обратном — удаление двухсторонней связи в ситуации, когда взаимное использование функций больше не нужно.

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

Упрощение условий

Одна из задач рефакторинга — минимизировать количество условных операторов в коде. Варианты:

• разбить сложный оператор на части, используя отдельные функции «then» и «else»;
• объединить одинаковые условия, которые приводят к одному и тому же результату;
• вынести все одинаковые фрагменты кода за пределы рамок условного оператора;
• заменить флаг для булевских выражений функциями «break», «continue» и «return».

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

Что еще рефакторить

Есть еще несколько методов, использование которых поможет провести грамотный refactoring программы и сделать ее структуру более понятной:

• Непонятные имена. Все названия классов, методов, переменных и других конструкций кода должны иметь интуитивно-понятные наименования, по которым можно понять, что именно они делают. Следование правилу сделает структуру понятной для других разработчиков.
• Большие методы и классы. Громоздкие конструкции сокращаются путем вынесения фрагментов в компактные методы и классы, которые правильно ссылаются друг на друга.
• Длинные списки параметров. Здесь работает аналогичное правило, что и выше. Число аргументов сокращается максимум до четырех-пяти, иначе структура программы будет сложной.
• Цепочки сообщений. Метод любого объекта должен ссылаться только на собственные либо переданные извне параметры, а также на те участки кода, к которому есть прямой доступ. Это правило называется законом Деметры. Если в программе это не так, нужно перепроверить все связи и правильно их настроить.
• Статика. Обилие статических переменных увеличивает непредсказуемость программы и делает код более процедурным, нежели объектно-ориентированным. Чтобы избежать этого, разработчик должен инстанцировать объекты, позволяя им управлять данными так, как им нужно.
• Универсальные объекты. Такие конструкции, имеющие доступ к другим универсальным участкам программы, нарушают закон Деметры и увеличивают связность системы. Это не идет на пользу приложению, поэтому в процессе рефакторинга важно инжектировать только необходимые зависимости.

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

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

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

Определение

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

Существительное «рефакторинг» относится к одному конкретному преобразованию, сохраняющему поведение, такому как «Извлечение метода» или «Введение параметра».

Распространенные ловушки

Рефакторинг «не» означает:

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

Рефакторинг при отсутствии гарантий от внесения дефектов (т. е. нарушение условия «сохранения поведения») является рискованным. Гарантии включают вспомогательные средства для регрессионного тестирования, включая автоматические модульные тесты или автоматизированные приемочные тесты, а также вспомогательные средства для формальных рассуждений, такие как системы типов.

Ожидаемые преимущества

Ниже перечислены заявленные преимущества рефакторинга:

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

Рефакторинг

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

Признаки использования

• Записи контроля версий (такие как журналы CVS или git) включают записи с пометкой «Рефакторинг»
• модификации кода, соответствующие таким записям, могут быть проверены на нейтральность поведения: не вводятся новые модульные или функциональные тесты, например

Уровни навыков

• Новичок
• знает определение «рефакторинга»
• может использовать некоторые автоматизированные рефакторинги из IDE

.

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

Дополнительная литература

• Рефакторинг, Мартин Фаулер
• Метод Микадо Олы Элльнестам и Даниэля Бролунда

Истоки

• 1984: понятие «факторинг», предвосхищение рефакторинга, описано в книге Броди «Размышление о будущем», где оно представлено как «организация кода в полезные фрагменты», которая «происходит во время детального проектирования и реализации». .
• 1990: Билл Опдайк вводит термин «рефакторинг» в статье ACM SIGPLAN с Ральфом Джонсоном «Рефакторинг: помощь в разработке инфраструктур приложений и развитии объектно-ориентированных систем» 9.0014
• 1992: подробное описание «рефакторинга» представлено в диссертации Опдайка «Рефакторинг объектно-ориентированных фреймворков»

.

• 1999: практика «рефакторинга», включенная несколькими годами ранее в «Экстремальное программирование», популяризируется одноименной книгой Мартина Фаулера

.

• 2001: рефакторинг «пересекает Рубикон», выражение Мартина Фаулера, описывающее широкую доступность автоматизированных средств рефакторинга в IDE для языка Java

Academic Publications

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

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

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

Рефакторинг

Рефакторинг снижает стоимость улучшений

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

Рефакторинг является частью повседневного программирования

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

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

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

Автоматизированные инструменты полезны, но не обязательны

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

Каталог

Основным содержанием этого сайта является онлайн-каталог
рефакторинг. Здесь перечислены рефакторинги во втором издании вместе
со сводной информацией о рефакторингах.

Книга

Чтобы узнать больше о
рефакторинга, естественной отправной точкой является мой рефакторинг
книга, уже во втором издании. Я написал оригинальное издание в
1997–1999 годы, когда рефакторинг был малоизвестной техникой. Когда я обновил его
восемнадцать лет спустя рефакторинг стал обычным инструментом для любого
квалифицированный программист. Однако в нашу профессию регулярно приходят новые люди
и нужно узнать о рефакторинге. Эта книга помогает им учиться и
для опытных разработчиков, чтобы передать свои навыки.

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

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

Как получить доступ к веб-версии?

Определение

В книге я даю следующее определение «рефакторинга»

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

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

This entry was posted in Популярное