熟悉rad開發工具的同學都知道，看「前人」「遺留」下來的程式是一種痛苦。改這些程式更是一種痛苦。而改程式的過程中，被測出來一些「史前錯誤」是痛苦中的痛苦。扣錢事小，一口氣嚥不下，被委屈的滋味不好受。因此，同學們在改程式的時候小心翼翼，全域性變數絕對不能動，明明看到原來的乙個函式改一下就能滿足要求，但還是自己再寫乙個比較保險。誰知道改過的地方會不會造成定時炸彈呢？
於是乎，程式越來越複雜，越來越臃腫。開發組長有對策，每個組員專門負責某幾個模組，時間長了，自己知根知底，就敢於對自己程式開刀。但人員調動，員工去留是不可避免的事情，乙個人負責固定幾個程式難以長久。拋開這些不談，假設某同學在公司就是負責有限的幾個模組維護，那他有何發展可言呢？
所以，歸根到底，我們要使得程式容易被理解，容易被修改，容易被擴充，才是最終目的。萬事開頭難，先從自己做起。
首先來看一下，別人的程式，到底是什麼妨礙了自己閱讀和修改？
1、全域性變數。全域性變數是個討厭的東西。 假設我們現在看到這裡有一句：mbdisplayinprice: boolean; //是否顯示進價按道理說，風格挺好的，有注釋，有字首，名字也起的好。但是這個變數它沒有乙個「主人」，如果說，它是單據類的屬性： treceiptinfo.displayinprice，我們能夠理解，如果說它是系統引數類的屬性：tsysparams.displayinprice，我們也好理解，但是現在它是屬於整個程式的，所以我們其實並不知道它確切的作用範圍。
所以，全域性變數帶來的問題是它不具備確切的含義而經常被誤解，它不屬於某個物件而在整個程式被隨處可能被修改。
3、事件陷阱現在的詳細設計文件裡面已經基本上見不到流程圖了。因為流程圖無從畫起。事件驅動、介面驅動的rad方法顛覆了我們的程式設計方法。記得在寫dos程式的時候，程式流程是很簡單的，因為就是一條線嘛，最多有個迴圈、有個條件轉向語句，因此程式清晰易懂，**優化也容易。然後就是講使用者互動了，也好辦啊，程式跑到中間，需要使用者確認的地方，就在螢幕顯示提示資訊，讓使用者按y 或者n，接著往下跑，其實也就是條件轉向語句。到了windows時代、rad時代，情況就完全不同了。假設我們按照dos程式的思路來設計修改訂單的流程。使用者按下修改訂單按鈕↓提示使用者輸入訂單號 ↓彈出訂單明細表，讓使用者選擇↓使用者選中某個明細，系統顯示數量和**的修改框，使用者修改↓彈出訂單明細表，讓使用者選擇（重複）↓使用者選擇結束作業↓程式提交修改
但是實際上呢，這個流程是沒辦法構造出來的。訂單一開始就在那裡了，不是你按下了修改才出現。查詢條件輸入框也是一直在那裡，不是你選擇了查詢才出現。你可以隨意在dbgrid裡面移動記錄，儘管接下來並不做什麼。你可以輸入查詢條件，然後刪除某個訂單，儘管這兩個動作沒有什麼相關。通常我們在qty和price欄位的onchange事件裡面改寫amount 的值，現在我們知道，這是造成**不清晰的原因之一。因為這個過程的呼叫，是應該在使用者修改了明細之後進行的，但我們為什麼不放在這裡呢？噢，因為這和query控制項的使用規範不太相稱，對於query控制項來說，在onchange事件改變其它欄位的值是推薦的寫法。看看，我們的程式解決特殊問題，query 控制項解決常規問題。query 的事件定義不會影響它本身的**規範性，但是影響了我們程式的**規範性。
(待續)
新世紀的五四運動 程式白話文
熟悉rad開發工具的同學都知道，看 前人 遺留 下來的程式是一種痛苦。改這些程式更是一種痛苦。而改程式的過程中，被測出來一些 史前錯誤 是痛苦中的痛苦。扣錢事小，一口氣嚥不下，被委屈的滋味不好受。因此，同學們在改程式的時候小心翼翼，全域性變數絕對不能動，明明看到原來的乙個函式改一下就能滿足要求，但還...
純真新世紀
純真新世紀 中的每一位創作者與許多人一樣，都是希望通過 探求心靈與自然世界裡純真本質的性情中人。這張 邀請到hbo cinemax abc discovery多部影片和紀錄片，及亨利曼西thebeegeesbono peter gabriel dionne warwick gee benson等固定...
新世紀專案總結筆記一
1 資料繫結時 eval 和 bind 的區別 據繫結表示式包含在 和 分隔符之內，並使用 eval 和 bind 函式。eval 函式用於定義單向 唯讀 繫結。bind 函式用於定義雙向 可更新 繫結。使用 eval 方法 eval 方法可計算資料繫結控制項 如 gridview detailsv...