软件交付是以代码为中心的交付过程，其中代码的作用有几点：第一，最终的制品要交付成什么样，需要通过代码描述清楚；第二，代码定义了系统和软件是怎样工作的；第三，代码定义了系统的运行环境是怎样的。所有这些都是围绕代码。
我们先看一个例子。下图是某个团队的代码组织结构，这样的代码组织结构会有什么问题呢？
问题1：代码组的命名方式混乱
我们发现在最上层的目录中叫risk-managenment，这是一个系统，这个系统是风险管理。但是子目录写的是叫“qinglong”，那“qinglong”是应用还是团队，我不知道。然后下面还有一个玄武，下面还有一个aTeam，中英文混杂，这样的命名方式是很混乱的。
问题2：用代码块存储外部二进制文件
在android-sdks里面会存放很多sdk文件，这些文件是很大的，这个代码库存储很多外部二进制文件，我们知道在代码库直接存这样的大文件，对整个代码库的资源消耗是非常大的。
问题3：同一归属的代码保存在不同的代码组
在aTeam目录下有一个data-model，但是其他相关的文件都在玄武下，就是data-console、data-task、data-ui，我们不知道它具体是什么，但是我们知道这几个大概率是同一个应用或者是同一个产品，所以它在两个不同的层级也是不合理的。
问题4：公共库保存在子代码组里
再下一个是common-lib，通过名字来理解就是公共库，但是这个公共感觉只给玄武这个子代码组使用。
问题5：应用的文档（或测试）与应用分开存放
最后还有一个docs目录下有risk-docs和data-docs，一个是针对风险控制的系统，一个是针对数据地系统。那这个里面文档也是一个代码库，文档代码库和测试代码库，它和应用是分开存放的，这也是不合理的。
好的代码库组织形式是怎样的？
问题：假设所有的代码都保存在一个代码库，且所有人均可访问，代码库应该怎么组织？
我们认为代码库是可以分组的，代码组（+子代码组）+代码库=大库。
基于这个逻辑，我们再看看刚才那个例子里合理的代码组的结构应该是怎样的。
如上图所示，整个代码库是一个系统，这个系统有两个应用，一个是risk，一个是data。每个应用下面是有很多的服务和文档。它们有一个公共的Model，叫common-lib，这是被所有的应用所依赖的。所以我们把属于同一个应用的Git仓库放在一起，让common放到该有的地方去。不是按照团队，而是按照应用组划分，这样划分，结构就更加清晰了。这里我们稍微总结了一些实践的建议。
·代码库的内容：
-软件的源代码（ProductionCode）；
-将文档（和测试）的git库放到其相关应用组下；
-不要将制品（如系统二进制包）保存在代码库中，如果确实需要，以LFS或类似方式存放；
· 代码库的组织结构：
-按照系统、应用和模块的层次来组织代码库；
-同一个系统/应用层级的所有内容位于同一个代码组下；
· 代码库的可见性：
-通用代码库放在其通用级别都可以访问的位置；
-除核心算法等少数代码库外，建议对代码库的访问在同一系统/应用下对所有相关人员公开；
代码组织完了以后，开发者就可以围绕代码库来进行协作。整个代码库的协作过程就是：一切皆Commit。无论是rebase还是merge，都是Commit。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
