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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

Изменить В ответ на комментарии: -

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

В любое время вы видите что-то, что должно быть сделано лучше, Refactor.

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

Ответ 8

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