客户端程序架构反思

       12年参加工作以来，一直从事客户端程序的开发，因为参与的都是单独模块，架构的问题基本不用考虑。但是经过16、17年的磨练，随着遇到的问题越来越多，发现了一个好的架构的必要性。

      本人从事无人机产测软件的研发，也就是 在无人机量产阶段，需要提供一些客户端软件给工厂的工人使用，用来排查组装过程中遇到的问题。最开始的时候是在一款开源地面站的基础上更改，但是慢慢的发现不太适用，因为开源地面站提供的功能太过复杂，操作也不适用于工人，所以将核心功能进行摘取，开发成一个个单独的小工具。

      随着项目越来越多，工具越来越多，工作变成不断的粘贴复制，因为大部分工具的核心部分是一样，包括协议解析，无外乎串口或者tcp。而每个项目只是测试点的增加和判断逻辑的改变。因此好多的代码都是重复的，并且维护的时候也变得困难。前些天看了一本C++的书，对面向对象又有了新的认识，对抽象、接口编程这些早些年就知道的概念有了新的领悟。于是乎将自己的所有程序进行重构，搞出了一套适合自己工作的开发架构。

    分层的思想 已经提出来不知道多少年了，但是以前认识不深。现在按照这个思想来组织代码，对后期的维护颇有好处，如下图所示：

（1），ui层 ，负责界面布局，参数配置，日志记载，控件调用

（2），数据层，只要是接口的封装。包括 串口、tcp和各种功能模块的接口，比如相机、链路、后台服务器等。都是最原始的数据收发。

（3），业务层，也是最关键的一层，负责连接数据层和ui层。从数据层获得原始数据后，根据具体的业务逻辑，进行处理，提供public函数，供ui层使用。此处 ui层 仅与业务层 交互，业务层仅与数据层交互。

 

按照上述划分之后，发现如下好处：

（1），因为 PVWidget ，PVGauge 为单独的库。新的程序 只负责维护 widget主窗口。这样如果想添加新的功能 或者修改原有通用功能，仅针对两个具体的库修改即可。

（2），数据层 接口采用抽象基类 进行封装，业务层 无需解除具体数据封装，只调用 抽象接口即可。

（3），每次新开发程序，不用拷贝代码，只负责核心的逻辑判断即可， 复用的部分已经被封装。

 

          好的架构一定是和具体的业务相结合的。经过了 合-》分-》合 两年的探索，现在初见眉毛。希望在后期的项目里对此架构进行再度的优化。