2
回答
哈,水下c开发系统和命名的个人观点
极速云服务器,低至1.04元/天>>>   

刚看个帖子的回复,说c语言的全局可见命名比较蛋疼。开发的系统大了,确实存在这个问题,哈。客观事实。不过这是说延续某种单一应用系统的开发。正好今晚休息一下,就水一下,c语言开发系统和命名的个人观点。哈。

c语言,挺简单的,在函数外不加 static ,就是全局作用域(默认的),加了,就是本文件的作用域,在函数内,自然作用域更小。这个已经体现了命名范围的差异,而不是没有局部范围。因此,一个简单的设计思路是,全部加 static,只有对外的接口(确实需要对外调用以保证本c文件还存在开发设计价值的函数)才不加。

上面的方法,基本能解决,不同区域代码内,相似含义的对象(函数,数据)名称重复的问题。哈。

但是,问题来了,小模块被整合到大模块里,大模块又被整合到子系统里,子系统又拼成一个目标设计系统,且不谈版本调整,原本应该封装在小模块里的东西,可能因为不同大模块中都包含相似的小模块,而导致名称重复。 这种问题客观存在,和水平高低没啥关系,和设计目标有关系。哈。

如果在带有“版本”概念,就更蛋疼了。说个简单的例子,存在,a,b,c,d四个c文件。b调用a, c 调用a, d 调用 a,b,c。这里的调用是说,b里面有个函数,调用了a文件中的某个函数。 如果这样,或许还有层级关系,模块关系。 a作为一个子模块,而被其他b,c,d利用。但如果一个系统设计,一开始只有 , a,b,d ,经过很长时间的开发,冒出来的c文件,此时c文件的设计,忘了a文件中的某个函数,于是在 c文件中自身设计了该函数,恰巧d中某个新增函数(因为新跑出来个c文件所对应的设计任务嘛)调用c时,也利用了该函数,如果命名规则清晰的团队,就极有可能出现a,c两个文件中命名冲突的问题。通常还不好解决。即便功能完全一样,但是不同历史的设计,在细节上可能有些差异,而a文件中的老函数又被很多模块调用,去修正它容易导致新增bug(只有菜鸟工程师才去动那些稳定的库,哈),而a文件的老函数又不能完全替代 c文件中的新增函数。

你说咋办?哈,就我能想到的,只有整合,把 c文件里的新增函数和a文件里的对应函数,重新合并到一个文件中,这等于重构。至于是否需要重构,不同团队有不同团队的观点,我个人的观点是“重构”永远存在,只要业务还没有枯萎。哈。如同对待美女,不是一次请客吃饭。吃了再吃才能更好的增加感情嘛。哈。

“重构”和重复做轮子不是一回事。而是反复把轮子质量做的更好。

而另一方面,系统要尽可能的在局部设计中紧耦合,而在系统协同设计中松耦合。松耦合确实有麻烦,但只要数据交换做的好(不是简单的接口的问题),系统运行效率并不低,且有利于系统规模的弹性调整(系统功能不变下,系统处理工作的“吞吐量”提升)。这是通过进程协同的方式来构建系统的方法。而这个系统构建的方法和你所用东西都是一个main函数调用的方法并不相同。而且这个和是否是c语言这种“模块化设计语言”,还是java这种面向对象设计语言没有关系(c++拒绝评论,这个语言权当我不懂,是一种至少让我会精神错乱的语言,你c++有种就别去源码级别的利用c代码,安心做面向对象,哈)。

这里,扩展水一下系统松耦合设计的个人观点。哈。

我们在写程序(先不说是系统吧,比如万恶的教学例子,写个printf("hello world!!\n"): )时,会按照单线程的思维来考虑。整个程序一个时间节点只做一件事情。这样会导致我们的思维聚焦在怎么实现某个功能,反正完成a才会去做b。而没从数据流动性的角度来考虑设计目标-系统。

如果换个思路来思考-从数据流动性的角度,那么应该是“数据从哪来,数据会给谁,数据需要什么样的加工”,由此确定系统的整体服务状态(其实很多服务端系统也是这么设计的,不知道设计前是不是这么思考的,哈)。根据服务状态- 系统有哪些模块,分别做什么,来确定不同模块的设计目标(细分,具体化后,是具体功能),此时,各个模块都是可以独立设计,并通过进程间通信,完成整体系统功能(网络通信,我个人观点,仍然是“广义”上的进程通信,哈)。随后,就是原型设计,和迭代优化。包括处理规模,数据交换速度(这直接引发了数据方面的很多问题,实效性、一致性、完整性等等)。 说到这,或许对于为大系统设计而纠结全局命名冲突的c程序员,应该可以想到,其实每个功能进程不会太大的。哈。

哈,顺带说个观点,系统没必要越大越复杂就越好。最近两年一直在stm32上玩。搞死了,都只能说是个实时调度的类系统,都不能说是个多进程,多线程系统,stm32这种级别的片子,上多线程或多进程是否真有必要,我不知道,我只是觉得,mcu的应用,强调实时,而非系统进程复杂度。

如果没啥复杂的系统设计目标,大家也不用为了多进程而多进程,把一个原本单一程序,刻意切成多个进程来折腾。哈。

最近忙我们自己系统量产前修正设计,深刻领悟到一个真理“把复杂的东西搞简单,才是水平”。谈不上我有水平,但多一个螺丝或多一个接插件,就多一个加工工序,别小看一个螺丝的加工,其实费用不高,但由此带来的物资采购,管理,就都是一堆事情。哈,工程师,坑谁都可以(都不是故意的嘛),坑自己就不应该了。所以,套用 @宏哥 的专用名词,“凡是”都要简单化的设计”哈。

 

<无标签>
举报
中山野鬼
发帖于5个月前 2回/142阅
顶部