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

圖一    圖二

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

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

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

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

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

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

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

     4）不斷求精，不要怕麻煩。有時因為程序寫起來麻煩，所以在設計時就避重就輕，到頭來還得還是自己。

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

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

以上！