面试中初级程序员常常遇到的问题—— 描述你做过的项目

时间:2021-12-22 12:00:04

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

小白面试者:“我做过手机开发,最近一个项目是个在线订餐的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格式;原型描述的是一个请求的内容,调用名称,参数和返回内容是什么含义,以及类型。

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

转载:http://blog.csdn.net/skyshore/article/details/50995163