不懂接口的程序员就不懂开发

开发人员的面试中，面试官经常会让你描述之前做过的一些项目，以及你在其中开发的部分。看似很简单，很多人就是讲不清楚，要么寥寥几句讲不清楚，要么东扯西凑不着重点。原因很简单，要么你不懂接口，要么你描述不清接口。

小白面试者：“我做过手机开发，最近一个项目是个在线订餐的APP，我做的用户下单，订单列表这块功能。”

资深面试官：“好，说说你是怎样从后台取一个用户的订单列表的。”

小白：“调一个函数。。。呃，就从后台取到数据。。。然后显示到页面上。”

资深：“调什么样的函数，它是怎么与后台通讯的？后台返回的数据是什么样子？”

小白：“调ajax，后台会返回一个数组。。。”

资深心想：“呵呵，啥叫后台返回数组，接口协议的过程完全不清楚。问问看接口原型能不能讲清楚。”，问：“数组的具体数据结构你能描述一下吗？”

小白：“就是一个变量。。。没有结构啊。。。”

资深（心想）：“捉急啊，数据类型也讲不清楚，真奇怪应用是怎么做出来的。。。”

一个表达良好且真实做过这块开发的程序员，应该有能力描述出细节：前端通过HTTP协议发出请求，调用这样的语句

$.get("api/queryOrder?status=1")

，可以用参数status表示只取指定状态的订单，后端返回JSON格式的数据，它表示是一个数组，数组每一项是个订单（Order类型），订单的属性有整型的id, 数值型的总价total等。

重点抓到了吗？首先他是大体知道通讯协议（HTTP/JSON等），并且可以详细描述出怎样调用后台；其次，对这次调用，他可以清楚的描述出了参数和返回值的类型、含义这些细节，对原型有一定描述能力。

而他可能对HTTP协议的细节不太了解。如果是个爱钻研或资深些的开发，可以把HTTP协议交互的细节讲清楚：

前端以HTTP GET方式向后端发出请求，发送请求像这样：

GET api/queryOrder?status=1

其中，应用层定义网址中，queryOrder是调用名，status是调用函数，参数通过urlencoded方式传递。后端成功时返回数据像这样：

200 OK

[{id:1, dscr:"order 1", total:100}, {id:2, dscr:"order 2", status:1}]

能说到这个程度，接口协议这一块已经很懂了。如果再遇到抽象能力强的，会直接写出形式化的接口原型，像这样：

queryOrder(status) -> [ {id, dscr, total} ]

那么这已经是精通前后端通讯的架构师水平了。

看到这里，新手会若有所思，但还是不禁要问，“到底啥叫接口？是Java里面那个Interface关键字吗？”没错，接口的英文是Interface。不过它不局限于是一个关键字，而是一组设计思想：

把待开发对象的接口理清楚，就决定了你对需求的理解程度和设计方案的方向正确性，其实就是需求分析和概要设计，它也同时决定了测试设计的质量。

把对象的内部接口理清楚（划分模块，理清它们之间的交互），决定了方案的实现，其实就是详细设计和编码的工作。

代码写乱了，已经难以理解了，这时要使用接口分离，这叫重构。

怎样才能把接口描述清楚呢？描述接口有两个重点，称为2P：一是协议（Protocol），二是原型（Prototype），它们分别描述了交互的方式与内容。协议说的是，调用方和被调用方是怎样交互的，比如基于HTTP协议，请求参数用urlencoded格式，返回内容用JSON格式；原型描述的是一个请求的内容，调用名称，参数和返回内容是什么含义，以及类型。

大到软件工程，小到编写个去后台获取订单列表的函数，多半的时间都花在确定接口和实现接口上。

下一节，我再和大家聊聊各种接口以及每种接口的表示。