新世纪的五四运动：程序白话文(1)

熟悉RAD开发工具的同学都知道，看“前人”“遗留”下来的程序是一种痛苦。改这些程序更是一种痛苦。而改程序的过程中，被测出来一些“史前错误”是痛苦中的痛苦。扣钱事小，一口气咽不下，被委屈的滋味不好受。因此，同学们在改程序的时候小心翼翼，全局变量绝对不能动，明明看到原来的一个函数改一下就能满足要求，但还是自己再写一个比较保险。谁知道改过的地方会不会造成定时炸弹呢？

于是乎，程序越来越复杂，越来越臃肿。开发组长有对策，每个组员专门负责某几个模块，时间长了，自己知根知底，就敢于对自己程序开刀。但人员调动，员工去留是不可避免的事情，一个人负责固定几个程序难以长久。抛开这些不谈，假设某同学在公司就是负责有限的几个模块维护，那他有何发展可言呢？

所以，归根到底，我们要使得程序容易被理解，容易被修改，容易被扩充，才是最终目的。万事开头难，先从自己做起。

首先来看一下，别人的程序，到底是什么妨碍了自己阅读和修改？

1、全局变量。
??全局变量是个讨厌的东西。 假设我们现在看到这里有一句：
??mbDisplayInPrice: Boolean; //是否显示进价
??按道理说，风格挺好的，有注释，有前缀，名字也起的好。但是这个变量它没有一个“主人”，如果说，它是单据类的属性： TReceiptInfo.DisplayInPrice，我们能够理解，如果说它是系统参数类的属性：TSysParams.DisplayInPrice，我们也好理解，但是现在它是属于整个程序的，所以我们其实并不知道它确切的作用范围。

??所以，全局变量带来的问题是它不具备确切的含义而经常被误解，它不属于某个对象而在整个程序被随处可能被修改。

2、程序代码分布在不同区域。
??假设我们现在要检查程序的修改订单这样一个功能的程序代码。按照我们通常的理解，这是一个很单一的功能，应该这样实现：
????检查用户权限
??????↓
????效验用户输入
??????↓
?将用户输入作为SQL 的输入参数
??????↓
????调用SQL
??????↓
??检查SQL 运行结果
??
??这些程序，如果比较短的话，应该是一个过程完成。如果比较长，就应该分为几个过程完成，但是由同一个函数来调用，这样都能够使我们看得清楚明白。
??但是在我们程序里面，检查用户权限是在控件里面实现的，效验用户输入可能放在Query.BeforePost里面检查，SQL 是写在窗体文件里面的（天知道哪段程序会对SQL进行过处理，比如加上采购组权限什么的），ApplyUpdate 是在Query.AfterPost 事件里面完成的，对某些字段赋初值可能在Query.AfterInsert事件，也可能在 Query.OnNewRecord事件，甚至可能在数据库触发器做。
??换句话说，我们检查这一段程序，要到各种不同的地方去看，去改，真是痛苦啊。当然，如果我们有一个叫 UpdateOrder 的函数来统一调用这些过程，那么多少能帮助理解，但是且慢，这里面牵涉到事件，事件是控件来调用的，Query1AfterPost就是Query1AfterPost，它不是叫 CommitQuery1 的私有方法，所以它里面很可能包含了其它的程序代码（除了ApplyUpdate和CommitUpdate），你改动了它，就可能埋下了定时炸弹。

3、事件陷阱??
??现在的详细设计文档里面已经基本上见不到流程图了。因为流程图无从画起。事件驱动、界面驱动的RAD方法颠覆了我们的编程方法。
??记得在写DOS程序的时候，程序流程是很简单的，因为就是一条线嘛，最多有个循环、有个条件转向语句，因此程序清晰易懂，代码优化也容易。
??然后就是讲用户交互了，也好办啊，程序跑到中间，需要用户确认的地方，就在屏幕显示提示信息，让用户按y 或者n，接着往下跑，其实也就是条件转向语句。
??到了Windows时代、RAD时代，情况就完全不同了。假设我们按照DOS程序的思路来设计修改订单的流程。
????用户按下修改订单按钮
????????↓
????提示用户输入订单号
????????↓
????弹出订单明细表，让用户选择
????????↓
??用户选中某个明细，系统显示数量和价格的修改框，用户修改
????????↓
????弹出订单明细表，让用户选择（重复）
????????↓
?????用户选择结束作业
????????↓
?????程序提交修改

??但是实际上呢，这个流程是没办法构造出来的。订单一开始就在那里了，不是你按下了修改才出现。查询条件输入框也是一直在那里，不是你选择了查询才出现。你可以随意在DBGrid里面移动记录，尽管接下来并不做什么。你可以输入查询条件，然后删除某个订单，尽管这两个动作没有什么相关。
??通常我们在Qty和Price字段的Onchange事件里面改写Amount 的值，现在我们知道，这是造成代码不清晰的原因之一。因为这个过程的调用，是应该在用户修改了明细之后进行的，但我们为什么不放在这里呢？噢，因为这和Query控件的使用规范不太相称，对于Query控件来说，在OnChange事件改变其它字段的值是推荐的写法。看看，我们的程序解决特殊问题，Query 控件解决常规问题。Query 的事件定义不会影响它本身的代码规范性，但是影响了我们程序的代码规范性。

(待续)

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有