面試官是根據(jù)應(yīng)聘者寫出的代碼來決定是否錄用一個(gè)應(yīng)聘者的。應(yīng)聘者首先要把代碼寫得規(guī)范，才可以避免很多低級錯(cuò)誤。如果代碼寫得不夠規(guī)范，會(huì)影響面試官閱讀代碼的興致，至少印象分會(huì)打折扣。書寫、布局和命名都決定著代碼的規(guī)范性。

　　規(guī)范的代碼書寫清晰。絕大部分面試都要求應(yīng)聘者在白紙或者白板上書寫。由于現(xiàn)代人已經(jīng)習(xí)慣了敲鍵盤打字，手寫變得越發(fā)不習(xí)慣，因此寫出來的字潦草難辨。雖然應(yīng)聘者沒有必要為了面試特意去練字，但在面試過程中減慢寫字速度、盡量把每個(gè)字母寫清楚還是很有必要的。不用擔(dān)心沒有時(shí)間去寫代碼。通常編程面試的代碼量都不會(huì)超過50行，書寫不用花多少時(shí)間，關(guān)鍵是在寫代碼之前形成清晰的思路并能把思路用編程語言清楚地書寫出來。

　　規(guī)范的代碼布局清晰。平時(shí)程序員在集成開發(fā)環(huán)境如Visual Studio里面寫代碼，依靠專業(yè)工具調(diào)整代碼的布局，加入合理的縮進(jìn)并讓括號對齊成對呈現(xiàn)。離開這些工具，應(yīng)聘者就要格外注意布局問題。當(dāng)循環(huán)、判斷較多邏輯較復(fù)雜時(shí)，縮進(jìn)的層次可能比較多。如果布局不夠清晰，縮進(jìn)也不能體現(xiàn)體現(xiàn)代碼的邏輯，這樣的代碼將會(huì)讓人頭暈?zāi)X脹。

　　規(guī)范的代碼命名合理。很多初學(xué)編程的人在寫代碼時(shí)總是習(xí)慣用最簡單的名字來命名，變量名是i、j、k，函數(shù)名是f、g、h。由于這樣的名字不能告訴讀者對應(yīng)的變量或者函數(shù)的意義，代碼一長就會(huì)變得非常晦澀難懂。強(qiáng)烈建議應(yīng)聘者在寫代碼時(shí)，用完整的英文單詞組合命名變量和函數(shù)，比如函數(shù)需要傳入一個(gè)二叉樹的根結(jié)點(diǎn)作為參數(shù)，則可以把該參數(shù)命名為BinaryTreeNode* pRoot。不要因?yàn)檫@樣會(huì)多寫幾個(gè)字母而覺得麻煩。如果一眼能看出變量、函數(shù)的用途，應(yīng)聘者就能避免自己搞混淆而犯一些低級的錯(cuò)誤。同時(shí)合理的命名也能讓面試官一眼就能讀懂代碼的意圖，而不是讓他去猜變量到底是數(shù)組中的最大值還是最小值。

　　在面試的過程中，面試官會(huì)非常關(guān)注應(yīng)聘者考慮問題是否周全。面試官通過檢查代碼是否完整來考查應(yīng)聘者的思維是否全面。通常面試官會(huì)檢查應(yīng)聘者的代碼是否完成了基本功能、輸入邊界值是否能得到正確的輸出、是否對各種不合規(guī)范的非法輸入做出了合理的錯(cuò)誤處理。

　　應(yīng)聘者在寫代碼之前，首先要把可能的輸入都想清楚，從而避免在程序中出現(xiàn)各種各樣的質(zhì)量漏洞。也就是說在編碼之前要考慮單元測試。如果能夠設(shè)計(jì)全面的單元測試用例并在代碼中體現(xiàn)出來，那么寫出的代碼自然也就是完整正確的了。通常程序員可以從功能測試、邊界測試和負(fù)面測試三方面設(shè)計(jì)測試用例，以確保代碼的完整性。

　　首先要考慮的普通功能測試的測試用例。應(yīng)聘者首先要保證寫出的代碼能夠完成面試官要求的基本功能。比如面試題要求完成的功能是把字符串轉(zhuǎn)換成整數(shù)，應(yīng)聘者就可以考慮輸入字符串“123”來測試自己寫的代碼。這里要把零、正數(shù)（比如123）和負(fù)數(shù)（比如-123）都考慮進(jìn)去。

　　考慮功能測試時(shí)，應(yīng)聘者要盡量突破常規(guī)思維的限制，避免忽視某些隱含的功能需求。比如“打印從1到最大的n位數(shù)”，很多人覺得很簡單。最大的3位數(shù)是999、最大的4位數(shù)是9999。這些數(shù)字很容易就能算出來。但最大的n位數(shù)都能用int型表示嗎？如果超出int的范圍可以考慮long long類型。超出long long能夠表示的范圍呢？面試官是不是要求考慮任意大的數(shù)字？如果面試官確認(rèn)題目要求的是任意大的數(shù)字，那么這個(gè)題目就是一個(gè)大數(shù)問題。此時(shí)需要特殊的數(shù)據(jù)結(jié)構(gòu)來表示數(shù)字，比如用字符串或者數(shù)組來表示大的數(shù)字，才能確保不會(huì)溢出。

　　其次需要考慮各種邊界值的測試用例。很多代碼都包含有循環(huán)或者遞歸。如果代碼是基于循環(huán)，那么結(jié)束循環(huán)的邊界條件是否正確？基于循環(huán)的代碼要特別注意開區(qū)間和閉區(qū)間的使用（也就是區(qū)分<與<=、>與>=）。如果代碼是基于遞歸，遞歸終止的邊界值是否正確？這些都是邊界測試時(shí)要考慮的用例。還是以字符串轉(zhuǎn)換成整數(shù)的問題為例，應(yīng)聘者寫出的代碼應(yīng)該確保能夠正確轉(zhuǎn)換最大的正整數(shù)和最小的負(fù)整數(shù)。

　　再次還需要考慮各種可能的錯(cuò)誤的輸入，也就是負(fù)面測試的測試用例。應(yīng)聘者寫出的函數(shù)除了要順利地完成要求的功能之外，當(dāng)輸入不符合要求時(shí)，面試官還希望他能做出合理的錯(cuò)誤處理。在設(shè)計(jì)把字符串轉(zhuǎn)換成整數(shù)的函數(shù)時(shí)，應(yīng)聘者就要考慮當(dāng)輸入的字符串不是一個(gè)數(shù)字，比如“1a2b3c”，怎么告訴函數(shù)的調(diào)用者這個(gè)輸入是非法的。

　　前面討論的都是要全面考慮當(dāng)前需求對應(yīng)的各種可能輸入。在軟件開發(fā)過程中，永遠(yuǎn)不變的就是需求會(huì)一直改變。如果應(yīng)聘者在面試時(shí)寫出的代碼能夠把將來需求可能的變化都考慮進(jìn)去，在需求發(fā)生變化時(shí)能夠盡量減少代碼改動(dòng)的風(fēng)險(xiǎn)，那他就向面試官展示了自己對程序可擴(kuò)展性和可維護(hù)性的理解，必定能得到面試官的青睞。如果應(yīng)聘者在解答面試題“調(diào)整數(shù)組順序使奇數(shù)位于偶數(shù)前面”時(shí)能夠考慮可擴(kuò)展性，他寫出的代碼不僅僅只是解決調(diào)整奇數(shù)和偶數(shù)的問題，還能考慮到把調(diào)整數(shù)字順序的功能和判斷一個(gè)數(shù)字是奇數(shù)還是偶數(shù)的功能解耦。這樣當(dāng)今后需求功能擴(kuò)展要求解決類似的問題，比如調(diào)整負(fù)數(shù)和非負(fù)數(shù)的順序、調(diào)整能被3整除的數(shù)字和不能被3整除的數(shù)字的順序，只需要添加很少的代碼都能做到，于是提高了代碼的可擴(kuò)展性和可維護(hù)性。

　　通常有三種方式把錯(cuò)誤信息傳遞給函數(shù)調(diào)用者。

　　函數(shù)用返回值來告知調(diào)用者是否出錯(cuò)。比如很多Windows的API就是這個(gè)類型。Windows中很多API的返回值為0表示API調(diào)用成功，而返回值不為0表示在API調(diào)用的過程中出錯(cuò)了。微軟為不同的非零返回值定義了不同的意義，調(diào)用者可以根據(jù)這些返回值判斷出錯(cuò)的原因。這種方式最大的問題是使用不便，因?yàn)楹瘮?shù)不能直接把計(jì)算結(jié)果通過返回值直接賦值給其他變量，同時(shí)也不能把這個(gè)函數(shù)計(jì)算的結(jié)果直接作為參數(shù)傳遞給其他函數(shù)。

　　當(dāng)發(fā)生錯(cuò)誤時(shí)設(shè)置一個(gè)全局變量。此時(shí)可以在返回值中傳遞計(jì)算結(jié)果了。這種方法比第一種方法使用起來更加方便，因?yàn)檎{(diào)用者可以直接把返回值賦值給其他變量或者作為參數(shù)傳遞給其他函數(shù)。Windows的很多API運(yùn)行出錯(cuò)之后，也會(huì)設(shè)置一個(gè)全局變量。函數(shù)調(diào)用者可以通過調(diào)用函數(shù)GetLastError分析這個(gè)表示錯(cuò)誤的全局變量從而得知出錯(cuò)的原因。但這個(gè)方法有個(gè)問題：調(diào)用者很容易就會(huì)忘記去檢查全局變量，因此在調(diào)用出錯(cuò)時(shí)忘記做相應(yīng)的錯(cuò)誤處理，從而留下安全隱患。

　　異常。當(dāng)函數(shù)運(yùn)行出錯(cuò)時(shí)，程序就拋出一個(gè)異常。程序員可以根據(jù)不同的出錯(cuò)原因定義不同的異常類型。因此函數(shù)的調(diào)用者可以根據(jù)異常的類型就能知道出錯(cuò)的原因，從而可以做相應(yīng)的處理。另外，由于顯式劃分了程序正常運(yùn)行的代碼塊（try模塊）和處理異常的代碼塊（catch模塊），代碼的邏輯比較清晰。異常在高級語言如C#中是強(qiáng)烈推薦的錯(cuò)誤處理方式，但有些早期的語言比如C語言還不支持異常。另外，當(dāng)拋出異常時(shí)，程序的執(zhí)行會(huì)打亂正常的順序，對程序的性能有很大的影響。

　　上述三種錯(cuò)誤處理的方式各有優(yōu)缺點(diǎn)。那么面試時(shí)應(yīng)聘者該采用哪種方式呢？這要看面試官的需求。在聽到面試官的題目之后，應(yīng)聘者要盡快分析出可能存在哪些非法輸入，并和面試官討論該如何處理這些非法輸入。和面試官進(jìn)行這樣的討論對應(yīng)聘者是有益的，因?yàn)槊嬖嚬贂?huì)覺得他對錯(cuò)誤處理有著全面的了解，并且還會(huì)覺得他有很好的溝通能力。

　　魯棒性是指程序能夠判斷輸入是否合乎規(guī)范要求，并對不合要求的輸入予以合理的處理。容錯(cuò)性是魯棒性的一個(gè)重要體現(xiàn)。不魯棒的軟件在發(fā)生異常事件時(shí)，比如用戶輸入錯(cuò)誤的用戶名、試圖打開的文件不存在或者網(wǎng)絡(luò)不能連接，就會(huì)出現(xiàn)不可預(yù)見的詭異行為，或者干脆整個(gè)軟件崩潰。這樣的軟件對于用戶而言，不亞于一場災(zāi)難。

　　由于魯棒性對軟件開發(fā)非常重要，面試官在招聘時(shí)對應(yīng)聘者寫出的代碼是否魯棒也非常關(guān)注。提高代碼的魯棒性的有效途徑是進(jìn)行防御性編程。防御性編程是一種編程習(xí)慣，是指預(yù)見在什么地方可能會(huì)出現(xiàn)問題，并為這些可能出現(xiàn)的問題制定處理方式。

　　在面試時(shí)，最簡單也最實(shí)用的防御性編程就是在函數(shù)入口添加代碼以驗(yàn)證用戶輸入是否符合要求。通常面試要求的是寫一兩個(gè)函數(shù)，應(yīng)聘者需要格外關(guān)注這些函數(shù)的輸入?yún)?shù)。如果輸入的是一個(gè)指針，那指針是空指針怎么辦？如果輸入的是一個(gè)字符串，那么字符串的內(nèi)容為空怎么辦？如果應(yīng)聘者能把這些問題都提前考慮到，并作相應(yīng)的處理，那么面試官就會(huì)覺得他有防御性編程的習(xí)慣，能夠?qū)懗鲷敯舻能浖?/div>