概述
本周先后进行了两个业务系统的对接工作，虽然不是直接负责开发，但也耗费了不少的精力，好在进度符合预期，本篇论文就结合业务系统对接这个点分享一下粗陋的经验，也当做记录了，同时为了下周在团队的分享提前预热。
有关对接的错误假设
1.对接方了解要对接的事
有几次我联系要对接的技术人员要沟通对接的细节时，对方都是一脸懵逼的反应，你是谁啊，联系我做什么，这是不归我管，好吧我去问问。
2.负责对接的技术人员拥有实现对接所需要的技术能力
有一次我跟一个对接方沟通一个系统监控信息获取的问题，需要获取底层的硬件信息，所以需要使用STMP协议，结果对接方找了个技术人员没有听过STMP，没办法也协调不动，就把STMP相关的测试和开发资料发了过去，人家也是挺给力，现学现用，几经周折终于通了，但进度已经远远落后于预期了。
3.对接方十分愿意完成对接这个工作
这个也遇到过不少次，尤其是行业内的，对接方总是对于我们的呼声带搭不理，最后不得已协调了他们客户的上级单位才开始了对接工作，结果十分简单的对接拖了很长很长时间，弄得我方用户很是无奈和崩溃。
上面的问题都不是技术层面的，在对接这个事情上，技术真的往往不是主要的。
对接要点
- 在对接进入到实质性阶段后，双方沟通交流一定要带着技术人员，并组建联系群，否则就是双方牛没少吹，但对接工作却迟迟没进展
- 尽早对接和磋商，有疑问一定要提出来
- 提前做对接工作，大多数人都喜欢做选择题，所以在对接前要做好调研，最好弄几套对接方案，对方一看有了现成方案，只要不是太离谱就会采纳，这样后面的开发就主动的多
- 最有一定要有对齐和接口文档发布的过程，以邮件的形式留底，并要确认
- 不要太指望文档 ，就算有了文档在开发过程中最好也要经常确认
- 尽早建立测试条件，只是Stub也比没有好一万倍
- 接口的设计一定要谨慎，对方系统的事情尽量少知道，能采用Restful就不采用rpc或中间件，共享数据库什么的能不用就不用
- 如果不得不采用WebService等强耦合技术，那就将对接部分分离出来
接口设计的一些不错资料
- opensource.zalando.com/restful-api…
- www.infoq.com/presentatio…
- www.vinaysahni.com/best-practi…
- betimdrenica.wordpress.com/2015/03/09/…
- github.com/interagent/…
- github.com/Microsoft/a…
上面大部分资料转自极客时间的《左耳听风专栏》
