代碼走查(code walkthrough)是一個開發人員與架構師集中討論代碼的過程。代碼走查的目的是交換有關代碼是如何書寫的思路，並建立一個對代碼的標準集體闡述。 在代碼走查的過程中，開發人員都應該有機會向其他人來闡述他們的代碼。 通常地，即便是簡單的代碼闡述也會幫助開發人員識別出錯誤並預想出對以前麻煩問題的新的解決辦法。
基本介紹
前言,原因,兩者關係,
前言
當團隊成員對代碼進行討論的時候，他們的討論應該集中到一些重要的話題上，比如算法，基於對象的編程，類設計。 然而，許多代碼走查不會做這些事，通常代碼走查是枯燥的，煩人的，機械的。 這就是為什麼許多開發人員討厭這些。要使得代碼走查變得很有效，那么這個過程就必須是有趣的，有創造性的。 很經常地，代碼走查退化成了僅是關注於強制代碼標準－－一個可以被自動執行的實踐。當這種情形出現後，團隊通常會覺得代碼走查沒有價值，然後將代碼走查從他們開發過程中去除掉。這樣便失去了他們可以從正確地執行代碼走查的過程獲益的機會。
--來自：天空之城
原因
代碼可讀性這個話題一直以來都是備受關注，但是可讀性高與不高卻沒有統一的標準。畢竟各個公司，甚至於各個項目的規範都是不一樣的。我們不能說一個抽象性極好，靈活度極高卻讓人十天半個月都難以搞清楚的代碼的可讀性高，也不能說一個長達幾千行卻從頭至尾邏輯性比較好的代碼的可讀性差。那么怎樣的代碼才算是合理的，才算是可讀性高的呢？我想不同之中必有共性，那就是經過走查的、能夠被項目組其他成員接受並能儘快看懂的代碼就是可讀性好的。
為什麼要做代碼走查呢？
要對代碼可讀性做走查，這需要人力、物力、以及項目寶貴的時間。對於一個項目來說，成本是一個重要的考慮因素，然而走查無疑會增加項目的成本，那么為什麼還要做走查呢？其實任何一個項目經理都清楚一個成功的項目都是難以一蹴而就的，開發過程必然會遇到各種各樣的問題和阻力，這也驗證了那句老話：“軟體開發中唯一不會變的就是，需求永遠會變化”。我們也清楚問題越早的被發現那么損失就會越小，補救花費的時間就會越少，自然成本就越低。但是我們有多大的機會可以儘早的發現問題呢？這不是我們說早發現問題，問題就會跟我們招手說：“看你態度不錯，就讓你早發現吧！”這么簡單的。疊代開發為什麼會出現，瀑布式開發為什麼難以應對大型的商業、行業項目？思考一下我們不難發現，客戶難以一次性的、整體的、詳盡的把自己想要的東西表達清楚，只有當客戶看見實實在在的東西之後，他才更明確自己想要什麼。好比我們去買褲子，你告訴一個人說：“我要一條簡約的牛仔褲”；然後那個人去幫你買，但是具體的顏色你確定么，是黑色還是藍色？衣服的口袋你確定么，是有扣子的還是沒扣子的？只有當你真真切切的到專賣店裡面，看到了試過了你才能確定：我要的就是那條180的藍色的口袋上沒扣子的XXX牌的褲子。也就是說我們很少能夠儘早的從客戶口中獲得問題，除非我們指著我們做出來的東西說：看看，這是不是你想要的。既然如此，要控制的不是儘早的去發現問題，而是如何在問題出現之後儘早的找出問題所在，並解決問題，進而降低項目的成本。
其實軟體開發的主要時間是花費在調試上，然而調試中花費的大部分時間又在於讀代碼。倘若之前開發該模組的人員已遠在天邊，面對幾千行混亂無序的代碼任誰都難以承受。因而花費成本在代碼走查上是值得的，而且是必須的。可惜的是，現在很少有人去關注代碼的規範性、可讀性，甚至在大公司都是如此。項目管理者過於注重項目的進度，只要開發者把自己的任務做完了，很少有人去關注他寫的代碼，甚至開發者自己都不會再去看。
代碼走查有何好處呢？
首先代碼走查可以提高軟體的質量，以及可維護性。這樣就可以減少查找錯誤的時間，提高解決bug的效率，提高開發效率的同時降低後期的維護成本。
其次，經過走查的代碼是能夠迅速被項目組其他成員看懂的，這樣有利於項目其他成員更全面的了解業務，對於成員之間交流也有很好的促進作用，當其中負責某個模組的開發人員離職之後其他人員能夠迅速的接手相關的開發，並能夠儘快的培養新人彌補空缺。
最後，代碼走查的過程是總結提高的過程，也是交流的過程，可以有效的提高開發人員的技術水平以及業務素養，增強公司的競爭力，通過總結交流甚至可以從不同項目中提取共性，做出相關產品，從而形成公司自己的核心競爭力，做到行業領先。
如何去做代碼走查？
從參加人員來說，應該是項目的整體參與者，如果項目太大，整體參加的成本很高，那么可以以模組為組進行走查。因為他們之間負責的業務是緊密相關的，使用的技術是接近程度比較大的，因而開發的規範應該是統一的。
從走查內容來說，應該是代碼的命名規範，以及組織結構。每個項目都有自己的規範，但是如果項目內部使用不同的規範必然會增加發現問題、解決問題的難度，同時增加後期的維護成本。
從走查時間來說，應該在每個模組開發完成之後進行，便於開發人員之間交流問題以及體會，並且每個人的講解時間不要超過30分鐘，因為模組的業務複雜度不會那么複雜，30分鐘都講不清的業務邏輯如何保證代碼是清晰的。
從走查的結果來說，經過走查的代碼應該是參加成員大部分能認同的，並且參加者每個人都能讀懂的邏輯清晰的代碼，並且通過交流提高項目成員的凝聚力，提高其業務認知度，最好能形成項目之間可以共同使用的產品。
---來自：51testing網站
兩者關係
代碼走查與代碼審查
代碼走查(code walkthrough)和代碼審查(code inspection)是兩種不同的代碼評審方法,
代碼審查是一種正式的評審活動，而代碼走查的討論過程是非正式的。
最近對項目組進行代碼評審，發覺需要對代碼評審中找到的問題進行一下分類，大概可以分成以下幾類問題：
1. Comment
注釋沒寫，或者格式不對，或者毫無意義
2. Coding Standard
沒遵守代碼規範
3. Existing Wheel
重複現成的代碼，或者是開源項目，或者公司已有代碼
4. Better practice
Java或者開源項目，有更好的寫法
5. Performance bottle and Improvement
性能瓶頸和提高
6. Code Logic Error
代碼邏輯錯誤
7. Business Logic Error
業務邏輯錯誤
代碼審查列出問題的類型，並有解決情況報告
