第二章--需求與設計評審V2_第1頁
第二章--需求與設計評審V2_第2頁
第二章--需求與設計評審V2_第3頁
第二章--需求與設計評審V2_第4頁
第二章--需求與設計評審V2_第5頁
已閱讀5頁,還剩64頁未讀 繼續免費閱讀

下載本文檔

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

文檔簡介

1、第第2章章 需求、設計代碼評審需求、設計代碼評審2需求、設計代碼評審需求、設計代碼評審-靜態測試靜態測試n 主要目標及內容:評審的方法與技術需求規格說明書的檢查系統結構與業務邏輯檢查代碼風格和規則檢查。本章內容本章內容2.1 軟件評審的方法與技術軟件評審的方法與技術2.2 產品需求評審產品需求評審2.3 設計審查設計審查2.4 代碼評審代碼評審2.1 軟件評審的方法與技術軟件評審的方法與技術 評審的方法評審的方法 評審會議評審會議 評審的技術評審的技術什么是軟件評審什么是軟件評審軟件評審是對軟件元素或者項目狀態的一種評估手段,以確定其是否與計劃的結果保持一致,并使其得到改進。 6評審方法評審方

2、法n 評審方法包括:走讀(Walkthrough) 小組評審(Team Review) 審查(Inspection) n 走讀、小組評審和審查都有正式評審和非正式評審兩種方式 評審的技術評審的技術檢查表檢查表場景分析場景分析頭腦風暴頭腦風暴輔助工具(統計、分析工具)輔助工具(統計、分析工具)評審會議評審會議會議流程會議流程達到評審會議標準?Yes計劃全面縱覽準備修正問題跟蹤問題記錄會議紀要滿足執行要求?YesNo總結報告評審結果分析流程改進建議2.1.4評審會議評審會議會議角色會議角色主持人作者記錄員CM評審員PMQA作者:解釋疑問、解決識別的缺陷主持人:從頭到尾管理評審過程評審員:識別缺陷和

3、問題記錄員:記錄識別的缺陷和問題并分發結果PM:確定評審計劃、確認評審對象資格QA:評審過程支持、審計評審過程CM:工作產品配置管理評審會議評審會議角色及職責角色及職責2.2 產品需求評審產品需求評審2.2.1需求評審的重要性需求評審的重要性2.2.2 需求評審的標準需求評審的標準2.2.3需求評審案例需求評審案例2.2.1需求評審重要性需求評審重要性v 發現需求定義中的問題,盡早發現缺陷,降低劣質成本。v 保證軟件需求的可測試性。v 與市場、產品、開發等相關人員在需求理解上認識一致,以免后期的爭吵。v 更好的理解產品的功能性與非功能性需求,為制定測試計劃打下基礎。v 確定測試目標與范圍。雖然

4、此后需求會發生變更,但能得到有效控制,降低測試風險。2.2.1 需求評審重要性直觀描述需求評審重要性直觀描述2.2.2需求評審的標準需求評審的標準v 正確性v 完備性v 易理解性v 一致性v 可行性v 易修改性v 易測試性v 易追溯性需求1:系統應在不少于每10秒的正常周期內提供狀態信息;系統應該以誤差上下不超過1秒的10秒間隔,在用戶界面的指定位置顯示狀態信息顯示的狀態信息應包括如下內容:。如果顯示狀態信息有錯誤,應提示如下的錯誤信息:。實例v禁忌詞語:這類詞語,不能出現在需求說明書中;否則,優秀需求的特征就不可能得到滿足v禁忌詞語舉例 某些、有時、常常、通常、貫常、經常、許多、大多、幾乎、

5、用戶友好的、容易的、簡單的、復雜的、健壯的、無縫的、透明的、優雅的、 最新技術等。這些詞語太過模糊,所描述的功能無法驗證 等等、諸如此類、依此類推、包括但不限于等。不完整,無法驗證 良好、迅速、廉價、高效、靈活、穩定、顯著、醒目等。這些是不確定的說法,不可驗證 可接受的、足夠的、差不多的、可選擇的、合理的、充分的、必要的、相關的等 一般情況下、理想情況下、必要時、合適時禁忌詞語 術語 前后置條件匹配 上下文2.2.2 需求評審標準需求評審標準-用語說明用語說明示例示例v 需求陳述 XML解析器應該生成標記出錯的報告,這樣就可以使XML初學者使用它來迅速找錯v 分析 禁忌詞:迅速 何時生成報告?

6、v 改正 在XML解析器完全解析完一個文件后,該解析器將生成一個出錯報告,其內容包括解析文件過程中所發現的所有XML錯誤的行號及其文本內容,還包括對每個錯誤的描述 如果在解析過程中未發現任何錯誤,則不必生成出錯報告術語工具術語工具v術語:需求說明書中出現的術語、名詞,其含義如果不包含在以下三種情況中,則意味著需求描述存在問題 約定俗成的 已定義在“術語與縮寫”、“數據字典”或“外部接口說明書”中 本文中有解釋示例示例v需求陳述 系統應對登錄到其上的無人值守的工作站提供超時安全保護措施v分析 系統如何判斷“無人值守”? “超時”中的“時”究竟是多長時間? 何謂“安全保護措施”?v改正 登錄到系統

7、上的工作站,如果超過(300 5)秒沒有發生任何鼠標或鍵盤操作,則系統應使得工作站進入屏幕保護狀態前后置條件匹配工具前后置條件匹配工具v前后置條件匹配:某個用例的前置條件,往往是由另一個(些)用例來設置的,即后者的后置條件就是前者的前置條件查詢商品目錄加入購物車付賬已登錄。意味著還存在用戶管理、權限管理查詢到特定商品查詢到特定商品商品已加入購物車購物車中至少有一件商品購物車中商品已付賬2.2.3 需求評審案例需求評審案例v1、某產品經理在主持需求評審會,評審開始時間不長,就被一位主管打斷,明確指出此方案與企業業務發展方向不符,不能實施。緊接著其他與會人員紛紛發言表示同意,結果評審會無法繼續進行

8、,需求最終被否決。v原因何在?v問題所在: 缺乏初步溝通,目標性需求尚未明確,功能性需求和操作性需求無從談起。2.2.3 需求評審案例需求評審案例v2、某次需求評審會,主要是公司內部相關領域的專家參加,在評審會開始后不久,某專家就對需求中的某個具體問題提出了自己的不同意見,于是,與會人員紛紛就該問題發表自己的意見,大家爭執不下,結果,致使會議出現了混亂狀況,主持人無法控制局面,會議大大超出了計劃評審時間。v原因何在? v問題所在:v前期溝通和準備不夠,缺乏應對不同意見的準備,難以化解爭執。v主持者不能有效把握會議目標,會議討論過于關注細節,導致評審失控。2.2.3 需求評審案例需求評審案例v3

9、、某產品經理主持需求評審會,在講解需求說明書時,與會人員似懂非懂,沒有提出任何有價值的問題,致使會議沒有得到預期效果,不得不改日重新進行。 v問題何在?v問題所在:v前期準備和溝通不夠,評審變成了培訓。v沒有選擇合適的評審人員,無法獲得有價值的信息。2.2.3需求評審案例需求評審案例v4、某需求評審會,與會人員各抒己見,氣氛熱烈,產品經理忙于收集意見,結果散會時發現對需求有價值的并不多,并且遺漏了許多要評審的問題,評審效果不佳。與會人員在離開會議室后,私下也認為評審沒有多少實際效果,完全是在走過場。v問題何在?v問題所在:v評審缺乏有效依據和規范,不能保證評審的覆蓋率和有效性。v產品經理沒有把

10、握好會議主題,評審變成了頭腦風暴。需求評審常見問題匯總需求評審常見問題匯總v目標性需求沒有溝通好,后面的需求變成空中樓閣。v缺乏評審的可操作依據,遺漏評審內容。v沒有作好前期準備工作,導致評審時間長,效率低。v沒有選擇合適的評審人員,無法獲得有價值的反饋。v參加人員過多,容易陷入細枝末節的討論,會議演變成一場人人自由的混戰。2.3 設計評審設計評審2.3.1 系統架構設計的評審系統架構設計的評審2.3.2 組件設計的審查組件設計的審查2.3.3 界面設計的評審界面設計的評審2.3.4 系統部署審查系統部署審查2.3.1系統設計的評審標準系統設計的評審標準v 設計技術評審標準。穩定、清晰、合理v

11、 非功能性質量特性的設計評審要求。安全、性能、穩定、擴展、可靠。v 評審的輸入:體系結構文檔、設計規范與指南、風險列表v 評審的輸出:經認可的軟件體系結構文檔、變更需求、評審記錄v 評審的檢查點:軟件體系結構、設計模式、部署視圖、進程視圖、封裝體、協議。2.3.1系統架構設計的審查系統架構設計的審查采用分層評審和整體評審相結合,經過整體評審到分層采用分層評審和整體評審相結合,經過整體評審到分層評審、再從分層評審到整體評審的過程,這樣既能確保評審、再從分層評審到整體評審的過程,這樣既能確保評審的深度,又能確保評審的一致性評審的深度,又能確保評審的一致性 p 整個系統不應該存在單一故障點 p系統是

12、否建立了故障轉移機制 p是否建立了良好的負載平衡機制 p關鍵業務 或關鍵任務 ?系統架構設計的基本要求就是保證系統具有高性能、高可系統架構設計的基本要求就是保證系統具有高性能、高可靠性、高安全性、高擴展性和可管理性靠性、高安全性、高擴展性和可管理性 。系統架構設計評。系統架構設計評審就是保證這些特性在設計中得到充分考慮。審就是保證這些特性在設計中得到充分考慮。2.3.2組件設計的審查組件設計的審查p 功能和接口定義 p 算法的有效性和優化p 合理的數據結構、數據流和控制流 p 可測試性 等2.3.3界面設計的審查界面設計的審查 (1) 易懂性、易用性(2) 一致性和規范性(3) 美觀與協調性(

13、4) 遵守慣例和通用法則(5) 獨特性(6) 快捷方式的組合(7) 自助功能(8) 錯誤保護2.3.4系統部署設計的審查系統部署設計的審查p 著重是否服從和遵守部署設計的技術規范著重是否服從和遵守部署設計的技術規范p 邏輯設計的審查邏輯設計的審查p 物理設計的審查物理設計的審查p 可用性設計的審查可用性設計的審查p 可伸縮型設計的驗證可伸縮型設計的驗證p 安全性設計的驗證安全性設計的驗證系統部署設計的審查是基于軟件服務的質量目標,用來審查軟件部署的目標、策略是否合理,是否得到徹底的執行。36檢查要素檢查內容清晰性是否所有的單元和進程的設計目的都已文檔化單元設計,包括數據流、接口描述是否清楚單元

14、的整體功能是否描述清楚完整性是否描述了所采用的標準是否確定了每個單元應用的算法是否列出了單元的所有調用是否記錄了設計繼承的歷史和已知的風險規范性文檔是否遵從了公司的標準單元設計是否使用了要求的方法和工具一致性在程序單元和單元的接口中數據成員的名稱是否保持一致所有接口之間,接口和接口規格書之間是否保持一致詳細設計是否同概要設計一致設計的評審條目解釋設計的評審條目解釋37設計的評審條目解釋設計的評審條目解釋檢查要素檢查內容正確性是否有邏輯錯誤需要使用常量名稱的地方是否有錯誤是否所有的條件都被處理(,=0,switch case)分支所處的狀態是否正確數據是否所有聲明的數據都已經被使用定位于單元的數

15、據結構是否已經描述如果有對共享數據、文件的修改,對數據的訪問是否按照正確的共享協議進行(例如:信號燈)可靠性對所有錯誤情況都做安排了有意義的消息反饋特殊情況下的返回碼是否和文檔中定義的全局返回碼一致是否考慮了異常情況(如磁盤空間不足、網絡掉線)可追溯性是否每個詳細設計單元都可以追溯到概要設計38設計的評審條目解釋設計的評審條目解釋檢查要素檢查內容接口參數表是否在數量、類型和順序上保持一致是否所有的輸入輸出都已經正確定義并檢查過所傳遞參數的順序是否描述清楚參數傳遞的機制是否確定通過接口傳遞的常量和變量是否與單元設計的相同(例如:函數中定義的常量不能在所調用的子過程中被修改)是否以度量單位描述了參

16、數的值區間、準確性和精度內容內容2.1 軟件評審的方法與技術2.2 產品需求評審2.3 設計審查2.4 代碼評審代碼評審402.4 2.4 代碼評審代碼評審n 2.4.1代碼風格與規則檢查n 2.4.2程序設計和結構的檢查 n 2.4.3業務邏輯的檢查 412.4.12.4.1代碼風格和規格檢查代碼風格和規格檢查n 代碼風格和規則 代碼風格和規則的檢查是在每個程序員完成一個模塊或類的時候要進行編碼規范的檢查。做一個檢查表,以表的內容為檢查依據,檢查表的內容主要是檢查的要點。Camel標記法 - 首字母是小寫的,接下來的單詞都已大寫字母開頭。Pascal標記法 - 首字母是大寫的,接下來的單詞都

17、已大寫字母開頭。匈牙利類型標記法 - 在以Pascal標記法命名的變量前附加一個小寫字母開頭(或小寫字母序列),說明該變量的類型,例如,i表示整數,s表示字符串。2.4.12.4.1代碼風格和規格檢查代碼風格和規格檢查n Java 命名規范包(Packages): 包名命名全部小寫字母:com.hisense.hiatmp類(Classes):類名命名采用Pascal標記法:public class PassImpl接口(Interfaces): 接口類名以大寫“I”開頭,命名采用Pascal標記法;示例:Ipass方法(Methods): 方法名命名采用camel標記法;public Lis

18、t getDirect()變量(Variables): 變量名命名采用camel標記法;盡量避免單個字符的變量名,除非是一次性的臨時變量。臨時變量通常被取名為i,j,k,m和n,它們一般用于整型;c,d,e,它們一般用于字符型;常量(Constants): 常量命名全部大寫,單詞間用下劃線隔開;常量必須是靜態、final類型。432.4.12.4.1代碼風格和規格檢查代碼風格和規格檢查n 程序風格檢查程序風格的一致性、規范性;代碼必須能保證符合企業規范,保證所有成員的代碼風格一致、規范、工整。例如對數組做循環,不要一會兒采用下標變量從下到上的方式(如:for(I=0;I+;I0);應該盡量采用

19、統一的方式,或則統一從下到上,或則統一從上到下。表示符定義的規范一致性;保證變量命名能夠見名知意,并且簡潔但不宜過長或過短、規范、容易記憶、最好能夠拼讀。并盡量保證用相同的表示符代表相同功能,不要將不同的功能用相同的表示符表示;更不要用相同的表示符代表不同的功能意義。442.4.12.4.1代碼風格和規格檢查代碼風格和規格檢查n 程序風格檢查檢查程序是否清晰簡潔容易理解。注意:冗長的程序并不一定不是清晰的。檢查方法內部注釋是否完整;是否清晰簡潔;是否正確的反映了代碼的功能,錯誤的注釋比沒有注釋更糟;是否做了多余的注釋;對于簡單的一看就懂的代碼沒有必要注釋。檢查注釋文檔是否完整;對包、類、屬性、

20、方法功能、參數、返回值的注釋是否正確且容易理解;是否會落了或多了某個參數的注釋,參數類型是否正確,參數的限定值是否正確。特別是對于形式參數與返回值中關于神秘數值的注釋,如:類型參數 應該指出 1.代表什么,2.代表什么等。對于返回結果集(Result Set)的注釋,應該注釋結果集中包含那些字段及字段類型、字段順序等。452.4.2 2.4.2 程序設計和結構的檢查程序設計和結構的檢查n 程序設計和結構的檢查檢查算法的邏輯正確性;確定所編寫的代碼算法、數據結構定義(如:隊列、堆棧等)是否實現了模塊或方法所要求的功能。模塊接口的正確性檢查;確定形式參數個數、數據類型、順序是否正確;確定返回值類型

21、及返回值的正確性。輸入參數有沒有作正確性檢查;如果沒有作正確性檢查,確定該參數是否的確無需做參數正確性檢查,否則請添加上參數的正確性檢查。經驗表明,缺少參數正確性檢查的代碼是造成軟件系統不穩定的主要原因之一。 462.4.2 2.4.2 程序設計和結構的檢查程序設計和結構的檢查n 程序設計和結構的檢查(續)調用其他方法接口的正確性;檢查實參類型正確與否、傳入的參數值正確與否、個數正確與否,特別是具有多態的方法。返回值正確與否,有沒有誤解返回值所表示的意思。最好對每個被調用的方法的返回值用顯示代碼作正確性檢查。出錯處理;模塊代碼要求能預見出錯的條件,并設置適當的出錯處理,以便在一旦程序出錯時,能

22、對出錯程序重做安排,保證其邏輯的正確性,這種出錯處理應當是模塊功能的一部分。若出現下列情況之一,則表明模塊的錯誤處理功能包含有錯誤或缺陷:出錯的描述難以理解;出錯的描述不足以對錯誤定位,不足以確定出錯的原因;顯示的錯誤信息與實際的錯誤原因不符;對錯誤條件的處理不正確;在對錯誤進行處理之前,錯誤條件已經引起系統的干預等。 472.4.2 2.4.2 程序設計和結構的檢查程序設計和結構的檢查n 程序設計和結構的檢查(續)保證表達式、SQL語句的正確性;檢查所編寫的SQL語句的語法、邏輯的正確性。對表達式應該保證不含二義性,對于容易產生歧義的表達式或運算符優先級(如: 、=、 、 &、|、+

23、、 -等)可以采用擴號“()”運算符避免二義性,這樣一方面能夠保證代碼的正確可靠,同時也能夠提高代碼的可讀性。檢查常量或全局變量使用的正確性;確定所使用的常量或全局變量的取值和數值、數據類型;保證常量每次引用同它的取值、數值和類型的一致性。 482.4.2 2.4.2 程序設計和結構的檢查程序設計和結構的檢查n 程序設計和結構的檢查(續)檢查代碼是否可以優化、算法效率是否最高。如:SQL語句是否可以優化,是否可以用1條SQL語句代替程序中的多條SQL語句的功能,循環是否必要,循環中的語句是否可以抽出到循環之外等。 492.4.3 2.4.3 業務邏輯檢查業務邏輯檢查n 業務邏輯的檢查主要是檢查

24、單元功能設計是否滿足概要設計要求模塊功能模塊層次結構模塊調用關系2.4 2.4 代碼評審代碼評審-Java重要性重要性激活激活 級別級別 檢查項檢查項總計總計 命名命名 重要重要2020命名規則是否與所采用的規范保持一致?2020是否遵循了最小長度最多信息原則?重要重要5050has/can/is前綴的函數是否返回布爾型?注釋注釋 重要重要1010注釋是否較清晰且必要?重要重要Y Y1010復雜的分支流程是否已經被注釋?1010距離較遠的是否已經被注釋?1010非通用變量是否全部被注釋?重要重要Y Y5050函數是否已經有文檔注釋?(功能、輸入、返回及其他其他可選)1010特殊用法是否被注釋?

25、2.4 2.4 代碼評審代碼評審-Java聲明、空白、縮進聲明、空白、縮進 2020每行是否只聲明了一個變量?(特別是那些可能出錯的類型)重要重要4040變量是否已經在定義的同時初始化?重要重要4040類屬性是否都執行了初始化?2020代碼段落是否被合適地以空行分隔?Y Y2020是否合理地使用了空格使程序更清晰?2020代碼行長度是否在要求之內?2020折行是否恰當?語句語句/ /功能分布功能分布/ /規模規模 2020包含復合語句的是否成對出現并符合規范?2020是否給單個的循環、條件語句也加了?2020if/if-else/if-else if-else/do-while/switch-

26、case語句的格式是否符合規范?4040單個變量是否只做單個用途?重要重要2020單行是否只有單個功能?(不要使用;進行多行合并)重要重要4040單個函數是否執行了單個功能并與其命名相符?Y Y2020操作符和 操作符的應用是否復合規范?2.4 2.4 代碼評審代碼評審-Java規模規模 重要重要2020單個函數不超過規定行數?重要重要100100縮進層數是否不超過規定?重要重要100100是否已經消除了所有警告?重要重要Y Y4040常數變量是否聲明為final?重要重要8080對象使用前是否進行了檢查?重要重要8080局部對象變量使用后是否被復位為NULL?重要重要7070對數組的訪問是否

27、是安全的?(合法的index取值為0, MAX_SIZE-1)。重要重要2020是否確認沒有同名變量局部重復定義問題?2020程序中是否只使用了簡單的表達式?2.4 2.4 代碼評審代碼評審-Java重要重要Y Y2020是否已經用()使操作符優先級明確化?重要重要Y Y2020所有判斷是否都使用了(常量=變量)的形式?8080是否消除了流程懸掛?重要重要8080是否每個if-else if-else語句都有最后一個else以確保處理了全集?重要重要8080是否每個switch-case語句都有最后一個default以確保處理了全集?8080for循環是否都使用了包含下限不包含上限的形式?(k

28、=0; kMAX)重要重要4040XML標記書寫是否完整,字符串的拼寫是否正確?4040對于流操作代碼的異常捕獲是否有finally操作以關閉流對象?2020退出代碼段時是否對臨時對象做了釋放處理?重要重要4040對浮點數值的相等判斷是否是恰當的?(嚴禁使用=直接判斷)2.4 2.4 代碼評審代碼評審-Java可靠性(函數)可靠性(函數) 重要重要Y Y6060入口對象是否都被進行了判斷不為空?重要重要Y Y6060入口數據的合法范圍是否都被進行了判斷?(尤其是數組)重要重要Y Y2020是否對有異常拋出的方法都執行了try.catch保護?重要重要Y Y8080是否函數的所有分支都有返回值?

29、重要重要5050int的返回值是否合理?(負值為失敗,非負值成功)2020對于反復進行了int返回值判斷是否定義了函數來處理?6060關鍵代碼是否做了捕獲異常處理?重要重要6060是否確保函數返回CORBA對象的任何一個屬性都不能為null?重要重要6060是否對方法返回值對象做了null檢查,該返回值定義時是否被初始化?重要重要6060是否對同步對象的遍歷訪問做了代碼同步?重要重要8080是否確認在對Map對象使用迭代遍歷過程中沒有做增減元素操作?重要重要6060線程處理函數循環內部是否有異常捕獲處理,防止線程拋出異常而退出?2020原子操作代碼異常中斷,使用的相關外部變量是否恢復先前狀態?

30、重要重要100100函數對錯誤的處理是恰當的?2.4 2.4 代碼評審代碼評審-Java可維護性可維護性重要重要100100實現代碼中是否消除了直接常量?(用于計數起點的簡單常數例外)2020是否消除了導致結構模糊的連續賦值?(如a= (b=d+c ))2020是否每個return前都要有日志記錄?2020是否有冗余判斷語句?(如:if (b) return true; else return false;)2020是否把方法中的重復代碼抽象成私有函數?562.4 2.4 代碼評審代碼評審-C/C+文件結構文件結構重要性審查項結論頭文件和定義文件的名稱是否合理?頭文件和定義文件的目錄結構是否合

31、理?版權和版本聲明是否完整?重要重要頭文件是否使用了 ifndef/define/endif 預處理塊?頭文件中是否只存放“聲明”而不存放“定義”572.4 2.4 代碼評審代碼評審-C/C+程序的版式程序的版式重要性審查項結論空行是否得體?代碼行內的空格是否得體?長行拆分是否得體?“” 和 “” 是否各占一行并且對齊于同一列?重要重要一行代碼是否只做一件事?如只定義一個變量,只寫一條語句。重要重要If、for、while、do等語句自占一行,不論執行語句多少都要加“”。582.4 2.4 代碼評審代碼評審-C/C+程序的版式程序的版式重要性審查項結論重要重要在定義變量(或參數)時,是否將修飾

32、符 * 和 緊靠變量名?注釋是否清晰并且必要?重要重要注釋是否有錯誤或者可能導致誤解?重要重要類結構的public, protected, private順序是否在所有的程序中保持一致?592.4 2.4 代碼評審代碼評審-C/C+命名規則命名規則重要性審查項結論重要重要命名規則是否與所采用的操作系統或開發工具的風格保持一致?標識符是否直觀且可以拼讀?標識符的長度應當符合“min-length & max-information”原則?重要重要程序中是否出現相同的局部變量和全部變量?類名、函數名、變量和參數、常量的書寫格式是否遵循一定的規則?靜態變量、全局變量、類的成員變量是否加前綴?

33、602.4 2.4 代碼評審代碼評審-C/C+常量常量重要性審查項結論是否使用含義直觀的常量來表示那些將在程序中多次出現的數字或字符串?在C+ 程序中,是否用const常量取代宏常量?重要重要如果某一常量與其它常量密切相關,是否在定義中包含了這種關系?是否誤解了類中的const數據成員?因為const數據成員只在某個對象生存期內是常量,而對于整個類而言卻是可變的。612.4 2.4 代碼評審代碼評審-C/C+內存管理內存管理重要性審查項結論重要重要用malloc或new申請內存之后,是否立即檢查指針值是否為NULL?(防止使用指針值為NULL的內存)重要重要是否忘記為數組和動態內存賦初值?(防

34、止將未被初始化的內存作為右值使用)重要重要數組或指針的下標是否越界?重要重要動態內存的申請與釋放是否配對?(防止內存泄漏)重要重要是否有效地處理了“內存耗盡”問題?622.4 2.4 代碼評審代碼評審-C/C+內存管理內存管理重要性審查項結論重要重要是否修改“指向常量的指針”的內容?重要重要是否出現野指針?例如(1)指針變量沒有被初始化。(2)用free或delete釋放了內存之后,忘記將指針設置為NULL。重要重要是否將malloc/free 和 new/delete 混淆使用?重要重要malloc語句是否正確無誤?例如字節數是否正確?類型轉換是否正確?重要重要在創建與釋放動態對象數組時,new/delete的語句是否正確無誤?632.4 2.4 代碼評審代碼評審-C/C+C+ C+ 函數的高級特性函數的高級特性重要性審查項結論重要重要是否混淆了成員函數的重載、覆蓋與隱藏?運算符的重載是否符合制定的編程規范?是否濫用內聯函數?例如函數體內的代碼比較長,函數體內出現循環。重要重要是否用內聯函數取代了宏代碼?642.4 2.4 代碼評審代碼評審-C/C+類的構造函數、析構函數和賦值函數類的

溫馨提示

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

評論

0/150

提交評論