熟悉rad开发工具的同学都知道,看“前人”“遗留”下来的程序是一种痛苦。改这些程序更是一种痛苦。而改程序的过程中,被测出来一些“史前错误”是痛苦中的痛苦。扣钱事小,一口气咽不下,被委屈的滋味不好受。因此,同学们在改程序的时候小心翼翼,全局变量绝对不能动,明明看到原来的一个函数改一下就能满足要求,但还是自己再写一个比较保险。谁知道改过的地方会不会造成定时炸弹呢?
所以,归根到底,我们要使得程序容易被理解,容易被修改,容易被扩充,才是最终目的。万事开头难,先从自己做起。 【相关文章:浅谈如何利用PB实现仿QQ自动显示/隐藏】
于是乎,程序越来越复杂,越来越臃肿。开发组长有对策,每个组员专门负责某几个模块,时间长了,自己知根知底,就敢于对自己程序开刀。但人员调动,员工去留是不可避免的事情,一个人负责固定几个程序难以长久。抛开这些不谈,假设某同学在公司就是负责有限的几个模块维护,那他有何发展可言呢? 【扩展阅读:关于csdnblog的几个疑问的非官方解】
1、全局变量。 【扩展信息:浅谈如何利用PB实现仿QQ自动显示/隐藏】
首先来看一下,别人的程序,到底是什么妨碍了自己阅读与修改?
全局变量是个讨厌的东西。 假设我们现在看到这里有一句: mbdisplayinprice: boolean; //是否显示进价 按道理说,风格挺好的,有注释,有前缀,名字也起的好。但是这个变量它没有一个“主人”,如果说,它是单据类的属性: treceiptinfo.displayinprice,我们能够理解,如果说它是系统参数类的属性:tsysparams.displayinprice,我们也好理解,但是现在它是属于整个程序的,所以我们其实并不知道它确切的作用范围。所以,全局变量带来的问题是它不具备确切的含义而经常被误解,它不属于某个对象而在整个程序被随处可能被修改。
2、程序代码分布在不同区域。
假设我们现在要检查程序的修改订单这样一个功能的程序代码。按照我们通常的理解,这是一个很单一的功能,应该这样实现: ... 下一页