У меня есть странный вопрос.
Я единственный программист, который постоянно чувствует, что мне нужно переписать/реорганизовать мои собственные коды?
Иногда я делаю это только потому, что думаю, что скорость может быть улучшена, или просто потому, что я верю код может быть легко импортирован в более поздний проект.
Эй, иногда только потому, что он выглядит чище для моих глаз.
Мне больно? Я тоже перфекционизм? Я единственный, у кого есть эта проблема?
Взгляните на TDD. Основная посылка:
В качестве общего принципа я считаю, что агрессивный рефакторинг - хорошая идея - почему у вас больше кода, чем вам действительно нужно. Трудность состоит из двух частей: во-первых, почему рефакторинг без цели и во-вторых, как вы знаете, что вы не функционально изменили реорганизованный код, если у вас нет набора тестов, против которых вы можете протестировать рефакторингу? TDD является ответом на обе эти вещи.
Я бы посоветовал вам привыкнуть к рефакторингу, но я также рекомендовал бы такую практику, как TDD, чтобы вы не нарушили свой код, как вы это делаете.
НТН
Вероятно, вы просто испытываете итеративное понимание проблемы. Вы делаете для него удар, а затем, когда вы закончите, вы приобрели новое понимание. Это новое понимание, которое вы применяете, только чтобы узнать, что у вас появилось новое понимание, поэтому вы бросаете часть кода и переписываете его.
Вы не должны менять код быстрее, если считаете. Вы должны измерять через профилирование или настенные часы. И вы должны знать, на каком уровне вам нужен код. Некоторый код требует очень небольшого улучшения скорости, чтобы быть адекватным.
Нет, ты не один. Я бы сказал, это именно то, что делает хорошего программиста - никогда не удовлетворенным тем, что вы делаете, стремясь улучшить себя, а не повторять одни и те же вещи снова и снова.
Иногда я реорганизую, чтобы упростить чтение или запуск быстрее или проще. Однако в реальном мире с крайними сроками и работая на себя, вы можете позволить себе это сделать, если у вас есть причина сделать это!
Я нашел это правило полезного: "Я не должен тратить больше времени на рефакторинг, чем на реализацию запрошенных пользователем функций".
У меня могло бы быть много других идей о том, как можно улучшить код, но я считаю полезным немного его улучшить, каждый раз, когда я работаю над ним, вместо того, чтобы пытаться достичь "совершенства" сразу со всем кодом.
Это похоже на девиз мальчишеского скаута: оставьте его лучше, чем когда вы его нашли.
На ранних этапах проекта вы должны постоянно реорганизовывать рефакторинг. Вы, вероятно, не собираетесь ударить по лучшему решению сразу, а изменения требований могут сделать ранее совершенное решение неоптимальным.
Однако, как только вы пройдете пару циклов интеграции и UAT-тестов, я бы начал осторожно относиться к рефакторингу. В конце концов, вы потратили время и силы на проверку кода, который у вас есть; рефакторинг будет тратить эти усилия на испытания и потребовать повторения всего цикла испытаний.
лично я бы скорее работал над кодом, подобным выше/кем-то, чем с кодом того, кто просто покидает его после первой попытки. просто не забудьте попасть в золотое покрытие.
Все зависит, если вы можете позволить себе рефакторинг, то есть у вас нет других более важных задач в вашей очереди, тогда рефакторинг в "более удобный для чтения" код всегда хорош;)
Это также зависит от ситуации. Если вы являетесь частью более крупной команды, то рефакторинг может означать более быстрое изучение вашего кода другими разработчиками.
Во время рефакторинга иногда вы обнаруживаете проблемы/случаи, которые не видят QA или текстовое крепление, но также возможно родить другие проблемы, которые могут стать невидимыми... что-то, что нужно иметь в виду.
Я бы сказал, продолжайте рефакторинг фрагмента кода, если вы:
Messy code = объявление переменных по всему месту, а не использование объектно-ориентированного принципа, а не инкапсуляция фрагментов кода и повторная запись одного и того же кода несколько раз, зацикливание везде! неприятные соединения, комментарии и т.д. и т.д.
У кого-нибудь больше случаев?
Вы спрашиваете о переписывании и рефакторинге, и я боюсь, что ответы разные. Если вы постоянно занимаетесь рефакторингом, вам по существу не нужно переписывать. Рефакторинг, сделанный хорошо, превращает ваш код в идеальное состояние для его текущих потребностей без перезаписи. Это замечательная вещь.
Вы можете указать несколько причин для этого:
Из них, я бы сказал, отбросить # 1 и # 2 и придерживаться только # 3. Вот почему. Рефакторинг не должен изменять поведение, поэтому реорганизованный код должен выполняться идентично оригиналу (для этого есть некоторые предостережения о крайнем случае, но никогда не рассматривайте рефакторинг как подход к оптимизации). Правила оптимизации:
И оптимизация, как правило, больше связана с переписыванием, чем с рефакторингом. Рефакторинг может помочь вам оптимизировать работу (метод извлечения приходит на ум), но он, как правило, не сделает ваш код более эффективным. Так что не рефакторинг "чтобы сделать ваш код быстрее"; рефакторе в процессе создания кода быстрее, потому что вы оптимизируете - не по прихоти.
В отношении повторного использования - YAGNI. Когда "поздний проект" приходит - если когда-либо - и вы знаете, что что-то, что вы могли бы взять взаймы из предыдущего проекта, если бы это было немного иначе - время для редизайна, чтобы удовлетворить новые потребности. До того, как этот проект существует, вы уже реорганизовали код первого проекта, чтобы в идеальном случае удовлетворить его (однопроектные) потребности; только когда возникает новая потребность, еще одна идея более желательна. Не ожидайте. Подождите, пока вам не понадобится управлять своим дизайном.
Итог: рефакторинг, чтобы сделать код лучше для его непосредственных потребностей. Сделайте его доступным для чтения, сделайте его пригодным для обслуживания. Используйте рефакторинг для поддержки других операций, но не в ожидании их. И не чувствуйте себя плохо в рефакторинге все время. Если что-то не так выглядит в вашем коде, полезно исправить его.
Я делаю то же самое. В конечном счете, я надеюсь, что это заставит меня писать код чище, быстрее, многократно использовать и т.д. Сразу. И я верю, что это уже происходит. Я все больше думаю о новой строке кода, прежде чем я ее взломаю. Поэтому я надеюсь сделать меньше рефакторинга в будущем. Но верьте, что я только доберусь туда, через рефакторинг.