Как вы рефакторинг?

Ответ 1

• не реорганизуйте что-либо нетривиальное, которое еще не имеет модульных тестов
• пишите блок-тесты, затем рефакторинг
• реорганизовать небольшие кусочки и повторно запустить тесты часто
• остановить рефакторинг, когда код DRY ^* clean

^* DRY = Не повторяйте себя

Ответ 2

Каков ваш первый шаг?

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

Как этот процесс отличается, если вы не используете код рефакторинга?

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

Вы пишете тесты во время рефакторинга?

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

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

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

Вот несколько общих советов:

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

Золотое правило никогда не рефакторизуется, когда тесты устройства не проходят полностью.

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

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

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

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

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

Ответ 3

Я беру дерьмо и делаю его менее дерьмовым.: -)

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

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

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

Ответ 4

Прочитайте Мартин Фаулер книга " Рефакторинг"

BTW - что Мартин Фаулер владеет ссылкой Amazon exec, если вам интересно:)

Ответ 5

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

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

Ответ 6

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

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

И, наконец, посмотрите, есть ли способ сделать код более читаемым. Обычно это достигается путем превращения 5 небольших скриптов, которые делают подобные вещи в 1 модуль (класс).

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

Я согласен с другими плакатами, когда вы реорганизуете код, который вы написали.

Если это код, который вы не писали, и особенно если его много, я бы начал с использования таких инструментов, как fxCop, Visual Studio Code Analysis, DevPartner - я уверен, что есть и другие хорошие. Они дадут вам представление о том, с чего начать и каковы наиболее распространенные проблемы с кодированием. Я бы также проводил стресс-тестирование, чтобы увидеть, где узкие места, поэтому наибольшая отдача от ваших усилий по улучшению кода.

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

Ответ 13

Первый шаг: Определите запах кода.

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

Третий шаг: выполните лучшее решение.

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

Ответ 14

Общий подход

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

Инструменты торговли

Инструменты анализа зависимостей:

• Python
• Java