CSDN博客

img lobby

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

发表于2004/6/24 9:18:00  979人阅读

分类: 技术文章

熟悉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 的事件定义不会影响它本身的代码规范性,但是影响了我们程序的代码规范性。

(待续)

0 0

相关博文

我的热门文章

img
取 消
img