一 早期语言写程序的特点：
特点：
1. 所有子程序共用全局数据。
2. 共用数据带来大量交叉耦合。
3. 大量的标志位或者数据定义很难读懂它到底代表什么意思。
1.几乎很少使用参数传递，所有子程序几乎全部依靠共有全局变量来传递数据。
2.共享全局变量带来的交叉耦合让这个代码调试起来非常费劲，因为每个函数都不是独立的，它依赖自身使用的大量全局变量。在MCU上，因为中断函数带来的并发性，如果有全局变量在中断内外都用到，那就会带来很多麻烦。这样的代码如果在多任务环境中将会更糟糕。
3.再看看可读性，大量全局变量和全局标志位让代码的可读性非常差：首先是如此之多的变量和标志位所要表达的意图，再者他们分散得到处都是，即使不考虑并发性也让阅读的人摸不到头脑。
4.看看扩展性和可维护性，如果有bug被测出，你定位问题将是极其困难的，因为这里的子程序没有内聚性，功能不独立，再加上可读性差，情况非常糟糕。如果要添加新功能，也是一件极其麻烦的事情，牵一发而动全身，要改的地方太多了。这样的编程方式也无法将项目做大。
你有这样的经历吗？刚开始做单片机的差不多都是这样的思维吧，除非之前有过其它领域的C开发经验。
我的编程思路也是这么一步步升级过来的。从最初的全局变量满天飞，到后来的的功能划分，参数传递，再到后来的文件划分，接口驱动和应用部分分离。其中的一步步变化，都有着自己的所感所悟。不可否认，这种变化，也是伴随着器件的升级，也算是一种与时俱进吧。
你不可能在89c51的片子上用那么多的参数传递，毕竟ｒａｍ有限，参数传递会降低效率，浪费空间，直接用全局变量，省时省力。后来在ａｖｒ上，上Ｋ的ＲＡＭ空间，有了奢侈的感觉。再后来的ＡＲＭ，ｒａｍ已经不再是瓶颈了。随着ＭＣＵ工作频率的提升，程序规模的扩大，我们的关注点从如何节省一个字节的ｒａｍ，转移到了如何保证程序的可读性，易扩展性上了。
二 第二代
对了。子程序不再那么单一，它有了嵌套的结构。看看这个时期引入了什么特点：
1.子函数调用支持嵌套。
2.支持各种参数传递。
3.程序拥有更丰富的控制结构。
4.声明的可见性范围多样化。如全局变量和函数内部的局部变量。
这个时候开始出现结构化程序设计。
如果从菜单的实现角度讲，这是一个很差劲的设计。主要是没有对显示内容本身做进一步的抽象，没有类似按钮，文本框，复选框等，窗口只有几行文字，被选中的行反显。因为没有真正意义上的“窗体”的概念，所以也没有真正意义上同窗口绑定的“事件”的概念，三个按键：上翻键，下翻键用来移动光标，确认键用来进入该项关联的窗口，关联关系被上面头文件里面的全局数组和全局结构体数组定义。
菜单本身如果改进的话，可以通过上面提到的做进一步抽象的方法。从窗口和窗口的组成元素（文本框，按钮，复选框等等）的独立实现上努力，再加上事件。
单单从程序设计的角度看：
1. 结构上，最主要的逻辑关系还是通过全局变量之间的组织关系来实现的。
2. 可读性很差，窗口内容很不直观，因为反映窗口（或窗口组成部分）属性的内容分散在各个
数组里面。
3. 可扩展性差，添加或者修改一个窗口（或窗口组成部分）需要更改很多地方。
4. 没有一个统一的事件处理机制，按键的处理结果也是通过上面数组的关系反映的
我应该收回对第二个阶段的比喻：远古时代。我的2007应该算是青铜时代了：虽然水平很菜，但是热情而有想法。而我的2008好比中世纪，因为郑州有些公司实在太无所事事，除了画几个PCB或者做一些散碎的不知所谓的小项目，剩下的就是像中世纪的巫师那样做一些不登台面的事情：私下学点linux环境下工具的使用和简单开发。漫长的一年毫无事事，没有什么明显收获。linux的接触犹如地理大发现，我对新大陆充满了渴望。整个2009年犹如我的大航海时代。这一年我接手了一个linux的应用项目，是电网监测系统的一部分；这一年我跑遍了全国很多地方的“国家电网”：河南的，山东的，湖北的...知名电力电网公司，比如：四方、南瑞等。我拿我们的电力电网监测从设备系统和他们的主设备对接，既维护原有系统，又增加新的功能，对于接触Linux应用开发不久的我来说，这是一个很好的机会。之前的系统是时工做的，程序写得很有技巧，对于当时的我来说难度也是颇大的。对此时工常常给予我指导和帮助，我至今都十分感激。
所以接下来我会分析一下这部分代码，当然开始之前我会插入一点小知识，就是前面提到过的对于问题的面向过程的分解（算法分解），因为这部分最典型的特定就是算法分解。
扫一扫
6034
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
