提高代碼質(zhì)量的三要素_第1頁
提高代碼質(zhì)量的三要素_第2頁
提高代碼質(zhì)量的三要素_第3頁
提高代碼質(zhì)量的三要素_第4頁
提高代碼質(zhì)量的三要素_第5頁
已閱讀5頁,還剩4頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、提高面試代碼質(zhì)量的三要素作者: baiyuzhong 分類:管理   閱讀:7,387 次 添加評論作者總結(jié)自己多年面試他人以及被他人面試的經(jīng)驗,發(fā)現(xiàn)應聘者可以從代碼的規(guī)范性、完整性和魯棒性三個方面提高代碼的質(zhì)量。程序員在職業(yè)生涯中難免要接受編程面試。有些程序員由于平時沒有養(yǎng)成良好的編程習慣,在面試時寫出的代碼質(zhì)量不高,最終遺憾地與心儀的公司和職位失之交臂。因此,如何在面試時能寫出高質(zhì)量的代碼,是很多程序員關(guān)心的問題。 代碼的規(guī)范性面試官是根據(jù)應聘者寫出的代碼來決定是否錄用一個應聘者的。應聘者首先要把代碼寫得規(guī)范,才可以避免很多低級錯誤。如果代碼寫得不夠規(guī)范,會影響面試官閱

2、讀代碼的興致,至少印象分會打折扣。書寫、布局和命名都決定著代碼的規(guī)范性。規(guī)范的代碼書寫清晰。絕大部分面試都要求應聘者在白紙或者白板上書寫。由于現(xiàn)代人已經(jīng)習慣了敲鍵盤打字,手寫變得越發(fā)不習慣,因此寫出來的字潦草難辨。雖然應聘者沒有必要為了面試特意去練字,但在面試過程中減慢寫字速度、盡量把每個字母寫清楚還是很有必要的。不用擔心沒有時間去寫代碼。通常編程面試的代碼量都不會超過50行,書寫不用花多少時間,關(guān)鍵是在寫代碼之前形成清晰的思路并能把思路用編程語言清楚地書寫出來。規(guī)范的代碼布局清晰。平時程序員在集成開發(fā)環(huán)境如Visual Studio里面寫代碼,依靠專業(yè)工具調(diào)整代碼的布局,加入合理的縮進并讓括

3、號對齊成對呈現(xiàn)。離開這些工具,應聘者就要格外注意布局問題。當循環(huán)、判斷較多邏輯較復雜時,縮進的層次可能比較多。如果布局不夠清晰,縮進也不能體現(xiàn)體現(xiàn)代碼的邏輯,這樣的代碼將會讓人頭暈腦脹。規(guī)范的代碼命名合理。很多初學編程的人在寫代碼時總是習慣用最簡單的名字來命名,變量名是i、j、k,函數(shù)名是f、g、h。由于這樣的名字不能告訴讀者對應的變量或者函數(shù)的意義,代碼一長就會變得非?;逎y懂。強烈建議應聘者在寫代碼時,用完整的英文單詞組合命名變量和函數(shù),比如函數(shù)需要傳入一個二叉樹的根結(jié)點作為參數(shù),則可以把該參數(shù)命名為BinaryTreeNode* pRoot。不要因為這樣會多寫幾個字母而覺得麻煩。如果一眼

4、能看出變量、函數(shù)的用途,應聘者就能避免自己搞混淆而犯一些低級的錯誤。同時合理的命名也能讓面試官一眼就能讀懂代碼的意圖,而不是讓他去猜變量到底是數(shù)組中的最大值還是最小值。代碼的完整性在面試的過程中,面試官會非常關(guān)注應聘者考慮問題是否周全。面試官通過檢查代碼是否完整來考查應聘者的思維是否全面。通常面試官會檢查應聘者的代碼是否完成了基本功能、輸入邊界值是否能得到正確的輸出、是否對各種不合規(guī)范的非法輸入做出了合理的錯誤處理。三種測試用例確保代碼的完整性應聘者在寫代碼之前,首先要把可能的輸入都想清楚,從而避免在程序中出現(xiàn)各種各樣的質(zhì)量漏洞。也就是說在編碼之前要考慮單元測試。如果能夠設計全面的單元測試用例

5、并在代碼中體現(xiàn)出來,那么寫出的代碼自然也就是完整正確的了。通常程序員可以從功能測試、邊界測試和負面測試三方面設計測試用例,以確保代碼的完整性。· 首先要考慮的普通功能測試的測試用例。應聘者首先要保證寫出的代碼能夠完成面試官要求的基本功能。比如面試題要求完成的功能是把字符串轉(zhuǎn)換成整數(shù),應聘者就可以考慮輸入字符串“123”來測試自己寫的代碼。這里要把零、正數(shù)(比如123)和負數(shù)(比如-123)都考慮進去。 考慮功能測試時,應聘者要盡量突破常規(guī)思維的限制,避免忽視某些隱含的功能需求。比如“打印從1到最大的n位數(shù)”,很多人覺得很簡單。最大的3位數(shù)是999、最大的4位數(shù)是9999。這些數(shù)字很容

6、易就能算出來。但最大的n位數(shù)都能用int型表示嗎?如果超出int的范圍可以考慮long long類型。超出long long能夠表示的范圍呢?面試官是不是要求考慮任意大的數(shù)字?如果面試官確認題目要求的是任意大的數(shù)字,那么這個題目就是一個大數(shù)問題。此時需要特殊的數(shù)據(jù)結(jié)構(gòu)來表示數(shù)字,比如用字符串或者數(shù)組來表示大的數(shù)字,才能確保不會溢出。· 其次需要考慮各種邊界值的測試用例。很多代碼都包含有循環(huán)或者遞歸。如果代碼是基于循環(huán),那么結(jié)束循環(huán)的邊界條件是否正確?基于循環(huán)的代碼要特別注意開區(qū)間和閉區(qū)間的使用(也就是區(qū)分<與<=、>與>=)。如果代碼是基于遞歸,遞歸終止的邊界

7、值是否正確?這些都是邊界測試時要考慮的用例。還是以字符串轉(zhuǎn)換成整數(shù)的問題為例,應聘者寫出的代碼應該確保能夠正確轉(zhuǎn)換最大的正整數(shù)和最小的負整數(shù)。 · 再次還需要考慮各種可能的錯誤的輸入,也就是負面測試的測試用例。應聘者寫出的函數(shù)除了要順利地完成要求的功能之外,當輸入不符合要求時,面試官還希望他能做出合理的錯誤處理。在設計把字符串轉(zhuǎn)換成整數(shù)的函數(shù)時,應聘者就要考慮當輸入的字符串不是一個數(shù)字,比如“1a2b3c”,怎么告訴函數(shù)的調(diào)用者這個輸入是非法的。 前面討論的都是要全面考慮當前需求對應的各種可能輸入。在軟件開發(fā)過程中,永遠不變的就是需求會一直改變。如果應聘者在面試時寫出的代碼能夠把將來

8、需求可能的變化都考慮進去,在需求發(fā)生變化時能夠盡量減少代碼改動的風險,那他就向面試官展示了自己對程序可擴展性和可維護性的理解,必定能得到面試官的青睞。如果應聘者在解答面試題“調(diào)整數(shù)組順序使奇數(shù)位于偶數(shù)前面”時能夠考慮可擴展性,他寫出的代碼不僅僅只是解決調(diào)整奇數(shù)和偶數(shù)的問題,還能考慮到把調(diào)整數(shù)字順序的功能和判斷一個數(shù)字是奇數(shù)還是偶數(shù)的功能解耦。這樣當今后需求功能擴展要求解決類似的問題,比如調(diào)整負數(shù)和非負數(shù)的順序、調(diào)整能被3整除的數(shù)字和不能被3整除的數(shù)字的順序,只需要添加很少的代碼都能做到,于是提高了代碼的可擴展性和可維護性。三種錯誤處理的方法通常有三種方式把錯誤信息傳遞給函數(shù)調(diào)用者。·

9、 函數(shù)用返回值來告知調(diào)用者是否出錯。比如很多Windows的API就是這個類型。Windows中很多API的返回值為0表示API調(diào)用成功,而返回值不為0表示在API調(diào)用的過程中出錯了。微軟為不同的非零返回值定義了不同的意義,調(diào)用者可以根據(jù)這些返回值判斷出錯的原因。這種方式最大的問題是使用不便,因為函數(shù)不能直接把計算結(jié)果通過返回值直接賦值給其他變量,同時也不能把這個函數(shù)計算的結(jié)果直接作為參數(shù)傳遞給其他函數(shù)。 · 當發(fā)生錯誤時設置一個全局變量。此時可以在返回值中傳遞計算結(jié)果了。這種方法比第一種方法使用起來更加方便,因為調(diào)用者可以直接把返回值賦值給其他變量或者作為參數(shù)傳遞給其他函數(shù)。Win

10、dows的很多API運行出錯之后,也會設置一個全局變量。函數(shù)調(diào)用者可以通過調(diào)用函數(shù)GetLastError分析這個表示錯誤的全局變量從而得知出錯的原因。但這個方法有個問題:調(diào)用者很容易就會忘記去檢查全局變量,因此在調(diào)用出錯時忘記做相應的錯誤處理,從而留下安全隱患。 · 異常。當函數(shù)運行出錯時,程序就拋出一個異常。程序員可以根據(jù)不同的出錯原因定義不同的異常類型。因此函數(shù)的調(diào)用者可以根據(jù)異常的類型就能知道出錯的原因,從而可以做相應的處理。另外,由于顯式劃分了程序正常運行的代碼塊(try模塊)和處理異常的代碼塊(catch模塊),代碼的邏輯比較清晰。異常在高級語言如C#中是強烈推薦的錯誤處

11、理方式,但有些早期的語言比如C語言還不支持異常。另外,當拋出異常時,程序的執(zhí)行會打亂正常的順序,對程序的性能有很大的影響。 上述三種錯誤處理的方式各有優(yōu)缺點。那么面試時應聘者該采用哪種方式呢?這要看面試官的需求。在聽到面試官的題目之后,應聘者要盡快分析出可能存在哪些非法輸入,并和面試官討論該如何處理這些非法輸入。和面試官進行這樣的討論對應聘者是有益的,因為面試官會覺得他對錯誤處理有著全面的了解,并且還會覺得他有很好的溝通能力。代碼的魯棒性魯棒性是指程序能夠判斷輸入是否合乎規(guī)范要求,并對不合要求的輸入予以合理的處理。容錯性是魯棒性的一個重要體現(xiàn)。不魯棒的軟件在發(fā)生異常事件時,比如用戶輸入錯誤的用

12、戶名、試圖打開的文件不存在或者網(wǎng)絡不能連接,就會出現(xiàn)不可預見的詭異行為,或者干脆整個軟件崩潰。這樣的軟件對于用戶而言,不亞于一場災難。由于魯棒性對軟件開發(fā)非常重要,面試官在招聘時對應聘者寫出的代碼是否魯棒也非常關(guān)注。提高代碼的魯棒性的有效途徑是進行防御性編程。防御性編程是一種編程習慣,是指預見在什么地方可能會出現(xiàn)問題,并為這些可能出現(xiàn)的問題制定處理方式。在面試時,最簡單也最實用的防御性編程就是在函數(shù)入口添加代碼以驗證用戶輸入是否符合要求。通常面試要求的是寫一兩個函數(shù),應聘者需要格外關(guān)注這些函數(shù)的輸入?yún)?shù)。如果輸入的是一個指針,那指針是空指針怎么辦?如果輸入的是一個字符串,那么字符串的內(nèi)容為空怎

13、么辦?如果應聘者能把這些問題都提前考慮到,并作相應的處理,那么面試官就會覺得他有防御性編程的習慣,能夠?qū)懗鲷敯舻能浖?。當然并不是所有與魯棒性相關(guān)的問題都只是檢查輸入的參數(shù)這么簡單。應聘者看到問題時,要多問幾個“如果不那么”這樣的問題。比如面試題“鏈表中倒數(shù)第k個結(jié)點”,這里隱含著一個條件就是鏈表中結(jié)點的個數(shù)大于k。應聘者就要問自己如果鏈表中的結(jié)點不是大于k個,那么代碼會出什么問題?這樣的思考方式,能夠幫助發(fā)現(xiàn)潛在的問題并提前解決問題。這比事后讓面試官發(fā)現(xiàn)問題之后應聘者再去慌忙分析代碼查找問題的根源要好很多。小結(jié)本文從規(guī)范性、完整性和魯棒性三方面介紹了應聘者如何在面試時寫出高質(zhì)量代碼(如下圖所示)。第一,應聘者在白紙或者白板上手寫代碼時要注意規(guī)范性,盡量清晰地書寫每個字母,通過縮進和對齊括號讓代碼布局合理,同時還要合理命名代碼中的變量和函數(shù)。第二,應聘者最好在編碼之前全面考慮所有可能的輸入,確保寫出的代碼在完成了基本功能之外,還考慮了邊界條件,并做好了錯誤處理。只有全面考慮到這三方面的代碼才是完整的代碼。第三,應聘者要重視代碼的魯棒性,確保自己寫出的程序不會輕易崩潰。平時在寫代碼時,應聘者最好養(yǎng)成

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論