Рефакторинг кода при плохом проектировании системы

Ответ 1

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

Некоторые мысли:

• Контроль версий. Вы начали настройку подрывной деятельности. Теперь убедитесь, что ваши схемы базы данных, хранимые процедуры, скрипты, сторонние компоненты и т.д. Также находятся под контролем версий. У вас есть система маркировки версий, убедитесь, что вы наклеиваете версии и можете в будущем получить доступ к старым версиям.
• Сборка и выпуск. У вас есть способ создать стабильные версии на машине, отличной от вашей машины. Вы можете использовать ant/nant, make, msbuild или даже пакетный файл или оболочку script. Возможно, вам понадобятся сценарии развертывания/установщики, если они не существуют.
• Получить тест. Не изменяйте приложение, пока не найдете способ узнать, нарушило ли ваше изменение его. Для этого вам нужны тесты. Вы должны надеяться, что сможете написать блок-тесты xunit для некоторых более простых автономных классов, но попытайтесь создать некоторые тесты системы/интеграции, которые используют приложение в целом. Без высокого охвата кода (с которым вам не придется начинать) интеграционные тесты - ваш лучший выбор. Входите в привычку проводить тесты как можно чаще. Используйте все возможности для их расширения.
• Сделайте небольшие, сфокусированные изменения. Попытайтесь определить системы/подсистемы в приложении и улучшить границы между ними. Это уменьшает влияние изменений, которые вы можете сделать. Остерегайтесь соблазна "скорректировать" код, переформатировав его или наложив последний модный шаблон дизайна. Обход такой системы требует времени.
• Documentation. Это необходимо, но не беспокойтесь об этом слишком много. Системная документация редко используется в моем опыте. Хорошие тесты обычно лучше, чем хорошая документация. Сосредоточьтесь на документировании интерфейсов между приложением и системным контекстом, в котором он работает (входы, выходы, файловые структуры, схемы db и т.д.).
• Управлять ожиданиями. Если он будет в плохом состоянии, то он, вероятно, будет сопротивляться вашим усилиям по внесению изменений, а временные рамки могут быть более сложными, чем обычно. Убедитесь, что руководство и заинтересованные стороны понимают это.

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

Как младший разработчик, не бойтесь обращаться за помощью. Как говорили другие, "Эффективная работа с устаревшим кодом" - хорошая книга для чтения, как и рефакторинг Мартина Фаулера.

Удачи!

Ответ 2

Получить и прочитать Эффективно работать с устаревшим кодом. Это касается именно этой ситуации.

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

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

Обновление:. Для подсказок о том, как использовать устаревший код, вы можете найти этот более ранний ответ полезным.

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

Ответ 3

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

Система обструктивно нарушена, когда дело доходит до ремонтопригодности, однако, так это то, что вы решаете. Как уже упоминалось выше, сначала напишите несколько тестов, чтобы получить исходный код в cvs, и THEN начните сначала сначала очистить мелкие кусочки, затем большие и т.д. НЕ НАЙДИТЕ БОЛЬШИЕ архитектурные проблемы, пока не получите хорошее представление о том, как работает система. Инструменты не помогут вам, если вы сами не погружаетесь в код, но когда вы это делаете, они очень помогают.

Помните, что ничто не "идеально". Не переусердствуйте. Соблюдайте принципы KISS и YAGNI.

EDIT: Добавлена ​​прямая ссылка на статью YAGNI

Ответ 4

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

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

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

Как только вы поймете приложение, вы, по крайней мере, знаете, какая функциональность важна для тестирования (вручную или автоматически).

Ответ 5

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

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

Ответ 6

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

Затем вы можете попробовать написать unit test для основных частей вашей системы. Оттуда, когда у вас есть более или менее твердое тело регрессионных тестов, вы можете продолжить рефакторинг.

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

Ответ 7

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

Ответ 8

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

5. плохая таблица таблиц базы данных

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

Ответ 9

Мой стандартный ответ на этот вопрос: Реорганизовать низко висящие фрукты. В этом случае я был бы склонен взять один из 10-строчных классов и искать возможности Sprout Class, но это только мое собственная склонность; вам может быть удобнее сначала изменить другие вещи (настройка контроля источника была отличным первым шагом!) Проверьте, что вы можете сделать; рефакторинг, который не может быть протестирован, сделать шаг за шагом и сделать его лучше.

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

Ответ 10

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

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

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

Изменение плохой структуры базы данных сложнее всего, потому что плохо разработанные таблицы, вероятно, используются многими программами. Любое изменение базы данных требует изменения каждой программы, которая ее считывает или записывает. Лучший способ добиться этого - это, как правило, попытаться уменьшить количество мест, которые обращаются к любой части базы данных. Чтобы привести простой пример: предположим, что есть 20 мест, которые читают записи клиентов и вычисляют остаток на счете клиента. Замените это на одну функцию, которая считывает базу данных и возвращает итоговые значения, и двадцать вызовов этой функции. Теперь вы можете изменить схему для записей клиентов, и вместо 20 можно изменить только один фрагмент кода. Принцип достаточно прост, но на практике маловероятно, что каждая функция, которая обращается к данной записи, делает то же самое. Даже если первоначальный программист был достаточно неудобным, чтобы написать тот же код 20 раз (маловероятно - я видел много этого), реальная ситуация, вероятно, не в том, что он написал 1 функцию 20 раз, период, но что он написал функцию 20 раз, функция B 12 раз, функция C 4 раза и т.д.

Ответ 11

Хорошая книга по этому вопросу работает эффективно с устаревшим кодом Майкл Перс (2004). Он проходит через процесс внесения небольших изменений, одновременно работая над большей очисткой.

• Напишите unit test и найдите и удалите повторяющийся код.
• Напишите unit test и перерыв длинных методов в ряд коротких методов.
• Напишите unit test и найдите и удалите повторяющийся метод.
• Запишите unit test и разбейте классы, чтобы следовать принципу единой ответственности .

Ответ 12

Эффективная работа с устаревшим кодом может быть полезна.

Ответ 13

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

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

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

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

Ответ 14

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

Зафиксируйте все значения в SVN и TAG (в случае, если что-то пойдет не так, у вас будет escape-код).

Использовать плагин inCode Eclipse http://www.intooitus.com/inCode.html и искать, какие рефакторинги он предлагает. Убедитесь, что предложенные рефакторинги кажутся подходящими для вашей оценки. Попытайтесь понять их.

Повторите попытку с созданными ранее единицами.

Теперь вы можете использовать FindBugs и/или PMD для проверки других тонких проблем.

Если все в порядке, вы можете снова зарегистрироваться.

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