Вы проводите рефакторинг маленькими шагами?

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

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

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

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

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

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

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

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

Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring - which allows you to gradually refactor a system over an extended period of time. - Martin Fowler

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

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

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

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

Идея здесь в том, что если вы «начнете» с обналичивания призовых, то следующие X дней вы потратите на рутинную работу. И есть риск, может быть, вы откажетесь, или это не сработает - или потратите 6 месяцев вместо недели. Если вы сначала выполните тяжелую работу, обналичивание приза будет возможно с меньшим риском. И ваш код будет улучшаться по мере вашего продвижения. Иногда вы можете решить, что выполнить половину работы было достаточно, поскольку ваше понимание проблемы возрастает. Иногда ваше представление о том, куда вы хотите пойти, было немного неверным, и вы можете изменить свою цель по мере продвижения.

Но заманчиво сразу пойти за наградой.

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

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

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

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

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

NB. Кодовая база, над которой я работаю, довольно старая и полна тех мистических ошибок, названных в честь ученых. С большими частями, по-прежнему не хватает даже почти 50% тестового покрытия, было бы неосторожно увлекаться.

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