Одна простая, но монолитная кодовая база и многие явно задокументированные зависимости

Question

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

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

Каковы преимущества и недостатки этих разных подходов и как вы работаете так или иначе?

Преимущества монолитной кодовую:

• Простота развертывания
• Легко откатить
• Легко расшириться/управлять всеми изменениями вместе
• Нет (или меньше) потенциально сложных зависимостей в документе и управление

Преимущества модульных зависимостей:

• Повторное использование
• Чистая архитектура (один модуль делает одну вещь хорошо)

Answer 1

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

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

Answer 2

Пожалуйста, свяжитесь с Google explaining (a little bit) how they handle their gigantic monolithic code repository. И почему у них это есть.

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