合同預(yù)警是我在項目組負責的第一個模塊，到今天為止，終于完工。回頭看，現(xiàn)在的這個版本和我最初的設(shè)想有較大的差異。整個模塊主要有兩個頁面組成，預(yù)警信息展示和預(yù)警條件設(shè)定。前者，以列表的形式顯示所有符合預(yù)警條件的合同，后者，對預(yù)警的條件進行編輯。合理好用的編輯條件是這個模塊的關(guān)鍵，本文將對預(yù)警條件編輯頁面的一些設(shè)計思路予以回顧。

圖一    圖二

       將預(yù)警條件分為A/B兩類。A類預(yù)警條件在新增合同時自動檢查，包含合同簽訂年限和合同簽訂次數(shù)兩個選項。如已簽訂3次合同的人員在簽新合同時予以提醒。B類預(yù)警條件用于本文開篇所述預(yù)警信息的展示。可是設(shè)置復(fù)雜的組合條件，如固定期限型，將在一個月之內(nèi)到期的合同予以提醒。

      預(yù)警條件由（HRID，SerialNumble），Brief，Title，Content，EWType，SqlSentence，SharePerson這幾項組成。HRID為當前操作員的唯一性編號，也是該預(yù)警條件的設(shè)立者。SerialNumber為該操作員所擁有的預(yù)警條件序號。這兩個字段為預(yù)警條件表的主鍵。Brief為預(yù)警的簡稱，Title和Content可以對預(yù)警條件詳細說明，并且使用@ContractName@的形式來表現(xiàn)合同的具體信息。SqlSentence為根據(jù)查詢條件生成的查詢語句。考慮預(yù)警條件編制較為復(fù)雜，設(shè)立SharePerson字段，將該預(yù)警條件共享給其他人使用，也即該預(yù)警條件的使用者，默認為預(yù)警條件的設(shè)立者。在合同預(yù)警頁面中，讀取這個字段的內(nèi)容，來獲取操作員所能夠使用的預(yù)警條件。（like %hrid%）

     預(yù)警條件的共享（使用者）設(shè)計比較有意思。最初沒有考慮到要將預(yù)警條件共享給其他人使用，現(xiàn)在即使增加一個字段，存儲共享者的hrid，也很麻煩。記錄之間高度關(guān)聯(lián)，增加一個共享者，需要在條件設(shè)定者里加字符，同時需要將條件賦給共享者，在表中增加一條記錄。而刪除共享者時，則更為麻煩，所有預(yù)警條件沒有唯一性編號，很難保持數(shù)據(jù)一致性。之后考慮新增一張表存儲共享關(guān)系，但這樣對現(xiàn)有程序結(jié)構(gòu)改動太大。最后發(fā)現(xiàn)，只要在查詢預(yù)警信息時使用SharePerson like %hrid%的形式即可，而現(xiàn)有的預(yù)警條件編輯頁甚至不用作太多變化。這種設(shè)計實際上是將條件的編寫者和使用者分離，大致實現(xiàn)胡老師所說的預(yù)警條件庫。

      以上合同預(yù)警的大致設(shè)計思路。在中途多次變更，bug也出現(xiàn)過無數(shù)回，最初的原版本甚至花費了一個月的時間。與初次上手不熟悉環(huán)境有關(guān)，但更多的是一些可避免的原因造成。存在以下問題：

    1）程序bug太多。頭一個月在原型出來后，改bug就改了一個多星期，自己很疲。其實多數(shù)bug細心一些都是可以避免的。寫程序，是一門細致的學(xué)問，很精確，毛躁不得。寫程序之前，先想一想思路，再沒有理清楚思路之前，不要動手。

     2）設(shè)計表的時候，不夠合理，昨天甚至發(fā)現(xiàn)，存放預(yù)警信息的表，甚至連主鍵都沒有。如果都是從頁面中對表進行操作自然沒有問題，如果有人直接修改數(shù)據(jù)庫呢？再有沒有考慮到擴展性，EWType、SharePerson都是后來才加進來的。

    3）獨學(xué)無友，何況我只是一個初學(xué)者。事實上，現(xiàn)有的設(shè)計很多都是討論出來的，一個人扛著時總是容易陷入死胡同。

     4）不斷求精，不要怕麻煩。有時因為程序?qū)懫饋砺闊栽谠O(shè)計時就避重就輕，到頭來還得還是自己。

    5）嗯，基礎(chǔ)很重要，體現(xiàn)了對程序的敏感程度。

     6）在設(shè)計程序時，可能有很多條路可以達到最終的目標，但應(yīng)學(xué)會選擇一條最簡潔的路。如共享者選擇頁面就是直接調(diào)用之前的頁面，而不是我自己設(shè)計的那個頁面。

以上！