開發人員的面試中,面試官經常會讓你描述之前做過的一些專案,以及你在其中開發的部分。看似很簡單,很多人就是講不清楚,要麼寥寥幾句講不清楚,要麼東扯西湊不著重點。原因很簡單,要麼你不懂介面,要麼你描述不清介面。

小白麵試者:“我做過手機開發,最近一個專案是個線上訂餐的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