2008-12-01 3 views
22

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

Текущая структура в основном:

  • Большой шар из грязи

Конечная цель состоит в том, чтобы достичь DDD-подобной структуры:

  • DAL
  • модель домена
  • Сервисный уровень
  • Презентация модели
  • GUI

Итак, как бы вы атаковать эту проблему?

  • Большой взрыв
    • Определить структуру конечного состояния и нажать код на его конечной дома.
  • Разделяй и властвуй
    • Пытаться отделить большой шар грязи на две части. Повторяйте, пока не сделано ...
  • удушающий

ответ

15

Никогда не пытайтесь «Большой взрыв». Это почти всегда дует вам в лицо, так как это очень рискованная, отчаянная мера, когда все остальное потерпело неудачу.

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

Наверное, я использовал что-то вроде «Удушения» на протяжении большей части своей карьеры: постепенно превращал плохой старый код в блестящий новый код. Вот мой рецепт:

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

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

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

Недостаток: вам нужно много времени, и вы почувствуете разочарование, потому что часто прогресс будет казаться таким медленным, пока «узел» не появится, и внезапно все начинает падать на место, как по волшебству.

0

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

1

Зависит от того, должно ли вы иметь всегда рабочее состояние, чтобы вы могли исправлять ошибки и развертывать их каждый раз при необходимости, тогда Devide и Conquer были бы хорошим решением. Если вы можете сохранить старый код, работая над новым (и попросите ученика применить исправления ошибок к кодам), переписывание может быть лучшим решением.

6

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

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

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

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

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

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

1

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

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

-1

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

1

Для меня это зависит от ситуации.

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

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

BigBang очень рискован, поскольку у вас нет простого способа проверить, что обновленная система выполняет то же, что и старое.

Divide and Conquer менее рискован, чем BigBang ... но если его достаточно большая система, это может оказаться столь же проблематичным, как BigBang.

1

Большой взрыв/Big редизайн/переписывание SW ... или любые другие имена не работает для жизни SW. Причины:

  • Вы все еще должны поддерживать существующий SW с (возможно) те же ресурсы у вас есть.

  • У вас, вероятно, нет требований для перезаписи. У вашего старого кода есть все требования, встроенные в него. Никто из ваших инженеров не знает всех доменов SW и всех требований.

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

Смежные вопросы