code reivew是保障**質量的實用方法之一，這裡簡單分享下個人code review的經驗。建議只當案例來看，因為不同專案、不同團隊所做的事情、所具備的技術背景也是不同的，當然也會有些通用的點。
先問下，你所在的公司有code review的習慣不？你所在的團隊呢？你個人呢？如果沒有的話，為啥會忽略這個環節呢？
來說下現實情況，大多數公司做的專案，如果按專案規模來看，都是很小的專案，即使是很大的專案，正確的做法也必然會拆分成多個小專案，由多個團隊同時合作完成。在這個前提下，實際每天每個程式設計師提交的**量是很少的，對這麼少的**變更進行code review其實是花不了個人多少時間的。
我覺得完全每天可以抽出半小時，乃至一小時的時間來對別人的**進行review，比如：
只是隨便舉幾個場景的例子，code review形式不限、時間、地點更無所謂。
不同的團隊，不同的專案，在不同的時期，可能對**發布的要求不同：
不管如何，我覺得做專案本身都沒有十足的鐵則，實用就好。
團隊中為什麼要有code review的文化呢？或者說，code review有哪些好處嗎？
從專案角度，很直接，可以提高**質量。從人性弱點上來看，人類總是樂於去發現別人不好的地方的，所以多一雙眼睛，更容易發現**中的壞味道；另一方面，大家內心深處都是樂於追求真、善、美，所以總是希望寫出來的**更加優美。間接上，**質量提高，對於乙個專案的成功，以及乙個軟體的生命週期的延長，是個挺必要的因素，至少微觀上是這樣。
從個人角度，可以大致分兩種。對於初學者學習，從看有經驗人的**過程中，可以學到好的**實踐；對於有經驗的人自省，自然能發現各種不好的，時刻提醒讓自己避免這種不好的**，順便可以幫助別人更好更快地提高，畢竟大家都是從初學者過來的。
從團隊角度，逐漸拉近團隊成員間的水平。儘管團隊中成員各有所長，但在**層面會有共同標桿，共同進步，讓團隊整體實力得到提高。
code review的形式各種各樣，這裡按人數規模來分類。
這個其實是大家都在做的方式，但可能不一定每個人都能做得好，或者說人類總是很難自覺做到從自己身上發現問題，經過一定訓練後逐漸會學會限制這種本能。一種方式可以有所幫助，就是找個木偶講解**，比如：放在桌上的瓦力小機械人或盆栽之類的東西。講出你寫的**的變化，也許就會發現一些問題。
當然，一般都會借助一些工具來幫忙檢查**，比如：各種語言的lint工具或者很多ide本身的功能，在**風格這些偏靜態層面的東西，可以輔助發現一些問題。
另外，隨著程式設計師程式設計經驗的增長，逐漸會注意到**的各種壞味道，這也是給別人做code review的基礎。
這種形式的code review，發現了問題基本上就是立馬糾正了。或者說，自己已經處理了一大半的**壞味道了，剩下可能真的自己都很難發現了，畢竟不是每個人的自省能力都是很高的，所以才有了後面的幾種形式。
這種形式其實也很常見，特別是兩個小夥伴一起協作程式設計的時候，比如：所謂的結對程式設計。當然，也可以不是結對程式設計，比如：兩個人挨著坐，乙個人完成一塊邏輯複雜或稍有難度的**後，需要別人來把把關，這個時候就可以叫上旁別的人幫忙過下**或自己給他講解下**。
如果是結對程式設計，個人認為還是需要兩人水平相當，乙個人在乙個顯示器前寫**，另乙個人在另乙個複製的顯示器前觀察寫的**，有問題隨時溝通，也許兩人各有所長，一人完成某塊他擅長的部分後，兩人交換角色。這個時候，其實是個互相審核的過程。
當然，也有不在少數的人不習慣所謂結對程式設計，那麼就各自幹活，誰覺得需要另乙個人幫忙，就進行code review。這種形式，個人覺得就不必要求兩人水平相當，也可以乙個老手+新手的組合。
另外，個人建議這種形式的code review，最好兩人負責的任務是比較相似或有交集，效果會更好些，不然乙個人不理解另乙個人的業務邏輯，效果上還是會打些折扣的。
這種形式隨著各種code review的工具出現，越來越方便，自然也就越來越流行了。這裡的「2-3」意思並不是只有2個人或3個人，根據需要也可以再增加人數，特別是有很多code review工具輔助的時候。
當然，這個時候個人建議那2個人中，有至少一人是個老手，最好是那種什麼掃地阿姨，背後一站，掃一眼就看出你這有個溢位那種。當然這是玩笑了，意思是得有個有經驗的程式設計師把關。
這種形式的code review，一般是由寫**的人負責記錄問題，當然有code review工具輔助，那就工具自動給你記錄了，省去很多麻煩。這種形式也是最省事的，特別是有了工具輔助，也就沒有時間、地點的限制了。
這種形式有點會議形式，更接近「**審查」了，而不是「**評審」，一堆人圓桌+大屏。如果有場景，的確要用到這種形式的code review那就要慎用了，大家都知道一旦變成開會形式了，那就必然會有會議的各種缺點出現，所以要注意。
當然，一旦開會形式了，針對某個人寫的**，容易變成批評、批鬥，所以還得要注意：
另外，如果沒有強烈的特別的需要，其實還是不要這種形式的code review了，主持人不好或大家意識上不到位，容易浪費時間，效果不一定好。
這種形式的code review，可以指定乙個記錄人，當然就和主持人不是乙個人了，不然主持人即當爹又當媽，功能不要太全哦！當然最好可以是寫**的那個人。
這裡說些其它形式的code review。可以引入某方面的專業人士，比如：安全專家，對**進行安全層面的審計，雖然程式設計師必須具備安全意識，但安全層面的思路有時候還是會有所差異的，畢竟每個人的安全意識水平也參差不齊；再比如，需要對資料庫或作業系統等的特別操作，可以讓這方面的專家幫忙把關，當然如果團隊中有這些型別角色的成員，就再好不過了。
最後，提幾個建議，可能上面說過：
程式設計師這個群體，並不是所有人都是天才級別的，所以當你看到別人寫的爛**時候，也得知道自己當初也可能經歷過那個階段。
本來想說下，哪些地方需要重點code review，但發現場景不同，專案不同，採用的技術不同，大家的關注點都不一樣，如果說成通用的，反而沒有重點了。比如：大段**、大函式、大類、長sql、複雜儲存過程、使用頻率高的功能、**巢狀太深、核心演算法實現、核心介面實現、函式引數過多、使用者輸入校驗是否有安全隱患、異常處理、日誌記錄、業務是否需要事物等等太多了。
另外，不同程式語言、程式設計框架還有不同規範性質的程式設計建議，實在不好說重點。
如果要看重點，估計還是自己去翻一遍《**大全》比較實際。
code review有很多任務具，最原始的莫過於人肉了，這裡簡單列舉下幾個工具，看各自實際情況使用了。一般對這種型別工具或軟體的要求可能有：
可以郵件提醒。
可以很好支援git或svn等版本控制工具。
可以很好支援jenkins等ci工具。
可以支援命令列，方便寫指令碼整合其它工具。
列舉下我知道的工具：
另外，用了工具後，別忘了還有最實用的面對面交流這個人肉工具，也許用慣了冷冰冰的工具外，小夥伴互相看完**後，溫暖的會心一笑還是不錯的。
其實想表達的意思是，遞交的**讓別人review不要太**了，別人會很有壓力的。
後續，有關code review的主題，會具體介紹下幾個常用的code review工具的安裝和使用。
如何進行Code Review
code review應該怎麼做 如何高效迅速的進行codereview 下面推薦一些 code review 工具 crucible atlassian 內部 審查工具 gerrit google 開源的 git 審查工具 github 程式設計師應該很熟悉了，上面的 pull request 在...
如何進行CodeReview
規範主要分為風格規範與設計規範兩大類 主要是文字上的規定，看似表面文章，實際上非常重要。具體有如下幾個方面 1 縮排 2 行寬 3 斷行 空白行 4 括號 5 命名 字母 下劃線 大小寫 6 注釋 a 單行注釋 b 多行注釋 c 變數 方法 類 包注釋 牽涉到程式設計 模組之間的關係 設計模式等方方...
如何進行高效迅速的CodeReview
背景 第一次參加 codereview 不知道該如何去做，也不知道為什麼去做，後來參加多了，慢慢了解了 codereview 的意義，也同時發現 codereview 的效率問題 寫這篇文章，希望本文中的一些建議能夠緩解上述問題，能使新人更快的了解 codereview 的意義和方法，有經驗的人能夠...