那我们的代码管理和软件配置管理应该怎样做呢? 我们先看一个例子。下图是某个团队的代码组织结构,这样的代码组织结构会有什么问题呢?
问题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),我们将立即处理
21天更文挑战,赢取价值500元大礼,还有机会成为签约作者!
原文地址:http://www.51testing.com/?action-viewnews-itemid-7789416
免责声明:本文来源于互联网,版权归合法拥有者所有,如有侵权请公众号联系管理员
* 本站提供的一些文章、资料是供学习研究之用,如用于商业用途,请购买正版。