嵌入式技术
嵌入式项目中,软件是一个不断迭代的过程,需要考虑各种兼容性。之前我们的项目,因为这方面考虑得比较少,导致项目中后期开发起来很被动。
项目系统总体设计阶段,应尽可能地考虑到未来可以遇见的情况,覆盖到尽可能多的业务扩展。项目虽然分阶段开发,各个阶段完成的功能都不一样,总体设计要指向最终的需求。
数据兼容性
1、协议制定
制定的协议要满足整个项目所有数据的交互。
比如:
这里的 ID 设置为 1 个字节,可能有一定的风险。后面功能加着加着,可能 1 个字节的 ID 满足不了,就得改协议。尽管可能满足了某个项目的需求,但万一之后其它项目也用了这一套代码,但是 1 个字节的 ID 满足不了,又得改代码。这里设置 2 字节可能会好一点,基本上能满足绝大部分情况的使用。
不一定为了覆盖范围更广而设置 4 字节,这样可能有点冗余。很多情况都有一个平衡点,需要自己权衡。
Length字段只设置了 1 个字节,可能也有一定的奉献。后面功能中如果有发较大的数据,可能要分好多包发,原本可以发得很快,被这里限制死了。到时候想要提速,就得改协议。
之前项目里,几块板间的通信都用同一套协议。但后期发现该协议满足不了新需求,但为了不影响到前面的数据,又搞了一套协议。导致项目里有两套差不多一样的协议处理代码。
协议应该是项目一开始考虑好、制定好,整个项目开发期间,都不应该再做改动。
2、数据添加
后面新增的数据,不应该插入现有的数据中,应该单独增加一个数据ID。
比如:
现有的数据中,有一条数据叫做设备信息的数据,设备信息里包含了:设备IP、设备Mac。这个数据会显示在手机APP上。对应的 C 语言代码:
#define MSG_ID_DEV_INFO 0x0001 typedef struct _dev_info { char dev_ip[IP_MAX_LEN]; char dev_mac[MAC_MAX_LEN]; }dev_info_t;
假如后面需要再显示一个设备的sn,这个数据我们应该加在哪里?
如果是项目前中期,这时候还是在开发阶段,我们可以随意修改。因为设备sn也是设备信息的一部分,可以直接在设备信息这个数据里添加会比较合理:
#define MSG_ID_DEV_INFO 0x0001 typedef struct _dev_info { char dev_ip[IP_MAX_LEN]; char dev_mac[MAC_MAX_LEN]; char dev_sn[SN_MAX_LEN]; }dev_info_t;
如果是产品已经在市场上流通,这时候这么加的话,软件兼容性就不太好。因为假如你的手机APP版本与设备版本不匹配,原有的设备IP及设备MAC这两个设备信息可能都显示不出来,因为我们这么一改,破坏了原有的数据结构,而手机APP按照原来的数据来做解析的,会解析不过。
这时候可以这么来加:
#define MSG_ID_DEV_INFO 0x0001 #define MSG_ID_DEV_SN 0x0002 typedef struct _dev_info { char dev_ip[IP_MAX_LEN]; char dev_mac[MAC_MAX_LEN]; }dev_info_t; typedef struct _dev_sn { char dev_sn[SN_MAX_LEN]; }dev_sn_t;
这样,哪怕手机APP版本与设备版本没有对应上,原来的数据还是能正常显示的。当然,最好的情况当然是在开发阶段就合理地设计好。不然,像这种情况,只能牺牲一些程序可读性来换取程序兼容性了。这会让后面看代码的人觉得很奇怪,你这个sn不也是数据设备信息吗,怎么还单独给一个ID。后面接手这个代码的人可能就会把这一块代码给改了。
温馨提示:在没有完全弄懂维护项目的代码为什么这么实现的情况下,能正常在跑的程序还是别乱动得好,哪怕你觉得这是屎山代码。否则可能会出大问题。要么等到软件重构时再修改,要么就继续打补丁。
3、数据删除
如果是删除本模块内部自己使用的数据,你想怎么删就怎么删。
如果是删除与其它模块进行交互的数据,这就不能这么随意了。比如,请求、应答的方式。应答端给请求端返回的数据是不能随意删的,如果要删,一定要确保请求端已经没有请求数据的需求,并且已经去掉相关代码时,这时候应答端才去删数据,否则还是留着吧。
4、数据修改
其实数据定了,为了保证软件兼容性,应该是要禁止修改的。
如果一定要修改,可以先增加一条新数据,后面慢慢切为新数据、删除旧数据。
接口兼容性
正在使用的接口,应该尽量不要修改。如果要修改,一定不要影响之前的功能。
之前就有遇到类似的情况。举个例子:
typedef enum _sys_status { SYS_STATUS_IDLE, SYS_STATUS_RUNNING, SYS_STATUS_STOP, }sys_status_t; static sys_status_t g_sys_status; sys_status_t get_sys_status(void) { return g_sys_status; }
这里的系统状态是要显示在手机APP上的,不同的状态显示不同的图标。后面要新增一个状态,结果数据提供者这么改:
typedef enum _sys_status { SYS_STATUS_IDLE, SYS_STATUS_NEW_STATUS, SYS_STATUS_RUNNING, SYS_STATUS_STOP, }sys_status_t; static sys_status_t g_sys_status; sys_status_t get_sys_status(void) { return g_sys_status; }
接口提供者把新增的数据插入了中间,影响了枚举原有的顺序。结果手机APP上图标显示乱了。
影响到接口的修改,要保证原有的数据不受影响。
系统兼容性
在软件升级过程中,需要考虑软件所依赖的其他系统组件是否发生变化,以确保升级后软件能够正常运行,不会影响其他系统组件的正常运行。如果其他系统组件发生变化,则需要进行相关测试和文档更新,以确保整个系统能够正常运行。
另外随着项目的迭代,这一套代码有可能运行于不同的系统不同的芯片平台。
比如,我们嵌入式Linux项目,有些项目里会用到一些第三方库,这时候可能会编译成动态库的形式。要考虑升级的时候能不能升级动态库。如果不能,就得把依赖的库一起编译到可执行程序里。
另外,如果使用动态库,之后产品软硬件迭代换了一个芯片平台的话,我们就需要重新交叉编译一次所依赖的库。如果为了保证这一块的兼容性,也可以考虑把所依赖的库与用户代码一起编译。
当然,这个根据实际情况进行权衡取舍。如果依赖的库很多,一起编译到可执行程序里,导致可执行程序很大,到时候更新也不好更新。
功能兼容性
涉及到功能的添加的,尽量不要影响到之前已开发的功能。不然也会增加用户对产品的学习成本。比如某些指示灯在前一个版本的快闪、慢闪代表什么意思,这个在之后就尽量不要去修改了,不然用户又得重新理解。
性能兼容性
在软件升级过程中,需要考虑软件的性能是否发生变化,以确保升级后软件的性能仍然能够满足用户需求。如果软件的性能发生变化,则需要进行相关测试和优化,以确保软件能够正常运行,并且能够满足用户的性能需求。
比如,原来正常升级需要3分钟,某个版本之后升级变成了6分钟,升级效率变差了。
安全兼容性
在软件升级过程中,需要考虑软件的安全性是否得到加强,以确保升级后软件的安全性能够得到保障,不会出现新的安全风险。如果软件的安全性得到加强,则需要进行相关测试和文档更新,以确保软件能够正常运行,并且能够保障用户的安全。
编辑:黄飞
全部0条评论
快来发表一下你的评论吧 !