Код рефакторинг на плохой дизайн системы

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

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

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

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

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

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

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

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

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

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

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