Постоянно рефакторинг моего собственного кода... очень плохая практика

Ответ 1

Взгляните на TDD. Основная посылка:

• написать неудачный тест
• написать код, чтобы пройти тест
• агрессивно рефакторинг

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

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

НТН

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Однако, как только вы пройдете пару циклов интеграции и UAT-тестов, я бы начал осторожно относиться к рефакторингу. В конце концов, вы потратили время и силы на проверку кода, который у вас есть; рефакторинг будет тратить эти усилия на испытания и потребовать повторения всего цикла испытаний.

Ответ 7

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

Ответ 8

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

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

Во время рефакторинга иногда вы обнаруживаете проблемы/случаи, которые не видят QA или текстовое крепление, но также возможно родить другие проблемы, которые могут стать невидимыми... что-то, что нужно иметь в виду.

Я бы сказал, продолжайте рефакторинг фрагмента кода, если вы:

• не имеют более важных задач в вашей очереди
• вы устраняете проблему, связанную с производительностью.
• другие товарищи по команде думают, что ваш код сосет (грязный код) и должен быть организован лучше! в этом случае вы единственный разработчик, поэтому вам нужно судить о своих вещах.
• вы написали 40 строк кода для чего-то, что ВЫ ЗНАЛИ, могли быть написаны в 2 строках, но нужно было быстро его освободить.

Messy code = объявление переменных по всему месту, а не использование объектно-ориентированного принципа, а не инкапсуляция фрагментов кода и повторная запись одного и того же кода несколько раз, зацикливание везде! неприятные соединения, комментарии и т.д. и т.д.

У кого-нибудь больше случаев?

Ответ 9

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

Вы можете указать несколько причин для этого:

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

Из них, я бы сказал, отбросить # 1 и # 2 и придерживаться только # 3. Вот почему. Рефакторинг не должен изменять поведение, поэтому реорганизованный код должен выполняться идентично оригиналу (для этого есть некоторые предостережения о крайнем случае, но никогда не рассматривайте рефакторинг как подход к оптимизации). Правила оптимизации:

• Не
• См. Правило №1;
• Если вам абсолютно необходимо профиль, тогда оптимизируйте только медленные биты.

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

В отношении повторного использования - YAGNI. Когда "поздний проект" приходит - если когда-либо - и вы знаете, что что-то, что вы могли бы взять взаймы из предыдущего проекта, если бы это было немного иначе - время для редизайна, чтобы удовлетворить новые потребности. До того, как этот проект существует, вы уже реорганизовали код первого проекта, чтобы в идеальном случае удовлетворить его (однопроектные) потребности; только когда возникает новая потребность, еще одна идея более желательна. Не ожидайте. Подождите, пока вам не понадобится управлять своим дизайном.

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

Ответ 10

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