前言
单源码库单应用是我们公司一直在执行的标准，这个标准也是由于我的坚持才一直实行到现在。因为这个标准和开发的小伙伴儿们相爱相杀过好多次，下面我关于这个标准做的总结。
开发角度
首先，很多开发都认为单源码库多应用的话，会提升开发速度，两个应用有很多共同的地方，放在一个源码库下开发也方便，这两个应用共享的代码并不会被别的应用用到。
但是，我觉得两个应用之所以划分成两个应用就是要独立开发，独立部署，独立运行。两个应用如果代码都耦合在一起的话，是应用划分的不合理，无论是应用间还是应用内的模块间都应该是高内聚低耦合的，两个应用的公用部分就应该放到制品库（neuxs 或者 artifactory）做成公共的组件。如果两个应用代码耦合很严重的话，就应该合并成一个应用。
有个流传很广的一句话是对一个程序员最大的惩罚就是让他维护他三个月前写的代码，这也从侧面反映出开发不太关心非功能性需求。
运维角度
从运维的角度讲，任何一个运维对象的添加都应该慎重。因为每添加一个运维对象就会增加运维系统的复杂度，如果我们不能很好的控制复杂度，那我们运维工作肯定没法做。
就以 java 应用为例，假设应用名为app1。
- 单源码库单应用，源码库地址就是 gitlab 地址+组名+app1，pom 文件在源码库的根目录，生成的 jar 包在，target/app1.jar。
- 单源码库多应用，就需要知道每个应用的 pom 文件位置和生成二进制文件的位置，还有就是我们按照 tag 发版的话，那么两个应用的话我还需要刷选一下。
总的来说单源码库多应用给运维系统带来的复杂度是非常巨大的。
架构角度
一个架构需要考虑开发，测试，部署，可扩张性，性能，整体的敏捷（可以理解为响应变化的能力）等一共六个方面，在单源码库多应用这个问题上我们主要考虑开发，测试，部署和整体的敏捷四个方面（两个应用代码都耦合在一起的话，耦合度是很高的，所以下面以耦合度来说）：
- 从开发的角度讲是 OK 的，能带来很大的便利
- 从测试的角度，耦合度高的应用可测试性通常不高
- 从部署的角度，给部署工作添加了复杂度
- 从整体的敏捷的角度，耦合度降低了软件响应变化的能力
总的来说，我们考虑这个问题要尽量考虑全面。
开发为什么这么在乎开发速度
首先我觉得是大环境导致的，引用深入核心的敏捷开发――ThoughtWorks五大关键实践中的一段话：
需求没有妥协的空间，设计没有妥协的空间，导致团队的痛点永远是按时交付，质量一定会被牺牲掉的。
总的来说这个不是技术层次能够解决的问题，需要引用敏捷的一些方法论和流程，比如 WIP 等，具体可以看看这本书里面的敏捷转型三步走的那章。
如果一定要实施单源码库多应用怎么办
有的开发也和我说过他们单源码库多应用有多么合理，我说的是可以让他们定义一个规则，比如一个源码库有多少个应用，应用在源码库根路径第几级目录等等，总之就是不可能他们说他们应用想怎么运行就怎么运行，一定要有规范，复杂度一定要可控，我让他们想好了这个我们再谈单源码库多应用的事情。
更新于20201208
在 Bob 大叔的《架构整洁之道》第 12 章组件的开头有说到：
无论采用哪种部署形式，设计良好的组件都应该永远保持可被独立部署的特性，这同时也意味着这些组件应该可以被独立开发。
