軟體工程經驗點滴之程式碼易複製性

上一次粗略說了一下工程目錄的問題，這一章主要說說裡面的細節。裡面沒有過多的教科書經驗，都是些個人經驗，大家可以看成草根經驗吧，有認為不對的地方，大家可以發郵件給我 mailto:ttch007@sina.com，直接評論我的回覆時效性非常低。

上一節說的比較散亂，那麼下面我整理一個總綱，然後以後一個個的描述。

一個好的工程，最初的優良標準是程式碼是否易於複製，是否存在簡單模式搭配。

1.目錄名稱設定

目錄的名稱設定和術語``有一定關係，這樣方便於快速記憶和查詢，我最早接觸的一個大概有70萬程式碼量左右的delphi工程，是通過中文名設定工程目錄的。對，你沒看錯，確實是中文名。因為大部分都是術語型，翻譯後的詞彙無法直接準確，且我們掌握和溝通也存在十分嚴重的差異，所以中文大家一套術語就搞定了，你一說投保，大家都知道對應的目錄在哪？

歸類下來，大概有幾種：

1、業務術語模型目錄（上面的例子）。
2、技術術語模型（比如引擎一個目錄目錄名稱，model一個目錄目錄名稱，view一個目錄名稱等等）
3、功能術語模型（會包含子模組為技術術語模組，此種較為優良）。

2.標準用語

比如投保，我們稱為Apl，等等細節的對錯不是特別重要，這個可以迭代式改進，因為促使定製一個完全無誤的術語模型，是需要很大精力和時間，這樣往往會導致專案上的延期。

比如如下例子：
    function SaveApl:
        Assert CheckApl//檢測投保人
        Assert CheckIsd//檢測被保人
        Assert Subj //檢測標的項
        SaveApl//儲存被保險人
        SaveIsd//儲存投保人
        Save Subj//儲存標的

    if Plc.state == PreApl:
        SavePlc(Plc);

這樣的虛擬碼很容易就讓程式設計師理解。

3.標準場景

一般系統開發團隊，入場後，首先會編寫需求文件，但對於場景整理忽略性較大，所以到後期的調整和問題比較多，首先最大的問題是成本居高不下，為什麼呢？

1、標準的場景定義沒有，其實程式設計師是比較喜歡複製場景的，如果場景可以直接被呼叫，工程質量就會上一層次，比如核保中的校驗引數函式，可以定義一系列的場景文件對應模型，然後通過gendoc方式來生成，這樣程式設計師寫其他的程式的時候，可以通過直接呼叫，省略掉重複編寫的過程，這樣不會產生歧義程式碼，重複程式碼，亂程式碼，錯誤程式碼，標準就是一句話`修補總比重寫好`（配置系統另當別論）。

2、程式碼review做的時候沒有參考依據，大部分人以為review都以為review只是進行基本的程式碼模式和名稱格式和拼寫等檢查，其實review最好的做法是減少`癌細胞繁殖數量`，那麼參考依據就是標準場景定義。

標準場景我認為包括幾個部分：

1、Action(主要指業務Action層，業務的非資料庫處理邏輯部分。)
2、Model的CRUD。
3、Services層的事務函式術語。

4.標準邏輯

這節不需要過於累贅說臺多，因為其實這個就是指業務Action，業務的非資料庫處理邏輯，為什麼要做這部分呢？

1、減少程式設計師寫重複邏輯程式碼。
2、為了將來系統擴充套件有依據。
3、為了形成指令碼性靜態程式碼生成器做準備。
4、形成標準術語庫。

額，先寫到這，等下次再繼續。