У меня была дискуссия несколько недель назад с некоторыми сотрудниками по рефакторингу, и я, кажется, в меньшинстве, который считает, что "Рефакторинг на ранней стадии, рефакторинг часто" - это хороший подход, который не дает коду стать беспорядочным и неподъемным. Ряд других людей считал, что он просто принадлежит к этапам обслуживания проекта.
Если у вас есть мнение, пожалуйста, защитите его.
Как и вы сказали: рефакторинг рано, рефакторинг часто.
Рефакторинг рано означает, что необходимые изменения все еще свежи в моем сознании. Рефакторинг часто означает, что изменения, как правило, меньше.
Задержка рефакторинга заканчивается тем, что делает большой беспорядок, что еще больше усложняет рефакторинг. Очистка, как только я замечаю, что беспорядок мешает ему нарастать и становиться проблемой позже.
Код рефакторинга, как только он будет функционировать (все тесты проходят). Таким образом, я очищаю его, пока он еще свежий в моем сознании, и прежде чем кто-либо еще увидит, насколько уродливой была первая версия.
После начальной регистрации я обычно реорганизую каждый раз, когда я касаюсь части кода. Рефакторинг не является чем-то, на что вы должны выделить отдельное время. Это должно быть то, что вы просто делаете, когда идете.
Вы пишете код с двумя головками. Шапка "только что-на-вещь" и шляпа "Я-нужно-понять-это-завтра". Очевидно, что вторая шляпа является рефакторингом. Таким образом, вы рефакторируете каждый раз, когда вы что-то делаете, но имеете (неизбежно) введенные запахи, такие как дублированный код, длинные методы, хрупкую обработку ошибок, неправильные имена переменных и т.д....
Рефакторинг при попытке получить что-то работает (т.е. носить обе шляпы) нецелесообразно для нетривиальных задач. Но отложить рефакторинг до следующего дня/недели/итерации очень плохо, потому что контекст проблемы исчезнет с вашей головы. Поэтому переключайтесь между шляпами как можно чаще, но никогда не комбинируйте их.
Я реорганизую каждый шанс, который я получаю, потому что он позволяет мне отточить мой код в лучшем случае. Я делаю это, даже когда активно развивается, чтобы предотвратить создание недостижимого кода в первую очередь. Это также часто позволяет мне выправить плохое дизайнерское решение до того, как оно станет неустойчивым.
Три веские причины для реорганизации:
Три серьезных причины не рефакторировать:
"Беспощадный" спорный - есть допустимый аргумент, который по-разному называется "исправление разбитых окон" или "гигиена кода", что предполагает, что если вы позволите мелким вещам сползать, то вы также начнете пропускать большие вещи. Это прекрасно, и хорошо помнить, но помните, что это аналогия. Он не оправдывает шунтирующий материал бесконечно, в поисках самого чистого возможного решения.
Как часто вы, рефакторинг, должны зависеть от того, как часто возникают веские причины, и насколько вы уверены в том, что ваш тестовый процесс защищает вас от появления ошибок.
Рефакторинг никогда не является самоцелью. Но если что-то не работает, оно должно быть исправлено, и это верно как в первоначальном развитии, так и в обслуживании. Для нетривиальных изменений почти всегда лучше рефакторировать и включать новые понятия в чистоту, чем исправлять одно место с большими кусками мусора, чтобы избежать каких-либо изменений в другом месте.
Для чего это стоит, я не думаю об изменении интерфейса при условии, что у меня есть дескриптор того, что его использует, и что область результирующего изменения управляема.
Я пытаюсь пойти этим девизом: оставьте весь код, который вы касаетесь, лучше, чем это было.
Когда я делаю исправление или добавляю функцию, я обычно использую эту возможность, чтобы делать ограниченный рефакторинг на подверженном влиянию кодах. Часто это облегчает внесение моих предполагаемых изменений, поэтому на самом деле это ничего не стоит.
В противном случае вам следует выделить выделенное время для рефакторинга, если вы не можете, потому что вы всегда боретесь с огнями (интересно, почему), тогда вы должны заставить себя реорганизовать, когда находите, что внесение изменений становится намного сложнее, чем нужно, и когда "кодовые запахи" просто невыносимы.
Как говорится в книге, вы рефакторируете, когда
Много раз, когда я смываю идеи, мой код начинается очень тесно и беспорядочно. Когда я начинаю полировать идею, логические разделения начинают становиться все более ясными, и я начинаю рефакторинг. Это постоянный процесс, и, как полагают все, следует делать "Раннее и часто".
Я реорганизую, когда:
Я изменяю код, и я смущен этим. Если мне потребуется некоторое время, чтобы отсеивать его, он нуждается в рефакторинге.
Я создаю новый код и после того, как у меня получилось "работать". Часто я получаю работу, и, поскольку я кодирую, я понимаю: "Эй, мне нужно повторить то, что я сделал 20 строк, только с небольшими изменениями". В этот момент я реорганизую и продолжаю.
Единственное, что, на мой взгляд, должно помешать вам сделать это, - это временные ограничения. Нравится вам это или нет, иногда у вас просто нет времени на это.
Это похоже на национальные парки - всегда оставляйте его немного лучше, чем вы его нашли.
Для меня это означает, что каждый раз, когда я открываю код, и мне приходится почесывать голову, чтобы выяснить, что происходит, мне нужно что-то реорганизовать. Моя основная цель - читаемость и понимание. Обычно это просто переименование переменной для ясности. Иногда он извлекает метод -
Например (тривиальный), если я натолкнулся
temp = array[i];
array[i] = array[j];
array[j] = temp;
Я бы, вероятно, заменил это методом swap (i, j).
Компилятор, скорее всего, встроит его, и swap() все семантически говорит, что происходит.
С учетом моего собственного кода (начиная с нуля), я склонен к реорганизации проекта. Мне часто легче работать в конкретном классе. Когда он будет выполнен и отлажен, я вытащу старый трюк интерфейса извлечения.
Я оставлю его сотруднику для рефакторинга для удобочитаемости, поскольку я слишком близок к коду, чтобы заметить дыры. В конце концов, я знаю, что я имел в виду.
Рефактор оппортунистически! Делайте это, когда это легко.
Если рефакторинг затруднен, вы делаете это в неподходящее время (когда код ему не нужен) или на неправильной части кода (где есть более эффективная эффективность, которую нужно получить в любом месте). (Или вы еще не очень хорошо разбираетесь в рефакторинге.)
Сохранение рефакторинга для "обслуживания" - тавтология. Рефакторинг - это обслуживание.
Я реорганизую каждый раз, когда я читаю, и могу сделать его более удобочитаемым. Не большая реструктуризация. Но если я подумаю: "Что это за List содержит? О, Integer s!" то я изменю его на List<Integer>. Кроме того, я часто извлекаю методы в среде IDE, чтобы указать хорошее имя нескольких строк кода.
Каждый раз, когда вы сталкиваетесь с необходимостью. По крайней мере, когда вы собираетесь изменить фрагмент кода, который нуждается в рефакторинге.
Ответ всегда, но более конкретно:
Я локализую рефакторинг для кода, связанного с моей текущей задачей. Я пытаюсь сделать свой рефакторинг впереди. Я выполняю эти изменения отдельно, поскольку с функциональной точки зрения он не связан с реальной задачей. Таким образом, код работает более чистым, и история изменений также более чистая.
"Рефакторинг на ранней стадии, рефакторинг часто" является продуктивным ориентиром. Хотя такой тип предполагает, что вы действительно знаете код. Чем старше система получает, тем более опасный рефакторинг становится, и тем больше обдумываний требуется. В некоторых случаях реорганизация должна управляться задачами, с оценкой уровня усилия и времени и т.д.
Постоянно, в пределах разумного. Вы всегда должны искать способы улучшить свое программное обеспечение, но вы должны быть осторожны, чтобы избежать ситуаций, когда вы рефакторинг для рефакторинга (Refactorbation).
Если вы можете сделать так, что рефакторинг сделает код более быстрым, более легким для чтения, проще в обслуживании или упростит или предоставит какую-то другую ценность для бизнеса, о котором я говорю, зайдите на него!
Если у вас есть инструмент рефакторинга, который сделает изменения безопасно, вам следует реорганизовать всякий раз, когда код будет компилировать, если он сделает код более понятным.
Если у вас нет такого инструмента, вы должны реорганизовать , когда тесты зеленые, если он сделает код более понятным.
Сделайте небольшие изменения - переименуйте метод, чтобы сделать то, что он делает более понятным. Извлеките класс, чтобы сделать группу взаимосвязанных переменных четко связанной. Рефакторинг заключается не в внесении больших изменений, а в том, чтобы делать вещи чистыми за минуту. Рефакторинг очищает ваши блюда после каждого приема пищи, вместо того, чтобы ждать, пока каждая поверхность будет покрыта грязными пластинами.
Абсолютно, как только это кажется целесообразным. Если вы не боретесь.
Так как переход на Squeak (который я теперь упоминаю каждый пост), я понял, что многие вопросы дизайна во время прототипирования отпадают, потому что рефакторинг в этой среде очень прост. Если честно, если у вас нет среды, где рефакторинг в основном безболезнен, я рекомендую вам попробовать писк, чтобы знать, как это может быть.
Рефакторинг часто часто может сохранять день или, по крайней мере, некоторое время. Был проект, над которым я работал, и мы переработали весь наш код после того, как мы достигли какой-то важной вехи. Это был отличный способ, потому что, если нам нужно было разорвать код, который больше не был полезным, он упростил исправление любой новой вещи, в которой мы нуждались.
Мы сейчас обсуждаем эту работу. Мы более или менее согласны с тем, что "напишите, чтобы он работал, а затем исправить". Но мы расходимся во времени. Я больше "исправляю это сразу", мой коллега более "исправляет его на следующей итерации".
Некоторые цитаты, которые поддерживают его:
Дуглас Крокфорд, старший архитектор Javascript Yahoo:
рефакторинг каждые 7 спринт.
Кен Томпсон (человек unix):
Код сам по себе почти гниет, и это собираемся переписать. Даже когда ничего изменилось, по какой-то причине оно гниет.
Я хотел бы, чтобы после выполнения задачи, представленной кодом, вы можете вернуться через 2 месяца и подумать "да, я здесь хорошо". Я не считаю, что легко найти время, чтобы вернуться позже и исправить это. полагая, что это несколько наивно с моей точки зрения.
Изменить: орфографическая ошибка
Думаю, вам нужно что-то реорганизовать, когда вы сейчас работаете над его частью. Значит, если вам нужно усилить функцию A, вам следует реорганизовать ее до (и после?). Если вы ничего не делаете с этой функцией, оставьте ее как есть, если у вас есть что-то еще.
Не реорганизуйте рабочую часть системы, если вам уже не нужно ее менять.
Существует много мнений по этой теме, некоторые из которых связаны с конкретной методологией или подходом к развитию. При использовании TDD рефакторинг рано и часто является, как вы говорите, предпочтительным подходом.
В других ситуациях вы можете рефакторировать по мере необходимости. Например, когда вы просматриваете повторяющийся код.
При использовании более традиционных методов с подробным предварительным дизайном рефакторинг может быть реже. Однако я бы рекомендовал не оставлять рефакторинг до конца проекта. Не только вы, вероятно, столкнетесь с проблемами, потенциально пост-UAT, часто также бывает, что рефакторинг становится все более сложным. По этой причине временные ограничения для классического проекта вызывают рефакторинг и дополнительное тестирование, которые нужно отбросить, и когда вы будете поддерживать обслуживание, возможно, вы уже создали монстра-спагетти-кода.
Если он не сломан, не рефакторируйте его.
Я бы сказал, что время рефактору принадлежит к начальной стадии кодирования, и ou может делать это так часто и столько раз, сколько вам нравится. Как только он находится в руках клиента, тогда это становится другим вопросом. Вы не хотите делать работу для себя, "убирая" код только, чтобы обнаружить, что он отправлен и что-то сломал.
Время после первоначальной доставки в рефакторинг - это когда вы говорите, что сделаете это. Когда код становится слишком вонючим, тогда у вас есть специальный выпуск, содержащий рефакторинги и, возможно, еще несколько важных исправлений. Таким образом, если вам что-то сломать, вы знаете, где это пошло не так, вы можете гораздо легче исправить это. Если вы будете реорганизовать все время, вы нарушите все, вы не узнаете, что его сломал до тех пор, пока он не получит QAd, и тогда вам будет трудно найти, изменились ли изменения кода ошибки/функции, или некоторые из них рефакторинг вы провели много лет назад.
Проверка изменений в cbreaking намного проще, когда код выглядит примерно так, как он использовался. Рефакторинг много структуры кода, и вы можете сделать это практически невозможным, так что только рефакторинг, когда вы серьезно это означаете. Относитесь к нему так же, как и любой другой код продукта, и вы должны быть в порядке.
Я думаю, что это сообщение в Top 100 Wordpress может иметь хороший совет. http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/