背景
我们总会通过增加一些流程来规范一些行为。但是流程增加，总需要投入精力来执行，维护或监督以及反馈效果
想法
在引入流程的时候，需要相关工具做支撑，让重复的工作，都靠工具及时反馈。让执行的人，马上、立即知道自己执行的效果。
并且，从这个流程的执行中，获得好处，以及节省其它需要做的事情与时间。
从每个人都是惰性的来说，都愿意选择节省更多时间的工作方式。
如果使用流程，减少一些本来需要做的工作，节省时间，会让人更易于接受
这样流程，可以提高工作效率，并且达到规范的效果。
如果单单规范工作，而牺牲效率，久而久之，会使人不堪重负
分析
想法来源是最近在公司对我们之前的ci流程进行升级，支持运行单元测试。
升级内容为:
- 运行当前目录下的所有包的单元测试
- 输出单元测试报告html 格式
- 计算单元测试覆盖率
- 在gitlab 上，展示覆盖率
- 修改了gitlab 代码，让覆盖率展示在项目列表上
- 单元测试一旦不通过，ci直接失败
这里,聊聊我的想法
自动运行单元测试，节省了以下环节:
- 手动运行已经存在的单元测试的麻烦
- 省去了编写运行所有单元测试脚本的麻烦
- 省去了学习怎么输出报告的时间
- 省去了计算单元测试覆盖率的时间
并且，还可以给领导、同事炫耀自己的项目，单元测试覆盖率。
并且由于他人也可以同时看到自己的代码，所以作弊有心理负担。
单元覆盖率不与绩效、利益挂钩，纯属个人行为，以及部分的社交、炫耀属性
这里，满足了社交需求与尊重需求，
社交需求 既公布覆盖率，使大家知道你的覆盖率多少，
尊重需求 单元测试写得好，供同事参考，赢得尊重。
自我超越的人，又给与十分直观的展示，以及节省其自己运行所有单元测试的时间。
机器辅助
指定好相应的流程，然后通过机器辅助方式，将固定流程工具化。
避免需要人力不断确认流程的准确性，使流程得不到好的实施而且还浪费很多人力
人的信息交流都具备一定的损失与误导。只有通过工具固化下来，每个人都去了解这工具的规则。
并且，逾越规则后，由工具纠正以及告知错误。比如各种格式错误、格式模板填写等等，都可以利用类似方法。
理论
马斯洛需求层次:
- 自我超越
- 尊重需求
- 社会需求
- 安全需求
- 生理需求
附录
在实施过程中，通过修改gitlab的源代码，用来展示单元测试的覆盖率
源码修改可参考:
代码路径: /opt/gitlab/embedded/service/gitlab-rails/app/views/shared/projects
在
.controls
.prepend-top-0
尾部，添加一行:
= image_tag project_path(project)+'/badges/master/coverage.svg', class: "", alt:''
