【效率专精系列】我有一个梦想：提高开发效率，晚上回家吃鸡

之前零零散散写了几篇文章，主要是实际开发过程中一些效率痛点和相应的改善方法。今天抽空温故知新，把之前的内容串起来，做了个小总结，即《效率专精系列》小系列的总集篇。

回顾项目开发流程

开发一个新项目时，开发流程大概分成以下几步：

1. 设计方案，并落地成设计文档
2. 设计方案评审
3. 任务分拆
4. 和上下游规定接口（服务、前后端等）
5. 代码开发
6. 开发自测
7. 上下游联调（服务、前后端等）
8. 提交QA测试

效率可改进的点

S1. 设计方案，并落地成设计文档

公司内部使用Wiki（XConfluence）管理所有文档，由于互联网产品的大部分开发模式都偏向于面向数据库编程，设计文档里ER图是展现设计的重要工具。但是绘制ER图是个挺费劲的活，不是说自带的draw.io组件不好用，而是说ER图和代码（Sql语句或Java代码）不能互相转化，两者的内容格式高度重合，却只能人工转化。

目前我的方式是先在Intellij Idea中写好持久化对象（PO），用POJO to Text插件把POJO转化为文本并复制到系统剪切板中，然后复制到ER图里，节省了重复录入类名和字段名的时间。

举个栗子，PO类的自定义文本形式为“PO \nid \nupdateTime”。

    Class PO {
        private int id;
        private Date updateTime;
        //getter/setter
    }

S4. 和上下游规定接口（服务、前后端等）/ S6. 开发自测

上下游服务之间有很完善的并行开发方案，即基于接口的开发，通过带有版本号的jar包来解耦双方具体实现的开发。但如果是前后端之间规定接口，一般需要先写接口文档，再写代码，与上面类似，其中很多内容需要人工重复录入，比如说URI、Param、Header、Body体等。

利用API统一描述语言OpenAPI和相应的工具Swagger2可在文档和代码之间搭起一座桥梁。另外该工具也可节约自测中的部分录入工作，如录入URL和Param。

【效率专精系列】善用API统一描述语言提升RestAPI开发效率
5分钟搞定Swagger2环境配置与使用

考虑到篇幅较长的文档反复修改的情况，要快速找到API修改点比较困难。

目前我的方式是利用版本管理和文本比较功能：比方说把API文档和代码一起放在git仓库，或者使用其他带版本管理的文档库；使用git仓库自带的文本比较功能，或者在线的代码比较网站。

文本比较网站	去除前导空格	分享给他人	其他
www.diffnow.com	可以	可以	界面风格原始
www.diffchecker.com	不可以	可以
www.newjson.com/Static/Tools/Diff.html	可以	不可以

S5. 代码开发

互联网公司常见的ORM组件不再是重型的Hibernate，而是轻量级的Mybatis（其实都不算ORM了，最多是Sql模板）。Mybatis中我认为最繁琐的工作就是写业务Sql了，基本上是getXXXByYYYZZZ这种形式，要么再加上分页，类型特征十分明显。

目前我的方式是利用Intellij Idea的Mybatis插件，把Mybatis Mapper类中的Java接口转化成对应的Sql语句。在不考虑优化的情况下，这种类型的Sql如果能自动生成就能节约不少人力，毕竟Sql语句比Java接口声明长多了。

【效率专精系列】善用插件提升MyBatis开发效率

S7. 上下游联调（服务、前后端等）

通常上下游都把自己的分支部署到beta环境来进行联调，存在分支冲突的风险；而且如果代码质量不高的话联调过程中需要反复更新代码，由于beta环境不支持热部署，更新代码的时间成本很高。

目前我的方式是不管是Rpc服务还是URL，把联调放在双方的本地机器上进行，这样热更新、热部署都没问题了。

【效率专精系列】Beta环境不需要，本地联调拯救开发效率
【效率专精系列】几种常见的JVM热部署技术及实现难点浅谈

小诗云

身在互联网，加班易，不加班难，且行且珍惜。