




版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領
文檔簡介
代碼大全精粹——個人整理版本目錄設計編碼質量優(yōu)化設計設計關鍵點1.封裝——信息隱藏類或模塊,只提供合適的接口,并保持不變。實現(xiàn)細節(jié)和成員不要暴露給外界即其他模塊。反例:
pDomain=&(g_AAADomain[DomainID]);if(READY==pDomain->Status){…}正例:if(DomainIsReady(DomainID)){…}設計關鍵點封轉的好處:a.降低耦合。尤其是大模塊之間。b.降低復雜度。修改和閱讀代碼時,一個時刻只用關心一層的設計,不用在龐大的代碼中左支右絀。c.屏蔽變化源。例如某數(shù)據(jù)索引表從Hash表改成AVL樹,不應對外部產生影響,封裝可實現(xiàn)這種屏蔽。Notice:
封裝不僅應該用在大模塊上,也應該用在模塊內的各子模塊上。C語言中不希望被外部調用的函數(shù),可通過函數(shù)名前加static前綴來實現(xiàn)信息隱藏設計關鍵點設計關鍵點2.隔離容易改變的區(qū)域找出明顯容易變化的功能,將之分離出來成獨立模塊。設計良好接口,使變化不影響模塊外部。容易變化的地方:a.業(yè)務規(guī)則。例如電話費、上網費的收費模式、費率等。b.硬件依賴性c.困難的設計區(qū)域和實現(xiàn)區(qū)域。因為這些設計和代碼不是很好,可能需要重新做。隔離使之對系統(tǒng)影響最低。舉例:請教練結合自己項目舉例設計關鍵點3.抽象抽象是從眾多的事物中抽取出共同的、本質性的特征,而舍棄其非本質的特征。抽象本身很“抽象”,不太容易理解。我們來通過軟件實例理解:C++項目中的抽象類C項目中的通用算法庫,例如Hash,就是抽象出了Hash算法的本質,而把具體的“雜湊函數(shù)”留給使用者注冊。請教練結合自己項目舉例設計關鍵點抽象的好處:關注高層規(guī)則,忽略無關細節(jié),降低軟件復雜度寫出高復用性代碼更好的軟件層次結構Notice:
抽象與語言無關,C語言同樣可實現(xiàn)抽象。編碼子程序和變量名子程序長度
無標準。但超過200行請小心,一般只有復雜算法(如AVL樹,加密等)才會寫出長函數(shù),其余情況出現(xiàn)長函數(shù)則要反省設計、分層是否合理。一個子程序只在自己的抽象層次上做一件事情。如果一個子程序的名字無法完全描述它做的事,就違背了這一原則。子程序和變量的名字:
總原則是讓代碼讀起來就跟自然語言一樣流暢。例如if(NameIsValid(userName)){
RemoveAllSpace(userName)…}子程序和變量名過程性子程序起強烈的“動詞+賓語”的名字,例如RemoveAllSpace()等。邏輯判斷子程序,名字寫為肯定語句。
面向對象例子:boolCLASS_USER_NAME::IsValidName();C語言例子:BOOLNameIsValid(&userName);
使用時就是如下流暢的語句:if(userName.IsValidName())或if(!userName.IsValidName())if(NameIsValid(&userName))語句1.循環(huán)循環(huán)變量使用有意義的變量名,避免習慣性使用i,j,k反例:for(i=0;i<MAX_USER_ID;i++){for(j=0;j<MAX_PAYOUT_TYPE;i++){sum+=employee[i].payout[j];}}正例for(userID=0;userID<MAX_USER_ID;userID++){for(payType=0;payType<MAX_PAYOUT_TYPE;payType++){sum+=employee[userID].payout[payType];}}好處:提高可讀性避免i,j,k寫代碼手誤設計關鍵點語句2.判斷語句判斷語句盡量寫為肯定形式,少用==判斷反例:if(TRUE==procResult){….}正例:if(procSuccess){….}好處:接近自然語言,提高可讀性;避免==手誤為=設計關鍵點語句語句3.克服深層嵌套一份研究表明,很少有人能理解超過三層的嵌套。當寫出深層嵌套時,如何改進?方法一:重新梳理判斷邏輯,重新設計被嵌套的代碼。某些情況下深層嵌套是混亂思路的產物。方法二:把深層嵌套的代碼提取出來放進單獨的子程序。只要提取的代碼是一個完整、獨立的概念。注釋1.盡量寫出“自說明代碼”盡量讓代碼像自然語言一樣流暢,即使不用注釋也能輕松看懂。通過好的子程序名、變量名、良好邏輯分層、清晰布局、低復雜度的控制流程和數(shù)據(jù)結構等實現(xiàn)該目標。2.注釋只允許有如下三類:1)概述性注釋。說明某一段代碼的總體意思。例如一個子程序中,各功能段的概述說明。2)目的性注釋。說明一段代碼的意圖,要解決的問題,而非解決的方法。例如函數(shù)頭的函數(shù)功能說明3)說明代碼無法表述的信息。例如與設計有關的注意事項,優(yōu)化標記等。其他類型的注釋,要么是無用的,重復說明代碼本身已經明白無誤的內容;要么說明代碼本身含糊不清,必須要另外說明,這種情況下最好改進代碼。
這是理想情況。在現(xiàn)有代碼無法達到自說明的情況下,還是要將理解有困難的地方都進行注釋。注釋質量優(yōu)化降低程序復雜度1.什么是程序復雜度程序復雜度的一個標準:為了理解應用程序,你必須在同一時間記住的智力實體的數(shù)量直觀標準:理解程序所需要花費的精力。復雜度代表什么?復雜度與程序可靠性成反比,與程序錯誤率成正比。復雜度高的代碼可讀性差,難以理解2.如何度量復雜度TomMcCabe方法:通過子程序中“決策點”來數(shù)量衡量復雜度。1.從1開始,一直往下通過程序2.一旦遇到以下關鍵字,或者其同類的詞,就加1:if,while,repeat,for,and,or3.給case語句中的每一種情況都加1例子:如下子程序復雜度為多少?
int
firstNum(inta,intc){for(b=0;b<MAX_NUM;b++){if(a<b&&b<c){returnb;}}}降低程序復雜度4降低程序復雜度3.如何處理復雜度度量結果0-5子程序可能還不錯6-10得想辦法簡化子程序10+把子程序的某一部分拆分成另一個子程序并調用它把子程序的一部分提取成另一個子程序,不會降低整個程序的復雜度,只是把決策點移到其他地方。但這樣可以降低你在同一時間必須關注的復雜度水平。有時混亂的代碼是混亂思維的產物,這種情況需要重新整理出清晰的函數(shù)邏輯。(這條是我個人的總結)10的上限不是絕對,只是一個警示。有些情況下子程序高復雜度不可避免。開發(fā)者測試1.什么是開發(fā)者測試完整測試過程:單元測試、組件測試、集成測試、回歸測試、系統(tǒng)測試。開發(fā)者測試主要指前三項:單元測試:類或子程序測試組件測試:也就是我們的模塊測試集成測試:多模塊的聯(lián)合測試2.推薦的測試項對每一項相關需求進行測試對每一個相關設計關注點進行測試典型數(shù)據(jù)、邊界數(shù)據(jù)、錯誤數(shù)據(jù)測試舉例:四則運算程序,請大家給出測試項。開發(fā)者測試3.推薦的測試方法測試先行保留測試用例,用于后續(xù)重新測試(回歸測試)自動化測試,使測試可快速、頻繁進行。例如測試用例函數(shù)中使用Assert判斷結果,而非打印出來肉眼觀察。開發(fā)者測試重構重構的定義:在不改變軟件外部行為的前提下,對其內部結構進行改變,使之更容易理解并便于修改。問題:何處需要重構,怎么重構?1.何處需要重構,怎么重構這里只說明幾種常見類型重復。代碼重復、結構重復、邏輯重復。重復的代碼是抽象不夠的表現(xiàn)。如果是一個獨立完整的概念,可以提取成一個子程序(抽象)。舉例:多處的排序算法。冗長子程序。如果把子程序的一部分提取來作為另一個獨立的子程序,可以讓代碼更清晰,就提取成子程序。循環(huán)過長或嵌套過深。循環(huán)內部的復雜代碼往往可以轉換成子程序。嵌套過深可以用前面“語句”中提過的方法解決。子程序命名不當。需要子程序重命名,或合并、拆分子程序。難懂、拙劣的代碼。需要重整邏輯和流程。問題:何時進行重構?重構2.重構的時機開發(fā)時,不斷重構。在開發(fā)階段,每完成一個小功能點、或修補一個缺陷時,都應該審視是否有需要重構的地方,保證持續(xù)集成中代碼不腐化。維護時,因故障或需求變化而修改某功能時,對修改到的代碼進行重構。但注意只能重構修改的地方!不能在解決故障時重構與之無關的代碼!問題:如何保證重構安全?這可能是阻礙我們進行重構的最大因素!重構3.如何保證重構安全重構前保存初始代碼,保證重構失敗可以返回。重構的步伐要小。盡量一次只處理一項重構,除非是最為簡單的重構。重新測試(回歸測試)。開發(fā)者自測階段請保留測試用例,最好是自動化測試用例,可以迅速重新測試,看重構后的代碼能否通過之前的測試用例。重構性能優(yōu)化1.性能優(yōu)化誤區(qū)隨時隨地進行優(yōu)化
為微觀的最終效果不足道的優(yōu)化,可能浪費了大量的時間,而對整個系統(tǒng)全局性的重要優(yōu)化視而不見。同時也為了微弱的性能提升而犧牲了正確性、可讀性等其他重要的軟件質量。優(yōu)化=修改代碼
遍歷查找數(shù)據(jù)的代碼,再怎么修改優(yōu)化,也不可能超越Hash查找算法、AVL樹查找算法——優(yōu)化需要先從更高層的需求、設計做起!2.什么是真正的優(yōu)化按如下的優(yōu)先順序來思考提高性能:需求設計程序同操作系統(tǒng)交互代碼編譯硬件代碼調整首先從需求、設計、編譯器優(yōu)化等級、硬件等上面提高效率,可以更全局、簡單、安全、高效地提高效率。最后才是考慮代碼
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
- 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
- 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 介紹考試形式的2025年網絡規(guī)劃設計師試題及答案
- 初級社會工作者考試強化練習試題及答案
- 高考語文模擬試題及答案
- 多媒體應用設計師考試的新方法試題及答案
- 電梯維修證考試題及答案
- 云南數(shù)學中考試題及答案
- 多媒體應用設計師考試的多樣性試題及答案
- 備考周期2025年網絡規(guī)劃設計師考試試題及答案
- 2025年設計師考試聯(lián)系試題解析
- 開發(fā)前期部門管理制度
- 【MOOC】模擬電子電路實驗-東南大學 中國大學慕課MOOC答案
- 人教版七年級下冊生物期末試卷
- GB 12476.2-2006可燃性粉塵環(huán)境用電氣設備第1部分:用外殼和限制表面溫度保護的電氣設備第2節(jié):電氣設備的選擇、安裝和維護
- 國家開放大學《金融法規(guī)》章節(jié)自測練習參考答案
- 《言語治療技術》考試復習題庫(含答案)
- 外墻體抹灰工藝技術控制方框圖
- 國軍標體系之公司質量目標(重要)
- DCS系統(tǒng)調試步驟
- JJF(津) 54-2021 液體流量計在線校準規(guī)范
- 關于進一步厲行節(jié)約推行無紙化辦公的通知
- 職業(yè)生涯規(guī)劃外文翻譯文獻
評論
0/150
提交評論