開發人員之間隨機的互相閱讀代碼，檢查其編寫正確與否的代碼檢查方式。
基本介紹
- 中文名：代碼走讀
- 外文名：Code review
- 實質：代碼檢查方式
- 作用：檢查其編寫正確與否
- 目的：分為四個層次
- 職能：找編譯器中的設計陷阱
- 關係：效地結合
內容簡介,單元測試,方法介紹,同行評審,
內容簡介
代碼走讀根據目的的不同，可以分為四個層次：
1、檢查是否符合編程規範；
2、尋找編譯器中的設計陷阱；
3、快速理解原始碼，找出流程設計中的問題；
4、對原有代碼的重構。
檢查是否符合編程規範
編程規範融合併提煉了許多人多年開發程式語言程式積累下來的成熟經驗，幫助編程者形成良好的編程風格，提高源程式的可讀性和可維護性，降低出錯的機會，迅速跨入業已存在的且具有相當高度的技術層次，並能夠為提高代碼的復用性提供積極的參考。
找編譯器中的設計陷阱
術語“陷阱”的發展歷史並不明確，而且它有多種定義方法。本文定義為編程和設計過程中常見的和可防止的問題，能順利通過編譯，沒有任何警告和錯誤信息，而且計算機嚴格按照作者寫明的代碼執行，但是結果卻不是作者期望的。許多IT人士都知道，市場上有很多新的編譯器，它們可以捕獲大部分程式錯誤，但遺憾的是，仍有許多錯誤是編譯器不能發現的。打個比方，拼寫檢查程式是用來查找拼寫錯誤的，但是，如果單詞DOG被錯誤地寫為CAT，您能指出單詞CAT（實際是DOG）中的拼寫錯誤嗎？很顯然，不能。因為這個單詞可順利通過拼寫檢查程式。這裡描述的陷阱所包括的範圍廣泛，從較容易的語法問題，基本設計缺陷，到完全錯誤的行為。利用正確的使用方法來說明這些常見的誤解和誤用，可以防止編程者出現類似的問題，並防止新一代程式設計師重複過去的錯誤。
快速理解原始碼，找出流程設計中的問題
無論是溝通程式的操作，還是將知識存儲為可執行的形式，軟體的原始碼都是最終的介質。我們可以將原始碼編譯成可執行程式，也可以閱讀代碼來了解程式的功能及其工作方式，還可以修改原始碼來改變程式的功能。大多數編程課程和書籍都將重點放到如何從零開始編寫程式上。然而，在軟體系統的工作投入中，40%～70%是用在系統首次編寫完整之後，這些工作一定涉及到閱讀、理解、以及修改最初的代碼。另外，遺留代碼持續不斷、不可避免的累積；對軟體重用的強調；軟體行業中人員的高流動性；同時，開放原始碼開發工作和協同開發過程（包括外包、代碼走查和極限編程）日益重要，使得代碼閱讀成為當今軟體工程師的一項基本功能。此外，閱讀實際的、編寫良好的代碼，可以更加深入地了解如何改造與編寫重要的系統，僅僅編寫小型的程式學不到這種能力。有時，閱讀代碼是一件不得不去做的事，比如：為了修復、檢查或改進現存的代碼，都必須去閱讀相關的代碼。有些時候，閱讀代碼也許是為了了解程式是如何工作的，對於任何能夠“打開蓋子”的事務，作為工程技術人員，我們總是傾向於分析一下它的內部結果。您閱讀代碼可能是想提取可供重用的材料，或者僅僅是出於個人興趣，將代碼作為一種文獻。每種原因的代碼閱讀都有自己的一套技術，強調不同方面的技能。代碼走讀中的閱讀原始碼強調的是通過快速理解原始碼，找出流程設計中的問題這個目的。
對原有代碼的重構
重構的含義是：在不破壞可觀察功能的前提下，藉由搬移、提煉、打散、凝聚……，改善事務的體質、強化當前的可讀性、為將來的擴充性和維護性做準備、乃至於在過程中找出潛在的“臭蟲”，就成了大受歡迎的穩步前進的良方；
單元測試
只有快速理解了原始碼才可以完成單元測試，或者說快速理解原始碼是完成單元測試的前提；利用單元測試可以幫助更好地重構；代碼走讀發現的問題比單元測試發現的更多、更快和更早；單元測試發現不了不滿足編程規範的問題
方法介紹
形式上可以遵從同行評審的結構化的正規檢視、走查、單人複審等；人工走讀時，檢查單可以按照頭腦風暴、親和圖、魚骨圖方法形成系統化的檢查樹和處理機制；工具走讀可以藉助一些商用的測試工具和自己開發的輔助工具進行走讀。
同行評審
同行評審是一種比較偏管理的方法，評審的材料可以包括文檔和代碼，對於代碼的同行評審就是代碼走讀，本文講的代碼走讀偏重於技術層面的方法，兩者只有有效地結合才能更大地發揮它們的威力！
