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

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

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

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

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

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

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

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

... Я думаю, вы совершенно правы.

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

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

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

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

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

Типичный случай рефакторинга:

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

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

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

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

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

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

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

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

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

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

Если это метод, сохраните имя, входные аргументы, тип возвращаемого значения и, возможно, операторы вызова. Примените все изменения внутри метода, не изменяя его внешний вид.

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

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

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

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

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

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

---

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

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

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

---

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

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

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

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

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

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

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

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

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

• ощутимые улучшения. Но все вместе они борются с медленной эрозией.

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

• ощутимые улучшения. Но все вместе они борются с медленной эрозией.

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