В компьютерном программировании и проектировании программного обеспечения рефакторинг кода — это процесс реструктуризации существующего исходного кода — изменение факторинга — без изменения его внешнего поведения. Рефакторинг предназначен для улучшения дизайна, структуры и/или реализации программного обеспечения (его нефункциональных атрибутов) при сохранении его функциональности . Потенциальные преимущества рефакторинга могут включать улучшенную читаемость кода и снижение сложности ; они могут улучшить поддерживаемость исходного кода и создать более простую, чистую или более выразительную внутреннюю архитектуру или объектную модель для улучшения расширяемости . Другая потенциальная цель рефакторинга — повышение производительности; инженеры-программисты сталкиваются с постоянной проблемой написания программ, которые работают быстрее или используют меньше памяти .
Обычно рефакторинг применяет ряд стандартизированных базовых микрорефакторингов , каждый из которых (обычно) является небольшим изменением в исходном коде компьютерной программы, которое либо сохраняет поведение программного обеспечения, либо, по крайней мере, не изменяет его соответствие функциональным требованиям. Многие среды разработки предоставляют автоматизированную поддержку для выполнения механических аспектов этих базовых рефакторингов. Если он выполнен правильно, рефакторинг кода может помочь разработчикам программного обеспечения обнаружить и исправить скрытые или неактивные ошибки или уязвимости в системе, упростив базовую логику и исключив ненужные уровни сложности. Если он выполнен плохо, он может не соответствовать требованию, что внешняя функциональность не должна изменяться, и, таким образом, может привести к появлению новых ошибок.
Постоянно улучшая дизайн кода, мы делаем его все более и более легким для работы. Это резко контрастирует с тем, что обычно происходит: мало рефакторинга и много внимания уделяется целесообразному добавлению новых функций. Если вы возьмете в гигиеническую привычку непрерывный рефакторинг, вы обнаружите, что расширять и поддерживать код становится проще.
— Джошуа Кериевски, Рефакторинг в шаблоны [1]
Рефакторинг обычно мотивируется обнаружением запаха кода . [2] Например, метод может быть очень длинным или может быть почти дубликатом другого соседнего метода. После обнаружения такие проблемы можно решить путем рефакторинга исходного кода или преобразования его в новую форму, которая ведет себя так же, как и раньше, но больше не «пахнет».
Для длинной процедуры можно извлечь одну или несколько меньших подпрограмм; или для дублирующих процедур дублирование можно удалить и заменить одной общей функцией. Невыполнение рефакторинга может привести к накоплению технического долга ; с другой стороны, рефакторинг является одним из основных средств погашения технического долга. [3]
Существует две основные категории преимуществ рефакторинга.
Инженерия производительности может устранить неэффективность в программах, известную как раздувание программного обеспечения, возникающее из традиционных стратегий разработки программного обеспечения, которые направлены на минимизацию времени разработки приложения, а не времени, необходимого для его запуска. Инженерия производительности также может адаптировать программное обеспечение к оборудованию, на котором оно работает, например, чтобы использовать преимущества параллельных процессоров и векторных блоков. [5]
Рефакторинг может быть выполнен двумя способами.
Метод, который уравновешивает профилактический и корректирующий рефакторинг, — это «разделенная ответственность за рефакторинг». Этот подход разделяет действие рефакторинга на два этапа и две роли. Первоначальный разработчик кода просто подготавливает код для рефакторинга, и когда код начинает пахнуть , последующий разработчик выполняет фактическое действие рефакторинга. [6]
Рефакторинг требует извлечения структуры программной системы, моделей данных и внутриприкладных зависимостей для получения знаний о существующей программной системе. [7] Текучесть кадров подразумевает отсутствие или неточность знаний о текущем состоянии системы и о проектных решениях, принятых уходящим разработчиками. Дальнейшие действия по рефакторингу кода могут потребовать дополнительных усилий для восстановления этих знаний. [8] Действия по рефакторингу приводят к архитектурным изменениям, которые ухудшают структурную архитектуру программной системы. Такое ухудшение влияет на архитектурные свойства, такие как поддерживаемость и понятность, что может привести к полной повторной разработке программных систем. [9]
Действия по рефакторингу кода защищены программным интеллектом при использовании инструментов и методов, предоставляющих данные об алгоритмах и последовательностях выполнения кода. [10] Предоставление понятного формата для внутреннего состояния структуры программной системы, моделей данных и внутрикомпонентных зависимостей является критически важным элементом для формирования высокоуровневого понимания и затем уточненных представлений о том, что и как необходимо изменить. [11]
Автоматические модульные тесты должны быть настроены перед рефакторингом, чтобы гарантировать, что процедуры по-прежнему ведут себя так, как ожидается. [12] Модульные тесты могут обеспечить стабильность даже для больших рефакторингов, если они выполняются с помощью одного атомарного коммита . Распространенная стратегия, позволяющая проводить безопасные и атомарные рефакторинги, охватывающие несколько проектов, заключается в хранении всех проектов в одном репозитории , известном как monorepo . [13]
При наличии модульного тестирования рефакторинг представляет собой итеративный цикл выполнения небольшого преобразования программы , его тестирования для обеспечения корректности и выполнения еще одного небольшого преобразования. Если в какой-либо момент тест не пройден, последнее небольшое изменение отменяется и повторяется другим способом. С помощью множества небольших шагов программа перемещается из того места, где она была, туда, где вы хотите, чтобы она была. Чтобы этот итеративный процесс был практичным, тесты должны выполняться очень быстро, иначе программисту пришлось бы тратить большую часть своего времени на ожидание завершения тестов. Сторонники экстремального программирования и других методов гибкой разработки программного обеспечения описывают эту деятельность как неотъемлемую часть цикла разработки программного обеспечения .
Вот несколько примеров микрорефакторинга; некоторые из них могут применяться только к определенным языкам или типам языков. Более длинный список можно найти в книге Мартина Фаулера по рефакторингу [2] [ нужна страница ] и на веб-сайте. [14] Многие среды разработки предоставляют автоматизированную поддержку для этих микрорефакторингов. Например, программист может щелкнуть по имени переменной, а затем выбрать рефакторинг «Инкапсулировать поле» из контекстного меню . Затем IDE запросит дополнительные сведения, как правило, с разумными значениями по умолчанию и предварительным просмотром изменений кода. После подтверждения программистом она выполнит требуемые изменения по всему коду.
Хотя термин «рефакторинг» изначально относился исключительно к рефакторингу программного кода, в последние годы код, написанный на языках описания оборудования, также был рефакторингован. Термин «рефакторинг оборудования» используется как сокращенный термин для рефакторинга кода на языках описания оборудования. Поскольку языки описания оборудования не считаются языками программирования большинством инженеров по оборудованию, [20] рефакторинг оборудования следует рассматривать как отдельную область от традиционного рефакторинга кода.
Автоматизированный рефакторинг описаний аналогового оборудования (в VHDL-AMS ) был предложен Зенгом и Хассом. [21] В их подходе рефакторинг сохраняет имитируемое поведение конструкции оборудования. Нефункциональное измерение, которое улучшается, заключается в том, что рефакторинг кода может быть обработан стандартными инструментами синтеза, в то время как исходный код не может. Рефакторинг языков описания цифрового оборудования, хотя и ручной рефакторинг, также был исследован сотрудником Synopsys Майком Китингом. [22] [23] Его цель — сделать сложные системы более простыми для понимания, что повышает производительность проектировщиков.
Первое известное использование термина «рефакторинг» в опубликованной литературе было в статье Уильяма Опдайка и Ральфа Джонсона , опубликованной в сентябре 1990 года . [24] Хотя рефакторинг кода неформально проводился в течение десятилетий, докторская диссертация Уильяма Гризволда 1991 года [25] является одной из первых крупных академических работ по рефакторингу функциональных и процедурных программ, за которой последовала диссертация Уильяма Опдайка 1992 года [26] по рефакторингу объектно-ориентированных программ, [27] хотя вся теория и механизмы уже давно доступны в виде систем преобразования программ . Все эти ресурсы предоставляют каталог общих методов рефакторинга; метод рефакторинга содержит описание того, как применять метод , и индикаторы того, когда следует (или не следует) применять метод.
Каноническим источником является книга Мартина Фаулера «Рефакторинг: улучшение существующего кода» . [ по мнению кого? ]
Термины «факторинг» и «факторинг» использовались таким образом в сообществе Форта по крайней мере с начала 1980-х годов. Шестая глава книги Лео Броди «Thinking Forth» (1984) [28] посвящена этой теме.
В экстремальном программировании метод рефакторинга Extract Method по сути имеет то же значение, что и факторизация в Forth: разбить «слово» (или функцию ) на более мелкие, более простые в обслуживании функции.
Рефакторинги также могут быть реконструированы [29] постфактум для создания кратких описаний сложных изменений программного обеспечения, записанных в репозиториях программного обеспечения, таких как CVS или SVN.
Многие редакторы программного обеспечения и IDE имеют автоматизированную поддержку рефакторинга. Вот список некоторых из этих редакторов, или так называемых браузеров рефакторинга .
{{cite thesis}}
: CS1 maint: бот: исходный статус URL неизвестен ( ссылка )