【手把手教你】电子合同的巧妙设计

 

作者：杨考   微信 : devin_cn_hd_09_16    欢迎讨论问题

在每次收到阅读者添加微信并开始交流讨论，心理是无比的激动。

 

一.背景

电子合同向来是各个公司研发人员比较头疼的一个业务。

 

1、电子合同维护的信息很多，且外观表现形式差异很大

 

2、电子合同是一个人工操作的应用，因此后台会产生一堆垃圾或者不合法的输入信息

 

3、电子合同是电子版的，但是同样具有法律效益，即使是过期的合同也是有法律效益的

 

4、历史合同无论在后续的任何时间展示，都必须和当时前签署时的展示一模一样，一字都不能差

 

5、电子合同涉及多个主体时，或者多种类型的合同，往往研发工程师都想抽象，兼容 ...... 坑之又坑的大坑

 

6、合同会定期升级，新老合同的数据和展示逻辑要相互兼容

 

7、合同内容修改，需要准确且简明的 change log 日志，需要能够简单的diff 指定合同的内容

 

二. 电子合同的样例

因涉及公司信息，电子合同的样例就不在这里截图展示了。自己回去看看自己的<劳动合同>、<购房合同> ... ...

 

三. 电子合同的设计【老版本的】【研发的噩梦】

 

1.老版本的问题之多，多的都成了研发人员的噩梦了。产品也害怕了，需求开发效率低，需求堆积严重

 

2. 合同主体【就是合同的所有内容】

 

关键字解释

 

如上 source 就是多种合同的主体或者类型，如 "劳动合同"、"购房合同"

 

不同合同，会有自己的升级，哪怕修改了一个字，也需要升级一下版本。其中 type 和 version 就是指定了合同的模板和版本，从而映射出了一个 tpl 模板。

 

下面就是 单个的条款 clause 了。

 

四. 电子合同的设计【新版本】【要命的工期和烧脑的逻辑】

 

1.关于批量修改、权限控制部分，伤了多少产品经理的脑细胞，最后研发人员给出了方案

 

2. 开发时间，7天完成设计与开发，7天测试并开始联调上线

 

3. 合同主体

 

对比老版本，新的设计里多了一个group的概念。

 

group 和 clause之间的对应关系

 

 

4. 合同主体框架实现

 

 

 

a) getContractEdit 是获取合同模板 

    历史合同获取历史模板

    编辑或者创建合同，获取最新的模板

 

b) content 

    新建合同 ： 默认的数据内容

    编辑合同 ：  上一次编辑的内容

    历史合同 ： 指定的版本的生效内容

 

c) splitConfFromContent

从合同模板+编辑数据的混合体中，剥离配置数据

 

d) applyConfToContent

将配置数据【默认数据、上次编辑数据、历史数据】填入到合同模板中

 

e) 数据的剥离和填充

主要是方便入参输入

方便新、老合同数据的对比，用来生成change log日志，对比决定部分特殊逻辑

 

 

5. 多方操作，不同人的权限设置和不同APP上分段展示部分合同内容:

合同主页面、xxx配置页面、批量修改某个主体的多种属性页面

 

6. 开发完成后，项目的每个人员，包括研发、测试、产品都顿时感觉到了无比的幸福和如释重负

 

五. 设计差异【读着感官】

到此2版合同的需求差异，大家基本已经明确了一部分了。接下来带大家看看详细的差异

 

 

六. 差异对比

 

1. 功能差异对比

类目	老系统	新系统
基本功能	空合同创建、合同编辑、历史合同浏览、合同中条款信息修改、合同操作日志信息	完全和老系统相同
相同条款复制	一个模板不能支持多个相同条款的存在	可以支持相同条款的存在，只需要建立多个group，而每个group中包含相同的条款，针对条款进行逻辑编程即可。
页面条款调整位置	不支持页面条款的调整，如果需要调整页面，需要升级模板	支持页面条款位置的调整，如果仅仅只是页面条款的位置调整，则通过后端返回数据的次序即可决定，如果除了条款位置调整，还附带有任何一点信息变更，则需要升级模板
特定APP	不能展示部分合同信息 如果条款缺失，则前端展示错误	前端不依赖后端返回的group数量，而影响展示结果，即后端返回部分group，则前端按需展示即可
批量修改	不支持批量修改	可以批量修改某个子类，子类有自己的合同
修改父类同步	支持父类修改，但父类修改不会同步至子类	支持批量父类的修改，父类的修改可以快速同步至子类
权限控制	通过操作页面的按钮控制权限	通过读写分离实现权限控制，即有些权限的人，可以调用写API，其它的只能调用读API。

 

当时关于批量修改如何提需求，PM同学也死了不少脑细胞

 

2. 效率差异对比

 

类目	老系统	新系统
代码量	10K 行	2K行
执行效率	20条SQL	2~3条SQL
模板	严重依赖模板 模板升级、新增品类都是通过模板完成	只依赖于条款，没有模板概念，无缝升级
潜力	模板和数据绑定严格	模板和数据无关 可以软删除某个分组、也可以再恢复
合同状态分离	已生效和编辑中的状态概念混淆	1、状态分离 2、编辑数据和生效数据分离
数据格式	多种数据格式 1、入参格式 2、上次保存的格式 3、历史合同的格式	相同格式
日志	以前是一堆，内部变量都在日志里	日志意义明确，翻译很完整
生效合同内容获取	逻辑非常复杂	非常简单
续签	以前是一种状态，维护成本和一致性问题	现在都是实时查询的结果翻译
合同默认值	没有	有空模板 有初始化的默认模板
问题定位效率		操作人相关信息完整，很准确、debug log详细

 

3.效率

以前的老合同，坑太多，都是新人入职之后，练手必备项目，再小的需求，也要1人1周开发完成，如果碰到稍微大点的项目，则需要的时间更多，而且引发老逻辑问题的概率更大

 

现在新的合同，一般小需求，基本是1人0.5天就能完成，稍大点需求，基本1人3天就能搞定

 

 

七. 总结

 

1.项目设计的重要性，好的设计是自我提升，也是财富积累

 

2.项目后续维护的把关很重要

 

3. 个人遵从一个准则，过手的项目，基本要稳定下来，不能稳定下来的要给出一个优化意见