【网易中台实践】云信业务中台的敏捷开发

我一直从事云信业务中台的后端开发工做。云信的业务发展迅速，产品的需求层出不穷，团队成员不断壮大。如何快速知足产品需求，同时保证线上系统的稳定迭代，以及小团队如何协同？接下来我会从开发规范、开发流程、项目管理、如何敏捷等方面讲述一些个人心路历程，以供参考。

开发规范

云信业务中台团队由最开始的2人，发展到最多时6人。前期阶段只关注需求如何快速迭代上线，没有过多关注代码规范。随着代码数量增长，逐渐发现迭代和维护的难度愈来愈大，每位程序员都有本身的编码习惯，十几万行的系统代码，看起来就像一堆“屎山”。此时，必须引入代码规范，让写代码和读代码的程序员都可以心情愉悦。

代码规范，直接借鉴的《阿里巴巴java开发手册》，手册里详细制定了编码、异常日志、单元测试、安全规约、MYSQL数据库、工程结构等的相关规范，你们能够网上下载阅读。

有了规范，你们如何有效地执行？

统一IDE代码模板

约定了IDEA/Eclipse IDE代码的统一模板，新建类、方法，格式化所有统一。避免不一样的开发同窗使用不一样的模板带来的差别化，以及增长merge的成本。可使用eclipse-java-google-style模板。在提交代码时使用Alibaba Java Coding Guidelines插件，对不符合规范的代码进行提醒，修改后再提交。

分支管理

最开始，团队使用的SVN来管理源码，随着git的流行，后来所有切换到git。针对分支开发，制定了如下规范：

• 分支的定义（master、develop、release、hotfix、feature），不一样分支会有不一样的权限；
• checkout、merge request流程，merge时还能够作一次code review；
• 提测、上线流程，不一样阶段使用不一样的分支测试和发布，上线完成后打tag，方便回滚。

统一工具与框架

对于业务中使用到的公共工具类和方法，统一抽象和封装到二方库，好比JedisUtil、httpClient、日期格式的转换、文件读写导出等。全部系通通一框架和版本，好比spring、spring boot，mybatis、dubbo、MQ等，让开发同窗能将主要精力放在业务模块的开发上。

注释和文档

让程序员既要写得一手好代码，又要写得一手好文档，而且保证代码和文档的同步，面对时间紧、需求多的状况下，实现起来不现实。那如何作到文档与代码同步？做为程序员，简单直接的方法的就是写好注释。在类、方法、属性前加上适当的注释，对于难以解释的代码加上必要的注释。Controller层的api可使用spring-swagger来保持同步，减小因修改代码而维护文档的成本。

如何作到敏捷？

敏捷这个词早在90年代初就提出了，据统计，2018年90%的软件开发都采用了敏捷开发。下面这段话很好的解释了什么是敏捷？

敏捷开发（agile development）是很是流行的软件开发方法，敏捷开发的核心是迭代开发，

迭代开发其实就是"重复开发"。它将开发过程拆分红多个小周期，即一次"大开发"变成屡次"小开发"，每次小开发都是一样的流程。

其实这里所谓的一样的流程，就是传统的瀑布开发模式，包括几个重要的环节。我在实际的开发过程当中，主要有如下几个重要的里程碑节点：

需求评审

咱们的需求主要来源于产品经理，产品经理经过给开发、测试讲解本次版本的需求背景、详细说明、完成后的效果，让相关同窗理解需求。同时，开发评估需求的合理性、可行性，能够对需求有所调整。这个环节必不可少。固然，需求也能够来自开发，测试，也须要与相关人员沟通。

设计评审

这里的设计评审，不是视觉和交互评审，是技术实现的设计评审。

若是本次迭代的需求在技术方案上须要评估，则须要对详细设计作一个评估，避免开发过程或上线后形成缺陷和遗漏。若是只是常规迭代，则能够省略这一步。

编码

实现本次迭代的需求

测试用例评审

测试用例和编码应该是同步的，对测试写的用例进行评估，可能会发现测试遗漏点，并将其补充完整。

发布计划评审

若是本次迭代涉及的变动复杂或须要跨部门合做，有先后依赖的关系，须要写一个发布计划，写清楚上线的时间、步骤、注意事项，以避免形成上线混乱。同时，要有发布失败的回滚方案。

上线

按照发布计划，进行系统的发布上线。

复盘

若是本次迭代有发生重大失误，形成发布失败或发布后引发严重的线上问题，则须要产品、测试、开发等相关同窗一块儿复盘本次迭代，总结经验，避免下次再发生一样的事情。

按照这个瀑布模式进行迭代，以为步骤是否是有点多？太浪费时间?和所谓的敏捷相违背？但实际是，多少实践经验告诉我，这些流程避免不了。好比没有需求评审，开发完成了，发现效果不是产品想要的。没有测试评审，开发有修改的地方，测试没有测试到，致使测试遗漏。

除了这些重要的里程碑，其实还有一些关键节点，好比视觉、交互评审，产品走查，冒烟测试，预发布验证等。

敏捷实践

根据敏捷开发的价格观和十二条原则，咱们团队作了以下调整：

少开会

让产品、测试、开发尽可能坐在一块儿，若是有任何问题，直接使用面对面交流的方式，解决问题。避免使用邮件、即时通信软件带来的信息滞后。若是要开会，可使用站会的形式，简洁沟通。若是必须开会，则尽可能控制开会时间，说重点和问题，高效解决。

控制迭代节奏

每次迭代主要解决优先级最高或比较紧急的需求，控制一次迭代的周期在2~3周，从而达到不断可持续的交付。

按期复盘

针对一段时间内，系统出现的问题，流程的问题等进行复盘和总结。技术实现上，若是用合理的方案快速实现。流程上，如何优化，才能更高效。

如何用好敏捷，打造高效团队，以上均是本人工做实践总结，纯属我的看法，若有疑问，欢迎拍砖。