熟悉RAD開發(fā)工具的同學(xué)都知道，看“前人”“遺留”下來的程序是一種痛苦。改這些程序更是一種痛苦。而改程序的過程中，被測出來一些“史前錯(cuò)誤”是痛苦中的痛苦。扣錢事小，一口氣咽不下，被委屈的滋味不好受。因此，同學(xué)們在改程序的時(shí)候小心翼翼，全局變量絕對不能動(dòng)，明明看到原來的一個(gè)函數(shù)改一下就能滿足要求，但還是自己再寫一個(gè)比較保險(xiǎn)。誰知道改過的地方會(huì)不會(huì)造成定時(shí)炸彈呢？

于是乎，程序越來越復(fù)雜，越來越臃腫。開發(fā)組長有對策，每個(gè)組員專門負(fù)責(zé)某幾個(gè)模塊，時(shí)間長了，自己知根知底，就敢于對自己程序開刀。但人員調(diào)動(dòng)，員工去留是不可避免的事情，一個(gè)人負(fù)責(zé)固定幾個(gè)程序難以長久。拋開這些不談，假設(shè)某同學(xué)在公司就是負(fù)責(zé)有限的幾個(gè)模塊維護(hù)，那他有何發(fā)展可言呢？

所以，歸根到底，我們要使得程序容易被理解，容易被修改，容易被擴(kuò)充，才是最終目的。萬事開頭難，先從自己做起。

首先來看一下，別人的程序，到底是什么妨礙了自己閱讀和修改？

1、全局變量。
全局變量是個(gè)討厭的東西。  假設(shè)我們現(xiàn)在看到這里有一句：
mbDisplayInPRice: Boolean;   //是否顯示進(jìn)價(jià)
按道理說，風(fēng)格挺好的，有注釋，有前綴，名字也起的好。但是這個(gè)變量它沒有一個(gè)“主人”，如果說，它是單據(jù)類的屬性： TReceiptInfo.DisplayInPrice，我們能夠理解，如果說它是系統(tǒng)參數(shù)類的屬性：TSysParams.DisplayInPrice，我們也好理解，但是現(xiàn)在它是屬于整個(gè)程序的，所以我們其實(shí)并不知道它確切的作用范圍。

所以，全局變量帶來的問題是它不具備確切的含義而經(jīng)常被誤解，它不屬于某個(gè)對象而在整個(gè)程序被隨處可能被修改。

2、程序代碼分布在不同區(qū)域。
假設(shè)我們現(xiàn)在要檢查程序的修改訂單這樣一個(gè)功能的程序代碼。按照我們通常的理解，這是一個(gè)很單一的功能，應(yīng)該這樣實(shí)現(xiàn)：
檢查用戶權(quán)限
↓
效驗(yàn)用戶輸入
↓
將用戶輸入作為SQL 的輸入?yún)?shù)
↓
調(diào)用SQL
↓
檢查SQL 運(yùn)行結(jié)果

這些程序，如果比較短的話，應(yīng)該是一個(gè)過程完成。如果比較長，就應(yīng)該分為幾個(gè)過程完成，但是由同一個(gè)函數(shù)來調(diào)用，這樣都能夠使我們看得清楚明白。
但是在我們程序里面，檢查用戶權(quán)限是在控件里面實(shí)現(xiàn)的，效驗(yàn)用戶輸入可能放在Query.BeforePost里面檢查，SQL 是寫在窗體文件里面的（天知道哪段程序會(huì)對SQL進(jìn)行過處理，比如加上采購組權(quán)限什么的），ApplyUpdate 是在Query.AfterPost 事件里面完成的，對某些字段賦初值可能在Query.AfterInsert事件，也可能在 Query.OnNewRecord事件，甚至可能在數(shù)據(jù)庫觸發(fā)器做。
換句話說，我們檢查這一段程序，要到各種不同的地方去看，去改，真是痛苦啊。當(dāng)然，如果我們有一個(gè)叫 UpdateOrder 的函數(shù)來統(tǒng)一調(diào)用這些過程，那么多少能幫助理解，但是且慢，這里面牽涉到事件，事件是控件來調(diào)用的，Query1AfterPost就是Query1AfterPost，它不是叫 CommitQuery1 的私有方法，所以它里面很可能包含了其它的程序代碼（除了ApplyUpdate和CommitUpdate），你改動(dòng)了它，就可能埋下了定時(shí)炸彈。

3、事件陷阱
現(xiàn)在的詳細(xì)設(shè)計(jì)文檔里面已經(jīng)基本上見不到流程圖了。因?yàn)榱鞒虉D無從畫起。事件驅(qū)動(dòng)、界面驅(qū)動(dòng)的RAD方法顛覆了我們的編程方法。
記得在寫DOS程序的時(shí)候，程序流程是很簡單的，因?yàn)榫褪且粭l線嘛，最多有個(gè)循環(huán)、有個(gè)條件轉(zhuǎn)向語句，因此程序清晰易懂，代碼優(yōu)化也容易。
然后就是講用戶交互了，也好辦啊，程序跑到中間，需要用戶確認(rèn)的地方，就在屏幕顯示提示信息，讓用戶按y 或者n，接著往下跑，其實(shí)也就是條件轉(zhuǎn)向語句。
到了Windows時(shí)代、RAD時(shí)代，情況就完全不同了。假設(shè)我們按照DOS程序的思路來設(shè)計(jì)修改訂單的流程。
用戶按下修改訂單按鈕
↓
提示用戶輸入訂單號
↓
彈出訂單明細(xì)表，讓用戶選擇
↓
用戶選中某個(gè)明細(xì)，系統(tǒng)顯示數(shù)量和價(jià)格的修改框，用戶修改
↓
彈出訂單明細(xì)表，讓用戶選擇（重復(fù)）
↓
用戶選擇結(jié)束作業(yè)
↓
程序提交修改

但是實(shí)際上呢，這個(gè)流程是沒辦法構(gòu)造出來的。訂單一開始就在那里了，不是你按下了修改才出現(xiàn)。查詢條件輸入框也是一直在那里，不是你選擇了查詢才出現(xiàn)。你可以隨意在DBGrid里面移動(dòng)記錄，盡管接下來并不做什么。你可以輸入查詢條件，然后刪除某個(gè)訂單，盡管這兩個(gè)動(dòng)作沒有什么相關(guān)。
通常我們在Qty和Price字段的Onchange事件里面改寫Amount 的值，現(xiàn)在我們知道，這是造成代碼不清晰的原因之一。因?yàn)檫@個(gè)過程的調(diào)用，是應(yīng)該在用戶修改了明細(xì)之后進(jìn)行的，但我們?yōu)槭裁床环旁谶@里呢？噢，因?yàn)檫@和Query控件的使用規(guī)范不太相稱，對于Query控件來說，在OnChange事件改變其它字段的值是推薦的寫法。看看，我們的程序解決特殊問題，Query 控件解決常規(guī)問題。Query 的事件定義不會(huì)影響它本身的代碼規(guī)范性，但是影響了我們程序的代碼規(guī)范性。

(待續(xù))