• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            S.l.e!ep.¢%

            像打了激速一樣,以四倍的速度運轉,開心的工作
            簡單、開放、平等的公司文化;尊重個性、自由與個人價值;
            posts - 1098, comments - 335, trackbacks - 0, articles - 1
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            Code Review 理論與實戰 [轉]

            Posted on 2009-01-18 12:46 S.l.e!ep.¢% 閱讀(640) 評論(0)  編輯 收藏 引用 所屬分類: C++

            ?

            Code Review 是一種通過復查代碼提高代碼質量的過程,在 XP 方法中占有極為重要的地位,也已經成為軟件工程中一個不可缺少的環節。本文通過對 Code Review 的一些概念和經驗的探討,就如何進行 Code Review Code Review 中應該注意什么提出一些建議。 本文中涉及的問題大部分針對 JAVA 類代碼。同時本文不涉及 Code Review 過程和組織。

            關鍵詞: Code Review JAVA XP ,代碼質量 ,軟件工程

            一、 Code Review 簡介

            1 Code Review 的目的

            凡事知其然還要知其所以然 我們首先需要知道什么是 Code Review 和我們使用它的目的是什么。 Code Review 是一種用來確認方案設計和代碼實現的質量保證機制,通過這個機制我們可以對代碼,測試過程和注釋進行檢查。 Code Review 主要用來在軟件工程過程中改進代碼質量,通過 Code Review 可以達到如下目的:

            在項目早期就能夠發現代碼中的BUG

            幫助初級開發人員學習高級開發人員的經驗,達到知識共享

            避免開發人員犯一些很常見,很普通的錯誤

            ??? 保證項目組人員的良好溝通

            ??? 項目或產品的代碼更容易維護

            2 Code Review的前提

            知道了 Code Review 的目的,我們就可以看看如何做 Code Review 了,但在做 Code Review 前我們還有事要做,所謂預則立,不預則廢,就是說如果在進入 Code Review 之前我們不做些準備工作, Code Review 很容易就變得沒有意義或是流于形式,這在我們周圍是有很多例子的啊。進入 Code Review 需要檢查的條件如下:

            a) ?????? Code Review 人員是否理解了 Code Review 的概念和 Code Review 將做什么

            如果做 Code Review 的人員不能理解 Code Review 對項目成敗和代碼質量的重要程度,他們的做法可能就會是應付了事。

            b) ????? 代碼是否已經正確的 build build 的目的使得代碼已經不存在基本語法錯誤

            我們總不希望高級開發人員或是主管將時間浪費在檢查連編譯都通不過的代碼上吧。

            c) ????? 代碼執行時功能是否正確

            Code Review 人員也不負責檢查代碼的功能是否正確,也就是說,需要復查的代碼必須由開發人員或質量人員負責該代碼的功能的正確性。

            d) ????? Review 人員是否理解了代碼

            做復查的人員需要對該代碼有一個基本的了解,其功能是什么,是拿一方面的代碼,涉及到數據庫或是通訊,這樣才能采取針對性的檢查

            e) ?????? 開發人員是否對代碼做了單元測試

            這一點也是為了保證 Code Review 前一些語法和功能問題已經得到解決, Code Review 人員可以將精力集中在代碼的質量上。

            3 Code Review 需要做什么

            好了,進入條件準備好了,有人在這些條件中看到 Code Review 這也不負責,那也不檢查,不禁會問, Code Review 到底做什么?其實 Code Review 主要檢查代碼中是否存在以下方面問題:代碼的一致性、編碼風格、 代碼的安全問題、代碼冗余、是否正確設計以滿足需求(性能、功能等等),下邊我們一一道來。以下內容參考了 Software Quality Assurance: Documentation and Reviews 》一文中的代碼檢查部分。

            3 1 完整性檢查( Completeness

            代碼是否完全實現了設計文檔中提出的功能需求

            代碼是否已按照設計文檔進行了集成和 Debug

            代碼是否已創建了需要的數據庫 , 包括正確的初始化數據

            代碼中是否存在任何沒有定義或沒有引用到的變量、常數或數據類型

            3.2一致性檢查(Consistency)

            代碼的邏輯是否符合設計文檔

            代碼中使用的格式、符號、結構等風格是否保持一致

            3.3正確性檢查(Correctness)

            ?????? 代碼是否符合制定的標準

            ?????? 所有的變量都被正確定義和使用

            ?????? 所有的注釋都是準確的

            ?????? 所有的程序調用都使用了正確的參數個數

            3 4 可修改性檢查( Modifiability

            ?????? 代碼涉及到的常量是否易于修改 ( 如使用配置、定義為類常量、使用專門的常量類等 )

            ?????? 代碼中是否包含了交叉說明或數據字典,以描述程序是如何對變量和常量進行訪問的

            ?????? 代碼是否只有一個出口和一個入口(嚴重的異常處理除外)

            3.5可預測性檢查(Predictability)

            ?????? 代碼所用的開發語言是否具有定義良好的語法和語義

            ?????? 是否代碼避免了依賴于開發語言缺省提供的功能

            ?????? 代碼是否無意中陷入了死循環

            ?????? 代碼是否是否避免了無窮遞歸

            3.6健壯性檢查(Robustness)

            ?????? 代碼是否采取措施避免運行時錯誤(如數組邊界溢出、被零除、值越界、堆棧溢出等)

            3.7結構性檢查(Structuredness)

            ?????? 程序的每個功能是否都作為一個可辯識的代碼塊存在

            ?????? 循環是否只有一個入口

            3.8可追溯性檢查(Traceability)

            ?????? 代碼是否對每個程序進行了唯一標識

            ?????? 是否有一個交叉引用的框架可以用來在代碼和開發文檔之間相互對應

            ?????? 代碼是否包括一個修訂歷史記錄,記錄中對代碼的修改和原因都有記錄

            ?????? 是否所有的安全功能都有標識

            3.9可理解性檢查(Understandability)

            ?????? 注釋是否足夠清晰的描述每個子程序

            ?????? 是否使用到不明確或不必要的復雜代碼,它們是否被清楚的注釋

            ?????? 使用一些統一的格式化技巧(如縮進、空白等)用來增強代碼的清晰度

            ?????? 是否在定義命名規則時采用了便于記憶,反映類型等方法

            ?????? 每個變量都定義了合法的取值范圍

            ?????? 代碼中的算法是否符合開發文檔中描述的數學模型

            3.10可驗證性檢查(Verifiability)

            ?????? 代碼中的實現技術是否便于測試

            二、 Code Review 經驗檢查項

            以下是在實踐中建立的檢查列表 checklist ), 通過分類和有針對性的檢查項 保證了 Code Review 可以有的放矢。

            1 JAVA 編碼規范方面檢查項

            檢查項參照 JAVA 編碼規范執行 見《 JAVA 編碼規范 ( Java Code Conventions )

            2 面向對象設計方面檢查項

            這幾點的范圍都很大,不可能在本文展開討論,有專門的書籍介紹這方面問題,當然在 Code Review 中主要靠經驗來判斷。

            A) ?????? 類設計和抽象是否合適

            B) ??????? 是否符合面向接口編程的思想

            C) ?????? 是否采用合適的設計范式

            3 性能方面檢查項

            性能檢查在大多數代碼中都是需要嚴重關注的方面,也是最容易出現問題的方面,常常有程序員寫出了功能和語法沒有絲毫問題的代碼后,正式運行時卻在性能上表現不佳,從而不得不做大量的返工,甚至是推倒重來。

            A) ?????? 在海量數據出現時,隊列,表,文件,在傳輸,upload等方面是否會出現問題,有無控制,如分配的內存塊大小,隊列長度等控制參數

            B) ?????? hashtable,vector等集合類數據結構的選擇和設置是否合適,如正確設置capacity,load factor等參數,數據結構的是否是同步的

            C) ?????? 有無濫用String對象的現象

            D) ?????? 是否采用通用的線程池、對象池模塊等cache技術以提高性能

            E) ?????? 類的接口是否定義良好,如參數類型等,避免內部轉換

            F) ?????? 是否采用內存或硬盤緩沖機制以提高效率

            G) ?????? 并發訪問時的應對策略

            H) ?????? I/O方面是否使用了合適的類或采用良好的方法以提高性能(如減少序列化,使用buffer類封裝流等)

            I) ???????? 同步方法的使用是否得當,是否過度使用

            J) ???????? 遞歸方法中的疊代次數是否合適,應該保證在合理的棧空間范圍內

            K) ?????? 如果調用了阻塞方法,是否考慮了保證性能的措施

            L) ??????? 避免過度優化,對性能要求高的代碼是否使用profile工具,如Jprobe等

            4 資源泄漏處理方面檢查項

            ? 對于 JAVA 來說由于存在垃圾收集機制,所以內存泄漏不是太明顯,但使用不當,仍然存在內存泄漏的問題。而對于其它的語言,如 C++ 等在這方面就要嚴重關注了。當然數據庫連接資源不釋放的問題也是廣大程序員最常見的,相信有很多的 PM 被這個問題折磨的死去活來。

            A) ?????? 分配的內存是否釋放,尤其在錯誤處理路徑上(對非 JAVA 類)

            B) ??????? 錯誤發生時是否所有的對象被釋放,如數據庫連接、 Socket 、文件等

            C) ?????? 是否同一個對象被釋放多次(對非 JAVA 類)

            D) ?????? 代碼是否保存準確的對象 reference 計數(對非 JAVA 類)

            5 線程安全方面檢查項

            線程安全問題實際涉及兩個方面,一個是性能,另一個是資源的一致性,我們需要在這兩方面做個權衡,現在就是到了權衡利弊的時候了。

            A) ?????? 代碼中所有的全局變量是否是線程安全的

            B) ??????? 需要被多個線程訪問的對象是否線程安全,檢查有無通過同步方法保護

            C) ?????? 同步對象上的鎖是否按相同的順序獲得和釋放以避免死鎖,注意錯誤處理代碼

            D) ?????? 是否存在可能的死鎖或是競爭,當用到多個鎖時,避免出現類似情況:線程 A 獲得鎖 1 ,然后鎖 2 ,線程 B 獲得鎖 2 ,然后鎖 1

            E) ??????? 在保證線程安全的同時,要注意避免過度使用同步,導致性能降低

            6 程序流程方面檢查項

            A) ?????? 循環結束條件是否準確

            B) ??????? 是否避免了死循環的產生

            C) ?????? 對循環的處理是否合適,如循環變量,局部對象,循環次數等能夠考慮到性能方面的影響

            7 數據庫處理方面

            很多 Code Review 人員在面對代碼中涉及到的數據庫可移植性和提高數據庫性能方面的沖突時表現的無所適從,凡事很難兩全其美的啊。

            A) ?????? 數據庫設計或SQL語句是否便于移植(注意和性能方面會存在沖突)

            B) ?????? 數據庫資源是否正常關閉和釋放

            C) ?????? 數據庫訪問模塊是否正確封裝,便于管理和提高性能

            D) ?????? 是否采用合適的事務隔離級別

            E) ?????? 是否采用存儲過程以提高性能

            F) ??????? 是否采用PreparedStatement以提高性能

            8 通訊方面檢查項

            A) ?????? socket通訊是否存在長期阻塞問題

            B) ?????? 發送接收的數據流是否采用緩沖機制

            C) ?????? socket超時處理,異常處理

            D) ?????? 數據傳輸的流量控制問題

            9 JAVA 對象處理方面檢查項

            這個檢查項的基礎是對 JAVA 對象有較深的理解,但現實是很多看過《 Thinking in Java 》的程序員,仍然在程序中無法區分傳值和傳引用,以及對象和 reference 的區別。這或許就是理論和實踐難以結合的問題啊。正所謂知而不行,非真知也。

            A) ?????? 對象生命周期的處理,是否對象的reference已經失效,能夠設置為null,并被回收

            B) ?????? 在對象的傳值和傳參方面有無問題,對象的clone方法使用是否過度

            C) ?????? 是否 大量經常的創建臨時對象

            D) ?????? 是否盡量使用局部對象(堆棧對象)

            E) ??????? 在只需要對象reference的地方是否創建了新的對象實例

            10 異常處理方面檢查項

            JAVA 中提供了方便的異常處理機制,但普遍存在的是異常被捕獲,但并沒有得到處理。我們可以打開一段代碼,最常見的現象是進入某個方法后,一個大的 try/catch 將所有代碼行括住,然后在 catch 中將異常打印到控制臺,而且該異常是 Exception 對象。

            A) ?????? 每次當方法返回時是否正確處理了異常,如最簡單的處理,記錄日志到日志文件中

            B) ??????? 是否對數據的值和范圍是否合法進行校驗,包括采用斷言( assertion

            C) ?????? 在出錯路徑上是否所有的資源和內存都已經釋放

            D) ?????? 所有拋出的異常都得到正確的處理,特別是對子方法拋出的異常,在整個調用棧中必須能夠被捕捉并處理

            E) ??????? 當調用導致錯誤發生時,方法的調用者應該得到一個通知

            F) ??????? 不要忘了對錯誤處理部分的代碼進行測試,很多代碼在正常情況下執行良好,而一旦出錯,整個系統就崩潰了

            11 方法(函數)方面檢查項

            A) ?????? 方法的參數是否都做了校驗

            B) ??????? 數組類結構是否做了邊界校驗

            C) ?????? 變量在使用前是否做了初始化

            D) ?????? 返回堆對象的 reference ,不要返回棧對象的 reference

            E) ??????? 方法 API 是否被良好定義,即是否盡量面向接口編程,便于維護和重構

            12 安全方面檢查項

            A) ?????? 對命令行執行的代碼,需要詳細檢查命令行參數

            B) ??????? WEB 類程序檢查是否對訪問參數進行合法性驗證

            C) ?????? 重要信息的保存是否選用合適的加密算法

            D) ?????? 通訊時考慮是否選用安全的通訊方式

            13 其他

            A)????? 日志是否正常輸出和控制

            B) ??????? 配置信息如何獲得,是否有硬編碼

            三、 總結

            通過在項目中實施 Code Review 將為我們帶來多方面的好處,表現在提高代碼質量,保證項目或產品的穩定性,開發經驗的積累等,具體的實施當然也要看項目的實際情況,因為 Code Review 也是需要成本的,這方面屬于 Code Review 過程的問題,將在其他文章中進行探討。

            四、 參考資料

            Java 語言編碼規范 (Java Code Conventions)? SUN

            Software Quality Assurance: Documentation and Reviews? Dolores R. Wallace,Wendy W. Peng, Laura M. Ippolito

            快速軟件開發 斯蒂夫 電子工業出版社

            五、 關于作者

            陳建華 , 從事移動互聯方面的應用開發 , 郵件地址 : cqbbs@yeah.net

            亚洲中文字幕无码久久精品1| 久久性精品| 久久精品无码免费不卡| 久久精品国产免费观看三人同眠| 国产∨亚洲V天堂无码久久久| 久久精品国产清自在天天线| 97精品依人久久久大香线蕉97| 久久免费国产精品一区二区| 亚洲精品WWW久久久久久| 国产精品视频久久| 一本色综合久久| 热99re久久国超精品首页| 欧美日韩精品久久免费| 日韩亚洲欧美久久久www综合网| 精品伊人久久大线蕉色首页| 国产成人精品久久亚洲| 久久久久人妻精品一区| 亚洲午夜无码久久久久小说| 精品精品国产自在久久高清| 国产精品久久婷婷六月丁香| 国产日韩久久久精品影院首页 | 久久人妻少妇嫩草AV蜜桃| 韩国三级大全久久网站| 久久免费看黄a级毛片| 国产99久久久国产精品~~牛| 久久综合狠狠综合久久综合88| 四虎影视久久久免费观看| 久久精品人人做人人爽电影| 亚洲国产精品无码久久久蜜芽| 久久最新免费视频| 国产精品99久久久久久www| 久久精品夜夜夜夜夜久久| 久久久久99这里有精品10| 久久www免费人成看国产片| 国产精品免费看久久久| 久久精品无码一区二区WWW| 日韩欧美亚洲国产精品字幕久久久| 91久久成人免费| 精品999久久久久久中文字幕| 欧美噜噜久久久XXX| 久久久国产精华液|