Что такое рефакторинг и что только изменяет код?

Ответ 1

Мартин Фаулер "Рефакторинг: улучшение дизайна существующего кода", возможно, является ссылкой:

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

Рефакторинг идет рука об руку с модульным тестированием. Напишите тесты перед рефакторингом, и тогда у вас будет уровень уверенности в рефакторинге (пропорциональный охвату тестов).

Хорошая ссылка: информация о рефакторинге

Ответ 2

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

Если мы делаем рефакторинг или модификацию кода, сохраняющего поведение:

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

Если мы вносим изменения, изменяющие поведение:

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

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

Ответ 3

Чтобы показать свое мнение:

Небольшие инкрементные изменения, которые оставляют код в лучшем состоянии, чем было найдено

Определенно Да: "Косметологические" изменения, которые не имеют прямого отношения к функциям (т.е. они не оплачиваются как запрос на изменение).

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

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

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

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

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

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

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

Как стена гальки, где каждый день падает на землю. И каждый день, один прохожий берет его и возвращает обратно.

Ответ 4

С учетом определения Мартина Фаулера,

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

... Я думаю, что вы явно правы.

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

Изменение алгоритма на что-то намного быстрее, очевидно, не рефакторинг, потому что меняется внешнее поведение! (Опять же, если эффект никогда не заметен, возможно, вы могли бы назвать его рефакторингом в конце концов - и также преждевременную оптимизацию.:-)

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

Ответ 5

Я думаю, что вы правы, но спорить о значении слова не особенно интересно или продуктивно.

Ответ 6

Если интерфейс к части кода изменяется, то я считаю, что больше, чем рефакторинг.

Типичным примером для рефакторинга является

• "О, все мои модульные тесты запускаются, но я думаю, что мой код можно сделать более чистым"
• Изменить код, чтобы быть более читаемым/более четким/эффективным
• Повторно запустить модульные тесты (без изменения тестов) и проверить, что они все еще работают.

Это означает, что термин "рефакторинг" относится к интерфейсу, который вы обсуждаете. то вы могли бы реорганизовать код за одним интерфейсом, а более широко изменять код другого на более низком уровне (возможно, это различие - вот что создает путаницу между вами и вашими коллегами здесь?)

Ответ 7

http://en.wikipedia.org/wiki/Code_refactoring

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

Я согласен, что код рефакторинга включает в себя нарушение существующего кода. Просто убедитесь, что у вас есть модульные тесты, чтобы вы не вводили никаких ошибок, а остальная часть кода компилируется. Использование инструментов рефакторинга, таких как Resharper for С#, делает это настолько простым!

• Создание кода более понятным
• Очистка кода и упрощение его
• Удаление кода! Избыточный, неиспользуемый код и комментарии должны быть удалены.
• Повышение производительности
• Создание чего-то более общего. Начните с самой простой вещи, а затем реорганизовать ее, чтобы было легче тестировать/изолировать или генерировать, чтобы она могла работать по-разному с помощью полиморфизма.
• Хранение кода DRY - Не повторяйте себя, поэтому сеанс рефакторинга может включать повторный код и рефакторинг его в один компонент/класс/модуль.

Ответ 8

I не согласен:

В разработке программного обеспечения, "рефакторинг" исходный код означает его улучшение без изменение его общих результатов [...]

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

Ответ 9

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

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

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

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

Ответ 10

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

http://www.schibsted.pl/blog/back-end/refactoring/

Ответ 11

Рефакторинг = улучшение нефункциональных требований при сохранении неизменных функциональных.

Не функциональные требования = модульность, тестируемость, ремонтопригодность, удобочитаемость, разделение интересов, принципы Лискова и так далее...