Как часто вы должны рефакторинг?

Question

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

Если у вас есть мнение, защитите его.

Answer 1

Точно так же, как вы сказали: рефакторинг рано, рефакторинг часто.

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

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

Answer 2

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

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

Answer 3

Вы пишете код с двумя шляпами. Шляпа 1002 * "Просто получи, что работает" и шляпа "1003 ", которую мне нужно понять, это завтра . Очевидно, что вторая шляпа является рефакторингом. Таким образом, вы выполняете рефакторинг каждый раз, когда заставляете что-то работать, но (неизбежно) вводите запахи, такие как дублированный код, длинные методы, хрупкая обработка ошибок, неправильные имена переменных и т. Д. *

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

Answer 4

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

Answer 5

Три веских причины для рефакторинга:

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

Три веские причины не проводить рефакторинг:

• «Это выглядит немного грязно».
• «Я не совсем согласен с тем, как это делал последний парень».
• «Это может быть более эффективно». (Проблема в том, что «может»).

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

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

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

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

Answer 6

Как сказано в книге, вы рефакторинг, когда

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

Answer 7

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

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

В противном случае вам следует выделить время, выделенное на рефакторинг, если вы не можете этого сделать, потому что вы всегда боретесь с пожарами (интересно, почему), тогда вы должны заставить себя провести рефакторинг, когда обнаружите, что вносить изменения становится намного сложнее, чем когда-либо ». запахи кода "просто невыносимы.

Answer 8

Много раз, когда я выкидываю идеи, мой код начинается очень тесно и грязно. Когда я начинаю дорабатывать идею, логическое разделение становится все более и более ясным, и я начинаю рефакторинг. Это постоянный процесс, и, как все предлагают, нужно делать «рано и часто».

Answer 9

Это как национальные парки - всегда оставляйте это немного лучше, чем вы его нашли.

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

Например (тривиально), если я сталкивался

temp = array[i];
array[i] = array[j];
array[j] = temp;

Я бы, вероятно, заменил это методом swap (i, j).

Компилятор, скорее всего, все равно его встроит, и swap () семантически расскажет всем, что происходит.

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

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

Answer 10

Я выполняю рефакторинг, когда:

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

Я создаю новый код, и после того, как он у меня "работает". Часто я работаю, и когда я пишу код, я понимаю: «Эй, мне нужно повторить то, что я сделал, на 20 строк, только с несколькими изменениями». В этот момент я выполняю рефакторинг и продолжаю.

Единственное, что, по моему мнению, должно мешать вам делать это, это ограничения по времени. Нравится вам это или нет, но иногда у вас просто нет времени на это.