公共CBB实现方案思考

需求:

对各产品提供一个公共的CBB:该CBB主要屏蔽多个硬件平台的区别,不同的硬件平台的实现机制不尽相同(不同的硬件芯片,驱动等等),但对外提供的功能是一致的

两套实现方案:

1. 每个平台单独实现自己的二进制,在二进制外面做一个封装层来统一供上层调用

示意图如下:
公共CBB实现方案思考_第1张图片

优点 缺点
简单,每个平台单独实现自己的分支;甚至API规范都不用考虑 后续如果需要增加统一的调试逻辑,需要在两个二进制中重复实现
- 两个平台的实现完全独立,后续的维护成本上升

初看起来本方案实现比较简单,且个平台的二进制实现完全独立无耦合,似乎是比较好的方案。但如果考虑后期的维护成本,由于各平台单独实现,编程风格和实现方式不尽相同,新人加入后的理解成本也会随之而来;另外,后续增加新平台时,还需要再独立完整实现一套,之前的工作成果无法复制使用。
综上考虑,该方案并非优选。

2. 统一实现一套CBB代码,命令的解析以及框架共用一套,在具体功能处调用不同平台的接口

示意图如下:

公共CBB实现方案思考_第2张图片

优点 缺点
各平台的接口规范统一要求,标准化 两个平台融合编译时,需要解决头文件冲突问题
在框架中统一添加日志和调试手段 工作量
维护过程中,只用关注细粒度的实现,不用熟悉两套框架 -

这个方案中可以说是方案1的细粒度实现,整个CBB只用实现一套框架和命令行UI,针对不同平台提出统一规范的API接口。在框架中识别平台后,调用具体平台的接口函数。该方式虽然前期会有开发工作量以及一定的耦合性,但维护成本会大大降低,增加新平台时,也只用根据之前的接口规范重新实现一套插入到当前的框架中即可,可以直接实现代码复用。

总结

以上是在实际工作中的一小项目方案考虑中提炼出来的,相信没有最优只有更优,先记录下当前的思考结果,后续继续优化,也欢迎大家提出意见。

你可能感兴趣的:(感悟,架构,硬件,需求)