Как Вы осуществляете рефакторинг?

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

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

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

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

Третий шаг: Реализуйте лучшее решение.

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

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

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

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

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

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

, Как этот процесс отличается при рефакторинге кода, который не является Вашим?

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

Делают Вас тесты записи при рефакторинге?

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

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

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

Вот некоторые общие рекомендации:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте Martin Fowler книга" Рефакторинг "

BTW - это - собственная исполнительная ссылка Amazon Martin Fowler, если Вы задаетесь вопросом :)

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

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

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

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

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

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

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