【随文杂想】Modules 分类标准(一)

目录

问题

分类

1. 原始型

2. A-B 型

3. B-T 型

4. CBS 型

---

 

问题

整理了一下自己以前写过的边边角角，感觉在技术选型的路子上，分类标准和分类体系比较重要，稍有不慎，容易走向野路子；

 

分类

按照软件开发演进时间梯度，推测可能的几种演变方式：

1. 原始型
2. A-B 型
3. B-T 型
4. CBS 型

 

1. 原始型

毫无疑问，原始型就是所有开发过程都在一个主工程中进行，很简单，不再提供图示，分类的作用其实是简化沟通/理解等一系列的相关学习成本；

 

2. A-B 型

这个A-B 型就是我自己起名的，因为我也想不出来啥好听高端大气上档次的名字，暂且就用这个A-B型命名吧，如图所示：

注意：

如果无分歧/争议，此处我们规定APP 表达主工程的含义，Base Level，CXXX Level... nXXX Level 表达Modules 工程；

 

APP 层就是我们的主工程；

Base Level 的建立很可能此处放的就是一般的工具包，公共性质的通用代码啥啥的，有了基本的分层构建意识;

 

3. B-T 型

同上，如图所示：

写代码浪到一定程度，对基本的业务和技术有了进一步的了解，到了这一个环节，我觉得才算是正式的程序猿入门?;

Business Level 用来表达业务层的东西；

Technology Level 用来表达纯技术层的东西；

做到技术和业务解耦操作，此时有个小技巧，搞技术的要有个业务是公司的，技术是自己的认知哦；

 

4. CBS 型

一样，同上，如图所示：

Middle Level 其实就是一个中间件，可分为多个亚层，表征一个或多个依赖项；

Compat Level 多版兼容软件包，参考Android API 方式，自己衍生出来的一个概念，因为Android 系统版本太多，有一些兼容性控件需要在不同系统版本下做到最大化兼容;

Support Level 分版支持包，参考Android API 方式,个人认为是一个比较好的分版本支持软件功能的分类方式；

Base Level 此处表达一些公共性质的技术沉淀，或多层次拆分，举例Base + Common + Abstract 亚层结构；

啧啧啧，解释一下为啥单独把这个拎出来成为一个分类类型，因为兼容性和支持库作为软件生态中软件敏捷开发过程中一个普遍应该考虑的问题，既不影响既有系统，又能在不同系统版本下做到不同粒度上的兼容与支持;

 

现在就先写到这吧，后续有时间再补充后续整理的，又该拉去开会了，哎;