关于通用程序架构的想法
工作有些年头,自己写程序或者维护别人的程序也不少,但始终觉得风格变化太多,有没有一种普遍点的架构方式,比如1.小资源的单片机,用一个状态机方式,在做的时候就往里面加模块就是;2.M3之类的,明白一个实时系统,根据自己行业选用,以后基本添加任务就行;3.嵌入式linux系统,编程架构也可以用单片机差不多的状态机方式实现应用。有哪些人总结出来了自己觉得好用的方式,一起聊聊,思路正在整理中... 有时候自己觉得好,别人不一定觉得好 没接触过Linux,状态机、OS都用过,小资源单片机就只用状态机,M3就OS+状态机。要降低开发成本,不做软件工程不行了,架构这概念太大了,我水平不够。我认为好的方式是封装与模块化,面向对象。 zhenghe 发表于 2014-11-30 17:34没接触过Linux,状态机、OS都用过,小资源单片机就只用状态机,M3就OS+状态机。要降低开发成本,不做软件工 ...
架构这词语确实有点大,应该说是根据自己工作所在方面做一个总结,把一些通用的抽象一下,在整体上能看见思路。有这些想法主要原因是,在维护别人产品时候,许多程序基本不好做扩展,许多东西都混在一起了,重新做,老板不给时间和再犯错的机会,而且不像大公司的开发文档会给流程文档什么的,许多的程序都是只考虑了当下,后面移植扩展都没法复用。 czg1411 发表于 2014-11-30 17:21
有时候自己觉得好,别人不一定觉得好
主要是能让所有看见程序的人能看见思路 ysyt_3 发表于 2014-11-30 17:46
架构这词语确实有点大,应该说是根据自己工作所在方面做一个总结,把一些通用的抽象一下,在整体上能看见 ...
说起来比做起来容易。我当年也打算把三个算法整合到一个程序里面,使用条件编译控制,结果最后维护起来非常困难。所以,你只能要求代码思路要留个文档出来,比如某个方法的实现流程。 好吧,拿例子说吧。我说的面向对象是一种思维,不是说要用c++、Java什么的。比如拿最简单的UART说,封装成一个模块需要两个文件:UART.c和UART.h,注意UART.c不能包含UART.h,UART.h是给外部用的,只有UART透给外部的数据类型、接口函数声明才能放到UART.h中。UART要提供的接口函数有三个:Init(),Write(),Read()(要是SPI,应该还有Exchange(),别的模块可能还有别的接口,具体有哪些接口,看你的抽象能力了,抽象好了以后就不变了,比如换了了一个芯片,其UART的接口必须也是Init(),Write(),Read(),参数和返回值都不能变,所以做模块的第一个人责任很大),以后做上层应用就只用Init(),Write(),Read()这三个接口,即使底层硬件换了,应用程序也不用改。如果别人做的模块,其接口与你需要的不符,并且改不了(比如是前任做的,现在人不在了),那么就需要你包装成需要的接口,所以接口的复杂程度也是需要火候的:透给外部的信息越多,就越灵活,功能就越强,当然也越难用。<时间长了就有架构能力了> 建议对此话题感兴趣的看傻孩子的帖子 wye11083 发表于 2014-11-30 17:51
说起来比做起来容易。我当年也打算把三个算法整合到一个程序里面,使用条件编译控制,结果最后维护起来非 ...
你说的3个算法条件编译什么的,我觉得看的freemodbus里面那种方式比较不错,好像是把一个算法写成函数,在用什么算法时候,把函数指针赋值给在框架结构里面的那个函数指针,框架里面的那个函数名字确定,调用的时候就调用那个指针。我想的是,怎么才能更好的搭建框架。以后直接把那函数从新换一个,然后把函数指针赋值给框架里面的指针,而且还得考虑下,在框架里面增加别的东西,所以有点麻烦,不知道有啥好的解决方法没。 zhenghe 发表于 2014-11-30 18:23
建议对此话题感兴趣的看傻孩子的帖子
确实是看了不少傻孩子的,不过对上位机式的编程有点不习惯,所以想有别的方法没。而且主要是想对自己工作方面的程序的一个提炼,不用通用的,比如,有的程序要求通信优先级高,有的侧重显示或者采集,当各位在对自己工作程序的提炼的时候,是怎么保持其以后的扩展的复用的 zhenghe 发表于 2014-11-30 18:15
好吧,拿例子说吧。我说的面向对象是一种思维,不是说要用c++、Java什么的。比如拿最简单的UART说,封装成 ...
想想stm32M3的库,也就是这样的呀,而且是经过这么多年才有现在3.5比较成熟的版本,,但是封装的完整度和可定制化是矛盾的,比如一个io有上拉下拉,开漏等等,这都要程序员来配置的 ysyt_3 发表于 2014-11-30 18:49
你说的3个算法条件编译什么的,我觉得看的freemodbus里面那种方式比较不错,好像是把一个算法写成函数, ...
你的意思我懂,Linux设备驱动部分全是这样做的,很多开源程序也全都这样做的,因为它们每个函数干活的方法是不一样的。比如CPU支持SSE,则对不支持SSE的用一个函数,支持SSE的用另一个函数。我的这个算法,是设计为兼容同一种算法的,具体就是三种博弈算法使用同一个引擎,但是三种算法总是有一些差异,因此引擎不得不使用大量条件编译。
也即,你想兼容所有的东西,那你就得去兼容所有东西。这显然,代价太大。 wye11083 发表于 2014-11-30 19:54
你的意思我懂,Linux设备驱动部分全是这样做的,很多开源程序也全都这样做的,因为它们每个函数干活的方 ...
确实是那样的,有些时候代价比较大,更让人难理解。 熵之矢 发表于 2014-11-30 19:52
想想stm32M3的库,也就是这样的呀,而且是经过这么多年才有现在3.5比较成熟的版本,,但是封装的完整度和 ...
他们那库是为了照顾全局,我想的是就对自己工作的产品的一个提炼,不用全 ysyt_3 发表于 2014-11-30 20:00
他们那库是为了照顾全局,我想的是就对自己工作的产品的一个提炼,不用全 ...
对自己工作的提炼就是程序员的价值所在,别人提供接口,好比积木,我们再搭起来。。。 zhenghe 发表于 2014-11-30 18:15
好吧,拿例子说吧。我说的面向对象是一种思维,不是说要用c++、Java什么的。比如拿最简单的UART说,封装成 ...
我一直就这么做的呀,自己一个人开发,然后自己维护,所有单片机……这个不是官网例子程序都这样的么?{:3_49:} zhenghe 发表于 2014-11-30 18:15
好吧,拿例子说吧。我说的面向对象是一种思维,不是说要用c++、Java什么的。比如拿最简单的UART说,封装成 ...
羡慕,应该有自己的一套开发结构了 通用架构的思路,驱动层,应用层分开,便于程序移植。驱动层最好有抽象接口,便于应用层调用。 lushanlq 发表于 2014-12-1 13:07
通用架构的思路,驱动层,应用层分开,便于程序移植。驱动层最好有抽象接口,便于应用层调用。 ...
忽然发觉,说来说去,好像最后还是走上操作系统的思路,只是具体话于一个应用。 ysyt_3 发表于 2014-12-1 20:04
忽然发觉,说来说去,好像最后还是走上操作系统的思路,只是具体话于一个应用。 ...
因为你想过的,前人也想过了,所以有了操作系统,哈哈,人的思维何其相似啊
页:
[1]