客户端程序架构反思
12年参加工作以来,一直从事客户端程序的开发,因为参与的都是单独模块,架构的问题基本不用考虑。但是经过16、17年的磨练,随着遇到的问题越来越多,发现了一个好的架构的必要性。本人从事无人机产测软件的研发,也就是 在无人机量产阶段,需要提供一些客户端软件给工厂的工人使用,用来排查组装过程中遇到的问题。最开始的时候是在一款开源地面站的基础上更改,但是慢慢的发现不太适用,因...
12年参加工作以来,一直从事客户端程序的开发,因为参与的都是单独模块,架构的问题基本不用考虑。但是经过16、17年的磨练,随着遇到的问题越来越多,发现了一个好的架构的必要性。
本人从事无人机产测软件的研发,也就是 在无人机量产阶段,需要提供一些客户端软件给工厂的工人使用,用来排查组装过程中遇到的问题。最开始的时候是在一款开源地面站的基础上更改,但是慢慢的发现不太适用,因为开源地面站提供的功能太过复杂,操作也不适用于工人,所以将核心功能进行摘取,开发成一个个单独的小工具。
随着项目越来越多,工具越来越多,工作变成不断的粘贴复制,因为大部分工具的核心部分是一样,包括协议解析,无外乎串口或者tcp。而每个项目只是测试点的增加和判断逻辑的改变。因此好多的代码都是重复的,并且维护的时候也变得困难。前些天看了一本C++的书,对面向对象又有了新的认识,对抽象、接口编程这些早些年就知道的概念有了新的领悟。于是乎将自己的所有程序进行重构,搞出了一套适合自己工作的开发架构。
分层的思想 已经提出来不知道多少年了,但是以前认识不深。现在按照这个思想来组织代码,对后期的维护颇有好处,如下图所示:
(1),ui层 ,负责界面布局,参数配置,日志记载,控件调用
(2),数据层,只要是接口的封装。包括 串口、tcp和各种功能模块的接口,比如相机、链路、后台服务器等。都是最原始的数据收发。
(3),业务层,也是最关键的一层,负责连接数据层和ui层。从数据层获得原始数据后,根据具体的业务逻辑,进行处理,提供public函数,供ui层使用。此处 ui层 仅与业务层 交互,业务层仅与数据层交互。
按照上述划分之后,发现如下好处:
(1),因为 PVWidget ,PVGauge 为单独的库。新的程序 只负责维护 widget主窗口。这样如果想添加新的功能 或者修改原有通用功能,仅针对两个具体的库修改即可。
(2),数据层 接口采用抽象基类 进行封装,业务层 无需解除具体数据封装,只调用 抽象接口即可。
(3),每次新开发程序,不用拷贝代码,只负责核心的逻辑判断即可, 复用的部分已经被封装。
好的架构一定是和具体的业务相结合的。经过了 合-》分-》合 两年的探索,现在初见眉毛。希望在后期的项目里对此架构进行再度的优化。
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)