合同预警是我在项目组负责的第一个模块，到今天为止，终于完工。回头看，现在的这个版本和我最初的设想有较大的差异。整个模块主要有两个页面组成，预警信息展示和预警条件设定。前者，以列表的形式显示所有符合预警条件的合同，后者，对预警的条件进行编辑。合理好用的编辑条件是这个模块的关键，本文将对预警条件编辑页面的一些设计思路予以回顾。

图一    图二

       将预警条件分为A/B两类。A类预警条件在新增合同时自动检查，包含合同签订年限和合同签订次数两个选项。如已签订3次合同的人员在签新合同时予以提醒。B类预警条件用于本文开篇所述预警信息的展示。可是设置复杂的组合条件，如固定期限型，将在一个月之内到期的合同予以提醒。

      预警条件由（HRID，SerialNumble），Brief，Title，Content，EWType，SqlSentence，SharePerson这几项组成。HRID为当前操作员的唯一性编号，也是该预警条件的设立者。SerialNumber为该操作员所拥有的预警条件序号。这两个字段为预警条件表的主键。Brief为预警的简称，Title和Content可以对预警条件详细说明，并且使用@ContractName@的形式来表现合同的具体信息。SqlSentence为根据查询条件生成的查询语句。考虑预警条件编制较为复杂，设立SharePerson字段，将该预警条件共享给其他人使用，也即该预警条件的使用者，默认为预警条件的设立者。在合同预警页面中，读取这个字段的内容，来获取操作员所能够使用的预警条件。（like %hrid%）

     预警条件的共享（使用者）设计比较有意思。最初没有考虑到要将预警条件共享给其他人使用，现在即使增加一个字段，存储共享者的hrid，也很麻烦。记录之间高度关联，增加一个共享者，需要在条件设定者里加字符，同时需要将条件赋给共享者，在表中增加一条记录。而删除共享者时，则更为麻烦，所有预警条件没有唯一性编号，很难保持数据一致性。之后考虑新增一张表存储共享关系，但这样对现有程序结构改动太大。最后发现，只要在查询预警信息时使用SharePerson like %hrid%的形式即可，而现有的预警条件编辑页甚至不用作太多变化。这种设计实际上是将条件的编写者和使用者分离，大致实现胡老师所说的预警条件库。

      以上合同预警的大致设计思路。在中途多次变更，bug也出现过无数回，最初的原版本甚至花费了一个月的时间。与初次上手不熟悉环境有关，但更多的是一些可避免的原因造成。存在以下问题：

    1）程序bug太多。头一个月在原型出来后，改bug就改了一个多星期，自己很疲。其实多数bug细心一些都是可以避免的。写程序，是一门细致的学问，很精确，毛躁不得。写程序之前，先想一想思路，再没有理清楚思路之前，不要动手。

     2）设计表的时候，不够合理，昨天甚至发现，存放预警信息的表，甚至连主键都没有。如果都是从页面中对表进行操作自然没有问题，如果有人直接修改数据库呢？再有没有考虑到扩展性，EWType、SharePerson都是后来才加进来的。

    3）独学无友，何况我只是一个初学者。事实上，现有的设计很多都是讨论出来的，一个人扛着时总是容易陷入死胡同。

     4）不断求精，不要怕麻烦。有时因为程序写起来麻烦，所以在设计时就避重就轻，到头来还得还是自己。

    5）嗯，基础很重要，体现了对程序的敏感程度。

     6）在设计程序时，可能有很多条路可以达到最终的目标，但应学会选择一条最简洁的路。如共享者选择页面就是直接调用之前的页面，而不是我自己设计的那个页面。

以上！