面試中初級程式設計師常常遇到的問題—— 描述你做過的專案

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

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