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

Question

Прочитав «Рефакторинг» Фаулера некоторое время, я все еще часто ловлю себя на мысли: «Я должен был сделать это небольшими шагами». - даже когда я не сломал свой код.

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

Тем не менее: большую часть времени я занимаюсь рефакторингом большими шагами. Если я возьму часть раздела «Механика» Фаулера и сравню то, как я работаю, я, возможно, обнаружу, что часто прыгаю сразу на два или пять шагов вперед. Это не значит, что я гуру рефакторинга. Мой код может остаться на 5 - 60 минут неработающим или не компилируемым.

Проводите ли вы рефакторинг меньшими шагами и пытаетесь создать непрерывный код на более коротких частотах? И: Вы успешны в этом?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

Но заманчиво идти прямо к награде.

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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