代碼審查在軟件開發中的應用范文

本站小編為你精心準備了代碼審查在軟件開發中的應用參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

《電腦開發與應用雜志》2014年第六期

1何時進行審查

根據軟件項目質量標準，每一小段代碼在之前都要經過細致的審查。全面的代碼審查應占編碼時間的50%或更多，比現實世界中的項目準備投入的時間要長。任何項目都會產生大量的源代碼。除了嚴格開發過程之外，總是沒有足夠的時間對每一個小代碼片斷進行詳盡的審查。那么，應如何決定哪部分代碼需要審查呢？必須選擇那些最能從審查中獲益的代碼。也就是那些可能編寫得很槽糕的代碼，或者是那些對于系統正常發揮作用最重要的代碼。具體可采取5種策略：①選擇中心組件的核心代碼；②運行分析器，看一看大部分CPU時間被用在哪里，然后對那部分代碼進行審查；③運行復雜性分析工具，然后對那段最槽糕的代碼進行審查；④將目標鎖定在那些已呈現出高錯誤率的代碼上；⑤挑出開發經驗缺乏的軟件開發者編寫的代碼。最切實的做法是綜合應用以上策略，基于對項目團隊、代碼庫以及當前系統的性能、bug樹立等特點，選擇最佳代碼審查對象。

2執行代碼審查

僅僅有代碼審查是不夠的，它本身不能解決所有問題，還需要通過代碼審查會議、集成審查、影子審查等來完成。

2.1代碼審查會議

在高度程式化的軟件開發過程中，最常見的審查方式是代碼審查會議。該會議有一個固定的議程表，以確保不會忘記任何步驟，以及一個預先確定的結束點，不一定是一個時間限制，也許是一個關于審查這些代碼不需要審查那些代碼的規定。代碼審查會議包括地點、時間、角色和責任、議程表4項內容。

2.1.1地點召開代碼審查會議的最佳地點是一個安靜的房間，審查人員不應受到干擾。應準備一臺裝有代碼編輯器并與網絡相連的筆記本和一臺與投影儀相連的計算機。經驗豐富的軟件開發者會喜歡打印稿和用筆和紙做記錄。

2.1.2時間召開代碼審查會議應選擇大家都方便的時間，可選擇星期一到星期五的上午，因為這段時間人的工作效率最高。如果代碼的規模太大，那么可將審查分為許多單獨的小會議。但千萬不要讓參加代碼審查會議的人員連續坐在一個封閉的場所很長時間，同時又期望他們的審查保持較高的質量。

2.1.3角色和責任選擇誰參加會議，是決定一次代碼審查會議是否成功的最重要的因素之一。每一位與會者都應被分配一個特定的角色。在較小的組中，一個人可承擔多個角色，具體角色如下：（1）作者。顯然編寫代碼的人應參加審查，以匯報他做了哪些工作，可拒絕不公平或不正確的意見，并傾聽有效的和建設性的反饋意見。（2）審查人員。應仔細挑選參加代碼審查的人員，確保這些人有足夠的時間和技能來進行審查。如果代碼在他們的專業范圍以內，或者他們以某種方式參加了代碼的編寫，那么這對代碼審查就會有幫助。例如，在對一個利用某個庫來診斷不正確的API用法的程序進行審查時，編寫這個庫的人員就應被邀參加會議。（3）主持人。任何會議都需要一位主持人，否則就會出現混亂。這個人要引導代碼審查的進行，并指導開展討論。要確保談話切中主題，以及代碼審查會議不偏離主題。任何不需要在會議中討論的次要問題，都應由主持人快速地派出出去。這是因為只要一有機會，代碼編寫者們就會對某個細小的問題討論幾個小時，而不惜浪費代碼審查時間。（4）秘書。主要負責記錄代碼存在的問題和具體修改意見。

2.1.4議程表代碼審查會議議程有5項：①作者簽名表示代碼已經準備就緒，可以進行審查；②主持人安排會議，包括預定適當的地點、設定時間和召集相應的審查人員；③準備好計算機、投影儀、打印稿等；④提前發出會議通知，預留出足夠的時間，以便讓審查人員做好準備；⑤在發出會議通知之后，開發者暫停修改代碼。代碼審查會議召開過程如下：（1）主持人事先安排布置好會議室，以便審查能如期進行；（2）作者用幾分鐘時間解釋代碼的目的，并接受代碼的結構；（3）先邀請大家對結構上的設計發表意見。這些意見與實現的結構相關，而不是與代碼的具體語句相關。將項目功能分為不同類型，將代碼放在不同的文件中，以及編寫不同風格的函數。（4）邀請大家對代碼提出總體意見。這些意見可能涉及不一致的編碼風格、槽糕的設計模式應用和錯誤的語言習慣用法等。（5）對代碼進行逐步的排查，以便尋找缺陷；（6）考慮許多代碼使用的場景實例，并對控制流進行研究。如果有一套完整的單元測試，那么這些測試將詳細描述需要分析的場景，從而有助于審查人員考慮所有的執行路徑。（7）秘書記錄下所有必須進行的修改；（8）將任何可能影響代碼庫其他部分的問題記錄下來，留待進一步研究；（9）當審查結束時，大家應對下一步達成共識。其結果有3種：①通過；②重新編寫并驗證；③重新編寫并重新審查。

2.2集成審查

代碼審查會議是一種高度程式化的審查辦法。這是一項非常艱巨的工作，但是它能發現許多問題，如果不召開會議這些問題就可能被漏掉。除此之外，還存在一些強度較小的審查過程，它們最大限度地提供了代碼審查會議所帶來的好處，實際上最有效的就是將新代碼集成到主線代碼分支中時而進行的集成審查。在以下3種情形下使用集成審查：①一段新的代碼即將簽入到源代碼控制系統中；②一段代碼剛剛簽入到源代碼控制系統中；③一個代碼包從功能開發分支合并到主版本分支上。在這些情形下，要將接受審查的代碼標注出來，并挑選一位恰當的審查人員，可以是負責開發這個模塊的人、代碼集成人員、代碼維護人員或被任命在一對一審查會議上對作者的源代碼進行驗證的人。與代碼審查會議相比，實際的審查步驟通常要隨意得多。審查人員會瀏覽代碼，查看是否有明顯的問題，對其進行測試，最后同意將其加入到主線中，由于審查人員和作者不需要真正面對面坐在一起，這種審查可看成是一種虛擬的審查過程。

2.3影子審查

這是一種介于對編程和代碼審查之間的方法。每個代碼模塊都有一位主導開發人員，他負責開發代碼。還會指定一位影子開發人員，他負責定期與主導開發人員一起對模塊進行審查。在設計過程中，影子開發人員將對已經制定的決策進行驗證。隨著代碼的逐漸完成，影子審查也逐步推進，并提出許多富有建設性的意見。在正式開發過程中，影子開發人員還被賦予了批準代碼可以的權力。除非影子開發人員同意某個模塊已經可以加入到版本構建中，否則任何模塊都不能被集成。

3代碼審查的標準

經過代碼審查后，代碼應達到如下標準：（1）沒有bug。Bug是良好軟件的宿敵。軟件開發者必須對自己工作的指令充滿信心，需要在開發過程中盡可能早地發現錯誤，問題發現的時間越早，發現的數量就越多，造成的成本和麻煩也就越少；（2）正確。代碼必須符合所有相關的標準和需求。確保所有的變量都具有正確的類型。例如，不會出現數字溢出。注釋必須非常正確。代碼必須符合內存大小或性能的需求，檢查對庫的使用是否正確，以及所有的函數參數是否正確。代碼需要經過驗證，以確定它與需求和功能規范相符合；（3）完整。代碼必須實現了整個功能規范。它必須令人滿意地通過了集成和調試，并通過了所有的測試，且測試套件必須全面；（4）結構良好。檢查已實現的設計是否可靠，代碼是否易于理解，以及是否沒有重復或多余的代碼。例如，查找是否有任何明顯的復制粘貼式編程；（5）可預知。不應該存在任何不必要的復雜性和無法預料到得以外。代碼不應該自我修改，不應該依賴神奇的默認值，也不應該包含出現無限的循環或遞歸的可能性；（6）健壯。代碼應該是防御性的。只要可能，它就要防止可能檢查到的零作為除數、數字溢出范圍等運行錯誤。所有的輸入都應接受檢查。不僅是函授的參數，還有程序的輸入。代碼能處理所有的錯誤情況，并且異常安全，可捕捉到所有適當信號；（7）數據檢查。對C語言風格的數組訪問執行邊界檢查。避免了其他類似的內部數據訪問錯誤。多線程代碼正確地使用了互斥，以防止競爭情況和死鎖的出現。所有系統/庫調用的返回值都經過了檢查；（8）可維護。軟件開發者在使用注釋時要明智。代碼處于正確的修訂控制之下。有適當的配置信息。代碼的格式與公司的內部標準相吻合。編譯的時候要很平靜，不會出現不正當的警告。

4結論

總之，代碼審查對于任何高質量的軟件產品生產來說都很關鍵，因為它不僅是對源代碼開發有用，規范文檔和需求列表也可有類似的審查過程。代碼審查的成功，在很大程度上取決于采取積極態度的作者和審查人員。審查的目的是通過集體協作改善代碼質量，而不是指責某人或證明實現決策的正確性。它是軟件開發過程中的一個重要部分，有助于保障代碼的高質量。

作者：張如云單位：徐州機電工程高等職業學校