Работать с базой кода, которую вы описываете, нелегко с множеством проблем, объединенных в то, что вы не знаете, как начать меняться.Существуют сильные зависимости между классами, а также между проблемами и, возможно, вообще нет общего дизайна.
По моему опыту, это требует больших усилий и времени, а также умения выполнять эту работу. очень хороший ресурс , чтобы узнать, как работать с устаревшим кодом, Книга Майкла Фезера: Эффективная работа с устаревшим кодом .
Короче говоря,Существуют безопасные рефакторинги, которые вы можете сделать, не рискуя сломать вещи, которые могут помочь вам начать работу.Есть и другие рефакторинги, которые требуют тестов для защиты работы. Тесты необходимы при рефакторинге кода .Это, конечно, не дает 100% гарантии того, что все не сломается, потому что может быть так много скрытых «функций» и сложности, о которых вы не сможете знать при запуске.В зависимости от базы кода объем работы, которую вам нужно выполнить, сильно варьируется, но для больших баз кода обычно много работы.
Вам нужно понять, что делает код либо просто зная это, либо узнав, что делает текущий код.В любом случае вы начинаете с написания "больших" тестов , которые на самом деле не являются модульными, они просто защищают текущий код.Они могут охватывать более крупные части, больше похожи на интеграционные / функциональные тесты.Это ваши охранники , когда вы начинаете рефакторинг кода.Если у вас есть такие тесты, и вы чувствуете себя комфортно в том, что делает код, вы можете начать рефакторинг частей, которые покрывают "большие" тесты .Для деталей меньшего размера, которые вы меняете, вы пишете соответствующие модульные тесты .Итерация выполнения различных рефакторингов в какой-то момент сделает начальные большие тесты ненужными, потому что теперь у вас есть намного лучшая кодовая база и модульные тесты (или вы просто оставляете их как функциональные тесты)..
Я понимаю, что вы имеете в виду под своим вопросом, но я все же хотел бы немного изменить его, потому что есть более важные аспекты, чем внешний и внутренний.Я считаю, что лучший вопрос - спросить , какие зависимости мне нужно разбить, чтобы получить лучший дизайн и написать модульные тесты?
Ответ на этот вопрос: перерыввсе зависимости, которые вы не контролируете, медленные, недетерминированные или слишком много выводит для одного модульного теста.Это наверняка все внешние (файловая система, принтер, сеть и т. Д.).Также обратите внимание, что многопоточность не подходит для модульных тестов, потому что это не является детерминированным.Для внутренних зависимостей я предполагаю, что вы имеете в виду классы с членами или функциями, вызывающими другие функции.Ответ на это может быть.Вам нужно решить, контролируете ли вы и хороший ли дизайн.Вероятно, в вашем случае вы не контролируете ситуацию, и код не очень хорош, поэтому здесь вам нужно реорганизовать вещи, чтобы все стало под контролем и улучшить дизайн.Книга Майкла Фезера здесь великолепна, но вам нужно найти, как применить эти вещи к вашей кодовой базе couse.
One Очень хорошая техника для разрушения зависимостей - внедрение зависимостей .Короче говоря, он меняет дизайн так, что вы передаете члены, которые использует класс, вместо того, чтобы позволить самому классу создавать их экземпляры.Для них у вас есть интерфейс (абстрактный базовый класс) для этих зависимостей, которые вы передаете, так что вы можете легко изменить то, что вы передаете. Например, используя это, вы можете иметь различные реализации членов для класса в производстве и при выполнении модульного теста,Это отличная техника, которая при правильном использовании также приводит к хорошему дизайну.
Удачи и не торопитесь!;)