Преждевременный рефакторинг?[закрыто]

Question

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

Прежде всего, прочтите основополагающую работу Мартина Фаулера. "Рефакторинг" буквально изменил мою жизнь в отношении программирования.

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

Каковы ваши мысли, идеи и/или мнения по этому вопросу?Есть ли у вас какие-либо советы или общие антипаттерны, связанные с этой проблемой?

РЕДАКТИРОВАТЬ:

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

Answer 1

Я на самом деле думаю наоборот.

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

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

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

Помните, что технически рефакторинг НИКОГДА не должен загонять вас в угол — речь идет о переработке внутренних компонентов без изменения способа использования класса.Если вы попадаете в ловушку рефакторинга, это означает, что ваш первоначальный проект был ошибочным.

Скорее всего, вы обнаружите, что со временем эта проблема становится все лучше и лучше.Дизайн вашего класса и структуры, вероятно, станет более гибким.

Answer 2

Мы все слышали о преждевременной оптимизации, но что вы думаете о преждевременном рефакторинге?По вашему мнению, есть ли такое?

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

Чтобы понять почему, представьте, что вы пишете программное обеспечение для анализа налоговых деклараций для IRS.Внезапно в последнюю минуту вводятся новые правила, которые разрушают некоторые из ваших первоначальных предположений.Хотя вы хорошо проектировали, ваша доменная модель фундаментально ушла из-под ног как минимум в одном важном месте.Сегодня 14 апреля, и проект должен быть запущен завтра, будь то ад или паводок.Что вы делаете?

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

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

Answer 3

Я думаю, что рефакторинг возможен слишком рано.

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

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

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

Редактировать В ответ на комментарии: -

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

Кто-нибудь помнит методы структурированного проектирования конца 1980-х и начала 1990-х годов, когда все проблемы решались с помощью умных диаграмм, прежде чем писать строку кода?

Answer 4

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

Answer 5

Я думаю, что любой проект «1.0» подвержен такого рода…назовем это «итеративным дизайном».Если у вас нет четкой спецификации, прежде чем вы начнете проектировать свои объекты, вы, вероятно, будете думать о многих проектах и ​​подходах к решению проблем.

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

Answer 6

Есть несколько многообещающих решений проблем такого типа, в зависимости от ситуации.

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

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

Answer 7

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

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

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

Answer 8

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