目录
前言
之前说到因为复盘到团队之前的故障很多是跟接口有关的，因此近期也在团队内部引进试用YAPI这个接口管理平台。用了大概几周吧，也找了团队的同事了解了一下具体的效果。
那这类平台有个什么样的好处呢？
1、团队内形成契约关系
我特意画了个前后对比图（个人比较喜欢可视化还有彩色系的东西，让人心情愉悦，哈哈）
在没有平台之间，我们的作业模式是怎么样呢？接口文档是不同步的，因为：
- 修改的成本很廉价，且每次改完代码很大程度又忘记修改word文档；
- 同步机制很弱，因为都是通过邮件、IM等天生非协同的工具进行版本同步；
- 种交互方式是单向的（从提供方到消费方），没有约束力的，毕竟是团队内部，总不能搞内讧吧；
- 没有持续的“仪式感”对外承诺对外的服务细节（API接口细节，如字段、是否REST风格等），一般情况就是1.0版本时候会象征性发个正式邮件，但是后面的小优化小迭代就会显得相对随意；
因此，开发人员改起来就随心所欲了，完全忘记了之前跟同事的“口头”承诺（即约定要改动的地方），这个承诺是抽象的，说它抽象是因为只存在于word文档，且单纯通过邮件、IM传播的Word文档是没有协同机制的（因为发送和接收都不能保证有序的，版本管理也强依赖人的自觉性和记忆力，也因此子虚乌有）。特别如果是不同办公场地的跨团队，情况更甚。
但是使用平台会有什么样的效果呢？
- 团队间的“承诺”（即接口版本）已经通过YAPI这类接口管理平台以可视化的，可被测试的方式固化到系统层面；
- 你可以看看前后端的信息流（上图的红色箭头），它不是单向的，他们是有个版本信息集散地的，一切以平台为准，而非以某个不知散落在某处的word文档为准；
那这样的话在人的潜意识里面就形成了一个
契约关系，也在无形中推动了组员间通过平台去承载这些所谓的契约，
这样的话接口的改动（起码是接口字段、通讯协议层面）就会在真正开发之前在团队间先明确清楚并“定义”在平台上，这也印证了我一直所认同的“工具能加速团队文化的形成”的观点。
2、方便自测，真正的前后端分离，真正的“解耦”
以前没有类似YAPI这样的接口管理平台，以前的前后端分离只是从系统架构和代码层面做了前后端分离，什么意思呢？就是说代码是可以分开来写了，不存在耦合，也不存在代码合并冲突。但是，在接口联调的时候，因为没有接口管理平台，很多时候前端如果开发进度较快的情况下，联调更多是自己简单写个mock程序在“自娱自乐”，功能非常有限，正因为功能有限，很多前端同事就有意识的配合后台去调整自己的接口开发的安排，尽量做到后台和前端的两边的接口都是差不多时间开发完，这样才开始实时联调，从这里你可以看出来，前后端的工作还是“强耦合”的。
但是引进这个平台后，因为接口字段配置、mock配置也相对比较简单，只要求后台开发人员按照之前的约定提前确定接口文档并部署到YAPI平台的话，前端人员就可以按照自己的节奏进行开发（当然前提还是重点接口优先开发以保证有足够时间测试），然后联调也可以通过YAPI平台做mock测试。
这才是真正的前后端分离，不单单是代码、架构层面的硬解耦，还有遵循康威定律从组织层面进行的软“解耦”。
3、每日构建（Daily build）的基础
前面我们一直在说团队内部前后端开发的协同优势，实际上这个不单单是只对前端同学有好处，这个平台也可以配合Jenkins进行集成以便支持自动化接口测试，妥妥的对服务端开发同学也是有好处，因为有了这个平台就可以进行具体的Daily build（每日构建）。具体可以参考我的另外一篇文章：
【DevOps】我们忽视了Daily Build（每日构建）吗？
后面我也会补充一下Jenkins集成YAPI进行自动化测试的文章。
4、“与时俱进”的接口文档
还是上面的图，大家可以看到因为所有的接口信息交互是通过接口管理平台承载的，因此只有有个开发人员的测试一有问题就可以快速排查出来是否接口版本问题，进而督促后台开发人员要快速把最新的接口更新到平台上去。
另外，类似YAPI这类平台可以支持导出Markdown、HTML这种比较丰富的接口文档格式，且还能支持不同格式的接口导入（如比较广泛使用的SWAGGER），可以支持：
-
历史项目接口文档迁移，通过平台进行管理，这样实际上就可以把SWAGGER和YAPI这两种工具有机结合，既不耽误高效方便的代码开发，又可支持接口版本的有效管理；
-
多种文档导出，用于常规的接口版本正式发布给到其他团队参考。
后话
相应的平台使用方法可以参考我另外的几篇文章，后面还在不断更新，例如目前正在整理与JENKINS的集成支持持续集成。
6348
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
