При работе с языками, в которых отсутствуют встроенная структура и организационные функции (например, если у него нет пространств имен, пакетов, сборок и т. Д.) Или если их недостаточно для контроля кодовой базы такого размера, естественным ответом является разработка наши собственные стратегии для организации кода.
Эта стратегия организации, вероятно, включает в себя стандарты, касающиеся того, где должны храниться разные файлы, что должно произойти до / после определенных типов операций, а также соглашения об именах и другие стандарты кодирования, а также многое из того, «как это настроено» - не связывайтесь с этим! " введите комментарии - которые действительны, если они объясняют почему!
Поскольку стратегия, скорее всего, в конечном итоге будет адаптирована к конкретным потребностям проекта (людям, технологиям, среде и т. Д.), Трудно предложить универсальное решение для управления большими базами кода.
Поэтому я считаю, что лучший совет - принять стратегию, специфичную для проекта, и сделать ее управление ключевым приоритетом: документировать структуру, почему это так, процессы внесения изменений, проверять ее, чтобы убедиться, что она соблюдается, и главное: измените это, когда это должно измениться.
Мы в основном знакомы с рефакторингом классов и методов, но с большой базой кода на таком языке именно организационная стратегия (в комплекте с документацией) должна быть реорганизована по мере необходимости.
Мотивация та же, что и при рефакторинге: вы создадите умственный блок для работы с небольшими частями системы, если почувствуете, что общая организация системы беспорядочная, и в конечном итоге допустите ее ухудшение (по крайней мере, это мое мнение) Это).
Предостережения также одинаковы: используйте регрессионное тестирование, убедитесь, что вы можете легко вернуться, если рефакторинг идет не так, и спроектируйте его так, чтобы в первую очередь упростить рефакторинг (или вы просто не будете этого делать!).
Я согласен, что это намного сложнее, чем рефакторинг прямого кода, и это сложнее проверить / скрыть время от менеджеров / клиентов, которые могут не понимать, почему это нужно делать, но это также типы проектов, наиболее подверженных программному гниению вызвано негибкими конструкциями верхнего уровня ...
