https://camokathomelab.servebeer.com/mediawiki/index.php?action=history&feed=atom&title=%D0%A0%D0%B5%D1%84%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3Рефакторинг - История изменений2026-07-17T12:00:51ZИстория изменений этой страницы в викиMediaWiki 1.45.3https://camokathomelab.servebeer.com/mediawiki/index.php?title=%D0%A0%D0%B5%D1%84%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3&diff=40636&oldid=previmported>Alex NB OT: унификация языковых шаблонов2025-11-15T11:10:47Z<p>унификация языковых шаблонов</p>
<p><b>Новая страница</b></p><div>'''Рефа́кторинг''' ({{lang-en|refactoring}}), или '''перепроекти́рование кода, перерабо́тка кода, равноси́льное преобразова́ние алгоритмов''' — процесс изменения внутренней структуры [[Компьютерная программа|программы]], не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы<ref>М. Фаулер (2000), стр. 61-62</ref>{{sfn|Кериевски|2008|loc=Введение}}. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и чёткости.<br />
<br />
== Цели рефакторинга ==<br />
Цель рефакторинга — сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным.<br />
<br />
Рефакторинг следует отличать от [[Оптимизация кода|оптимизации производительности]]. Как и рефакторинг, оптимизация обычно тоже не изменяет поведение программы, а только ускоряет её работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу<ref name=autogenerated1>М. Фаулер (2000), стр. 62</ref>.<br />
<br />
С другой стороны, нужно отличать рефакторинг и от [[Реинжиниринг программного обеспечения|реинжиниринга]], который осуществляется для расширения функциональности программного обеспечения. Как правило, крупные рефакторинги предваряют реинжиниринг.<br />
<br />
== Причины применения рефакторинга ==<br />
Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:<br />
# необходимо добавить новую функцию, которая недостаточно укладывается в принятое [[Архитектура программного обеспечения|архитектурное решение]];<br />
# необходимо исправить ошибку, причины возникновения которой сразу не ясны;<br />
# преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.<br />
<br />
== Признаки плохого кода ==<br />
{{main|Код с запашком}}<br />
Во многом при рефакторинге лучше полагаться на интуицию, основанную на опыте. Тем не менее имеются некоторые видимые проблемы в коде ({{lang-en|code smells}}), требующие рефакторинга:<br />
# [[дублирование кода]];<br />
# длинный метод;<br />
# большой класс;<br />
# длинный список параметров;<br />
# «жадные» функции — это метод, который чрезмерно обращается к данным другого объекта;<br />
# избыточные временные переменные;<br />
# классы данных;<br />
# несгруппированные данные.<br />
<br />
== Рефакторинг кода ==<br />
В программировании термин ''рефакторинг'' означает изменение исходного кода программы без изменения его внешнего поведения. В [[экстремальное программирование|экстремальном программировании]] и других гибких методологиях рефакторинг является неотъемлемой частью цикла разработки ПО: разработчики попеременно то создают новые тесты и функциональность, то выполняют рефакторинг кода для улучшения его логичности и прозрачности. Автоматическое [[юнит-тестирование]] позволяет убедиться, что рефакторинг не разрушил существующую функциональность.<br />
<br />
Рефакторинг изначально не предназначен для исправления [[Программная ошибка|ошибок]] и добавления новой функциональности, он вообще не меняет поведение программного обеспечения<ref name=autogenerated1 /> и это помогает избежать ошибок и облегчить добавление функциональности. Он выполняется для улучшения понятности кода или изменения его структуры, для удаления «мёртвого кода» — всё это для того, чтобы в будущем код было легче поддерживать и развивать. В частности, добавление в программу нового поведения может оказаться сложным с существующей структурой — в этом случае разработчик может выполнить необходимый рефакторинг, а уже затем добавить новую функциональность.<br />
<br />
Это может быть перемещение поля из одного [[Класс (программирование)|класса]] в другой, вынесение фрагмента [[исходный код|кода]] из [[Метод (языки программирования)|метода]] и превращение его в самостоятельный метод или даже перемещение кода по иерархии классов. Каждый отдельный шаг может показаться элементарным, но совокупный эффект таких малых изменений в состоянии радикально улучшить проект или даже предотвратить распад плохо спроектированной программы.<br />
<br />
== Методы рефакторинга ==<br />
Наиболее употребимые{{sfn|Кериевски|2008|сс=24-25}} методы рефакторинга:<br />
* Изменение [[Сигнатура функции|сигнатуры метода]] (change method signature)<br />
* [[Инкапсуляция (программирование)|Инкапсуляция]] [[Поле данных (информатика)|поля]] (encapsulate field)<br />
* [[Выделение частного класса данных|Выделение класса]] (extract class)<br />
* Выделение [[Интерфейс (объектно-ориентированное программирование)|интерфейса]] (extract interface)<br />
* Выделение локальной переменной (extract local variable)<br />
* Выделение [[Метод (языки программирования)|метода]] (extract method)<br />
* Генерализация типа (generalize type)<br />
* Встраивание (inline)<br />
* Введение [[фабричный метод (шаблон проектирования)|фабрики]] (introduce factory)<br />
* Введение [[параметр (программирование)|параметра]] (introduce parameter)<br />
* Подъём метода (pull up method)<br />
* Спуск метода (push down method)<br />
* Переименование метода (rename method)<br />
* Перемещение метода (move method)<br />
* Замена условного оператора [[Полиморфизм (программирование)|полиморфизмом]] (replace conditional with polymorphism)<br />
* Замена [[наследование (программирование)|наследования]] [[делегирование (программирование)|делегированием]] (replace inheritance with delegation)<br />
* Замена кода типа подклассами (replace type code with subclasses)<br />
<br />
=== Изменение сигнатуры метода (change method signature) ===<br />
Суть изменения сигнатуры метода заключается в добавлении, изменении или удалении параметра метода. Изменив сигнатуру метода, необходимо скорректировать обращения к нему в коде всех клиентов. Это изменение может затронуть внешний интерфейс программы, кроме того, не всегда разработчику, изменяющему интерфейс, доступны все клиенты этого интерфейса, поэтому может потребоваться та или иная форма регистрации изменений интерфейса для последующей передачи их вместе с новой версией программы.<br />
<br />
=== Инкапсуляция поля (encapsulate field) ===<br />
{{Якорь|Инкапсуляция поля}}В случае, если у класса имеется открытое поле, необходимо сделать его закрытым и обеспечить методы доступа. После '''«Инкапсуляции поля»''' часто применяется '''«[[#Перемещения метода|Перемещение метода]]»'''.<br />
<br />
=== Выделение метода (extract method) ===<br />
{{Якорь|Выделения метода}}Выделение метода заключается в выделении из длинного и/или требующего комментариев кода отдельных фрагментов и преобразовании их в отдельные методы, с подстановкой подходящих вызовов в местах использования. В этом случае действует правило: если фрагмент кода требует комментария о том, что он делает, то он должен быть выделен в отдельный метод. Также правило: один метод не должен занимать более чем один экран (25-50 строк, в зависимости от условий редактирования), в противном случае некоторые его фрагменты имеют самостоятельную ценность и подлежат выделению. Из анализа связей выделяемого фрагмента с окружающим контекстом делается вывод о перечне параметров нового метода и его локальных переменных.<br />
<br />
=== Перемещение метода (move method) ===<br />
{{Якорь|Перемещения метода}}Перемещение метода применяется по отношению к методу, который чаще обращается к другому классу, чем к тому, в котором сам располагается.<br />
<br />
=== Замена условного оператора полиморфизмом (replace conditional with polymorphism) ===<br />
[[Условный оператор]] с несколькими ветвями заменяется вызовом полиморфного метода некоторого базового класса, имеющего подклассы для каждой ветви исходного оператора. Выбор ветви осуществляется неявно, в зависимости от того, экземпляру какого из подклассов оказался адресован вызов.<br />
<br />
Основные принципы:<br />
* вначале следует создать базовый [[Класс (программирование)|класс]] и нужное число подклассов;<br />
* в некоторых случаях следует провести оптимизацию условного оператора путём '''«[[#Выделения метода|Выделения метода]]»''';<br />
* возможно использование '''«[[#Перемещения метода|Перемещения метода]]»''', чтобы поместить условный оператор в вершину иерархии наследования;<br />
* выбрав один из подклассов, нужно конкретизировать в нём полиморфный метод базового класса и переместить в него тело соответствующей ветви условного оператора;<br />
* повторить предыдущее действие для каждой ветви условного оператора;<br />
* заменить весь условный оператор вызовом полиморфного метода базового класса.<br />
<br />
== Проблемы, возникающие при проведении рефакторинга ==<br />
* проблемы, связанные с базами данных;<br />
* проблемы изменения интерфейсов;<br />
* трудности при изменении дизайна.<br />
<br />
== Средства автоматизации рефакторинга ==<br />
Технические критерии для инструментов рефакторинга:<br />
* базы данных программы;<br />
* деревья синтаксического разбора;<br />
* точность.<br />
Практические критерии для инструментов рефакторинга:<br />
* скорость;<br />
* отмена модификаций;<br />
* интеграция с другими инструментами.<br />
<br />
== См. также ==<br />
* [[Шаблоны проектирования]]<br />
* [[Экстремальное программирование]]<br />
* [[Просмотр кода]]<br />
* [[Рефакторинг баз данных]]<br />
<br />
== Примечания ==<br />
{{примечания}}<br />
<br />
== Литература ==<br />
* {{книга<br />
|автор = [[Фаулер, Мартин|Фаулер М.]], Бек К., Брант Д., Робертс Д., Апдайк У.<br />
|заглавие = Рефакторинг: улучшение существующего кода<br />
|оригинал = Refactoring: Improving the Design of Existing Code (2000)<br />
|тираж = 3000<br />
|ссылка =<br />
|издание = <br />
|место = Спб <br />
|издательство = Символ-Плюс<br />
|год = 2009<br />
|страниц = 432<br />
|isbn = 5-93286-045-6<br />
}}<br />
* {{книга<br />
|автор = Скотт В. Эмблер, Прамодкумар Дж. Садаладж<br />
|заглавие = Рефакторинг баз данных: эволюционное проектирование<br />
|оригинал = Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series)<br />
|ссылка = https://archive.org/details/refactoringdatab0000ambl<br />
|издание = <br />
|место = М.<br />
|издательство = [[Вильямс (издательство)|«Вильямс»]]<br />
|год = 2007<br />
|страниц = 368<br />
|isbn = 0-321-29353-3<br />
}}<br />
* {{книга<br />
|автор = Джошуа Кериевски<br />
|заглавие = Рефакторинг с использованием шаблонов<br />
|оригинал = Refactoring to Patterns<br />
|издательство = Вильямс<br />
|год = 2008<br />
|страниц = 400<br />
|isbn = 5-93286-045-6<br />
|ref = Кериевски<br />
}}<br />
<br />
== Ссылки ==<br />
* [http://c2.com/cgi/wiki?WhatIsRefactoring Что такое рефакторинг?]{{ref|en}}<br />
* [http://www.refactoring.com/ Домашняя страница Мартина Фаулера о рефакторинге]{{ref|en}}<br />
* {{cite web|url=http://citforum.ru/SE/project/refactor/|author=Ксензов Михаил|title=Рефакторинг архитектуры программного обеспечения: выделение слоев|access-date=2007-11-30|description=Рассматривается один из основных методов рефакторинга архитектуры ПО – выделение слоев, а также его место в контексте рефакторинга архитектуры как многошагового итеративного процесса|url-status=live}}<br />
* [http://www.softkey.info/reviews/review5449.php Обзор программ для автоматического рефакторинга]<br />
* [http://blog.symprise.net/2009/04/revisiting-fowlers-video-store-refactoring-code-reengineering-abstractions/ Revisiting Fowler’s Video Store: Refactoring Code, Refining Abstractions]<br />
<br />
[[Категория:Программирование]]</div>imported>Alex NB OT