Одна простая, но монолитная кодовая база против многих четко задокументированных зависимостей - PullRequest
1 голос
/ 01 февраля 2009

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

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

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

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

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

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

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

Ответы [ 2 ]

2 голосов
/ 01 февраля 2009

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

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

0 голосов
/ 28 сентября 2015

Вот доклад Google, объясняющий (немного), как они обрабатывают свой гигантский монолитный репозиторий кода . И почему они есть.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...