关于接口开发和联调的一些感想

最近项目上在作销售订单、预付款申请、贸易合同传输OA审批等功能，也经历到了本身遇到过的最糟糕的接口联调。SAP与泛微OA之间的对接有比较成熟的方案，咱们的工做过程不顺利，终究是人的缘由。我想把本身的一些见解记录下来，留做教训。

内部名仍是外部名？

不一样系统间的接口开发工做中的一个难点是接口提供者和被调用者对接口的不一样理解。一样的一个概念，在不一样系统中可能有不一样的名称；一样的一个名词，在不一样系统中又有可能有着不一样的意义。在理想状况下，肯定接口字段的定义和描述的人，应当对两个系统的领域语言有所了解，有能力找到其中的相同与不一样点，而且在相关的文档中作出准确的表述，让双方的参与人员理解本身的意图。

在现行的接口开发流程下，一般会由SAP业务顾问和对接系统的相关负责人来肯定接口字段的名称和意义，而SAP业务顾问在这当中又起着主导性的做用。实际上，SAP业务顾问有着丰富的业务和系统知识，理论上是有能力处理好相关工做的。但在实践当中，很多业务顾问彷佛对本身的工做尚未足够的认识，所以人们看到的文档是相似这样的：

假如读者是熟悉SAP系统的人，可能会知道：SUPERFIELD是采购订单相关事务屏幕中的一个抬头字段，它时而对应供应商，时而对应工厂等内容；NAME2，NAME3来自于NAME1，它是SAP系统主数据表中的常见字段名，意为名称；BUKRS大概来自于“公司代码”的德文写法，也是SAP系统中公司代码的技术名称。

这样的文档，即使目标人群是SAP系统的开发者，也不是彻底合适。好比供应商在SAP中的技术名称一般是LIFNR，所谓SUPERFIELD，是一个意义不明的通用名称，容易给读者带来困惑。

而在SAP与非SAP接口的开发中，这样的文档是不太合格的。显然一个非SAP系统的技术人员，没有义务懂得SUPERFIELD和BUKRS的名字来源，所以在接口中应当使用字段的外部名，而非内部名。若是要传递正确的信息给人们，尽可能减小误解，应该采用以下的比较合理的定义方式：

一个有经验的SAP开发者十分清楚VENDOR即SAP中的LFA1-LIFNR，COMPANY即T001-BUKRS。一个非SAP系统的开发者大概也能看懂这几个词的意思。这样一来，产生误会的可能性就下降了，思考的负担也下降了。由于没有人须要再死记硬背“NAME3”的含义。

 

名与实

“名不符实”是全社会共同面对着的难题，在开发工做中也不例外。我开发的某个接口中存在一个字段NETWR1，原本的意义是“净值”（Net Value），在一次口头需求变动后，它变成了“总值”（Gross Value），但接口文档依然保持着以下模样：

我很但愿文档的撰写者能够对它的字段名、描述、长度作出合理的修改，也对她作出了建议。可是个人愿望最终被忽视了，理由是工期紧，而且我“没有准确理解需求”。

需求文档是人们理解系统中自定义业务逻辑的重要依据，若是需求文档中存在大量的名不符实的东西，那么一段时间过去后人们只能从代码中考古，理解前人的工做了。

比较有趣的是，最不喜欢撰写可靠文档的人，同时也每每是最喜欢要求“来个开发，帮我debugger一段代码，看看这些程序到底在作什么”的人。从这个角度看，他们无愧是提升ABAP开发人员就业率的功臣...

联调的前提

良好的工做流程和良好的的程序同样，能够清晰的让人明白一段行为什么时开始、什么时候结束。

这里的“时”指的应当是时机和非时间，即它不是一个单纯的时间点，而是一个结合了条件的时间点...

对接口联调的工做而言，我认为，存在一个基本的前提条件，那就是接口已经经过测试。

接口联调的重要目的是发现问题、解决问题。解决问题的前提是定位问题，而定位问题的区域范围越小，就越容易用较小的成本解决问题。

若是接口联调时，双方的程序都处于一种极为不肯定的状态，那么联调中必定会暴露大量问题，且须要密切和低效率的沟通来肯定问题发生在哪一方。两个不肯定的程序交织在一块儿。而这两份不肯定，又给整个联调带来了更多额外的不肯定..原本是用于调试接口自己的问题的时间，可能会被天马行空找bug的过程占用。

在这个项目当中，有的接口开发人员甚至没有使用Postman或者SoapUI之类的工具对本身的接口作最基本的测试，而调用接口的代码，在联调时竟然经常没有完成，须要现场编写..编写时又发现提供的接口与文档不一致等状况。使人无言已对。

明确角色

在接口相关项目中，可能涉及的角色包括业务分析人员、开发人员、测试人员、运维工程师、产品经理、架构师、项目经理等。尽管在实际工做当中，可能有一我的身兼数个角色的状况存在，咱们依然有必要明确每一个人的角色、每一个角色的的工做内容和责任范围。

若是仅仅以完成工做为目标，而忽视了参与人员的角色，容易形成信息的错误传达和项目混乱：一些处于“中间地带”的工做分配会引发争议；项目有人员变更时，工做很难顺利接续；工做内容可能会变得依赖于有权力的人的指令，大部分参与者难以发挥本身的主观能动性；相关人员的观点存在矛盾、误解而不能及时消除，使得工做产物中存在缺陷。最终，每一个人都疲于奔命，却难取得较好的工做成果。

坊间经常流传一个佳话，故事中，某某员工能力很强，离职后，公司新招3我的来承接某某当初的工做，结果还不如某某作的好。这个故事可能存在另外一种解释：角色设置的混乱使得那位旧人承担了太多，新人们在承接这些工做时，角色依然是不明确的，此时人数的增长反而起到了反作用，致使他们没法产出与能力匹配的工做成果。

此外，在跨系统的接口开发中，参与人员须要注意各方对角色的设置和认知可能有所不一样，应该尽早明确这方面的差别，以避免形成误解。

等待时作什么

联调时会出现一种现象：一我的在改刚刚发现的问题，其它人则进入“事不关己”状态，开始聊天玩手机或者作其它工做。我以为这不是一个有益的现象。

在进入这样的状态以前，建议先按如下顺序作检查：

1. 发现的问题是否和接口联调有关，在不影响联调的前提下，可不能够将它记录到问题清单中，过后再改？
2. 在其它人作修改的时候，本身和其它参与联调但不须要改东西的人可不能够进行一些异步的工做，好比为联调中的下一项小工做作准备？
3. 能不能用电脑代替手机，来作本身想作的事情？

九我的等待一我的工做是一种低效的工做方式，而智能手机的出现甚至可能会下降那惟一一人的工做效率，让你们等待更久的时间。（参考 智能手机如何绑架了咱们的大脑，华尔街日报）。所以要尽可能避免这种状况发生。