【手把手教你】电子合同的巧妙设计
作者:杨考 微信 : 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. 个人遵从一个准则,过手的项目,基本要稳定下来,不能稳定下来的要给出一个优化意见