Как часто следует проводить рефакторинг?

Question

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

Если у вас есть мнение, пожалуйста, отстаивайте его.

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

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

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

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

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

Я рефакторингую, когда:

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

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

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

Answer 10

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

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

Например (тривиально): Если бы я встретил

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

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

Компилятор, скорее всего, в любом случае встроит его, и функция swap() семантически сообщит всем, что происходит.

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

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

Answer 11

Рефакторинг оппортунистически!Делай это всякий раз, когда это легкий.

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

Сохранять рефакторинг ради «обслуживания» — тавтология.Рефакторинг является обслуживание.

Answer 12

Я делаю рефакторинг каждый раз, когда читать что угодно и смогу это сделать более читаемый.Это не серьезная реструктуризация.Но если я думаю про себя: «Что это значит?» List содержать?Ой, Integerс!", тогда я изменю его на List<Integer>.Кроме того, я часто извлекаю методы из IDE, чтобы дать доброе имя нескольким строкам кода.

Answer 13

Ответ всегда, но более конкретно:

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

Answer 14

Каждый раз, когда вы сталкиваетесь с необходимостью.По крайней мере, когда вы собираетесь изменить кусок кода, требующий рефакторинга.

Answer 15

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

Answer 16

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

Если вы можете доказать, что рефакторинг сделает часть кода более быстрой, более легкой для чтения, более простой в обслуживании или более простой или принесет какую-то другую ценность для бизнеса, я говорю: действуйте!

Answer 17

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

Answer 18

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

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

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

Answer 19

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

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

Answer 20

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

Answer 21

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

Несколько цитат, подтверждающих его:

Дуглас Крокфорд, старший архитектор Javascript Yahoo:

рефакторинг каждый 7-й спринт.

Кен Томпсон (человек Unix):

Код сам по себе почти гниет, и он будет переписан.Даже когда ничего не изменилось, по какой -то причине это гниет.

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

Редактировать:орфографическая ошибка

Answer 22

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

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

Answer 23

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

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

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

Answer 24

Если он не сломан, не проводите его рефакторинг.

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

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

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

Answer 25

Я думаю, что этот пост в блоге Top 100 Wordpress может дать несколько хороших советов.http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/