對于代碼審查的認識和了解

　　代碼審查應該成為任何重要的軟體開發工作中一個基本制度。并不單指産品程式――而是所有東西。而且代碼審查也不需要花費很多的時間和人力，但它卻能發揮巨大的效果。

　　從代碼審查裡能得到什麼？

　　對于代碼審查的認識，在代碼送出前，用其他人的眼睛檢查一遍，防止bug混入。這是最常見的了解，也是對代碼審查的好處的最廣泛的認識。

　　但是，在我看來，這并是它最不重要的。人們确實可以在代碼審查中找到一些bug。可是，這些在代碼審查中能發現的絕大部分bug，很顯然，都是微不足道的bug，程式的作者花幾分鐘的時間就能發現它們。真正需要花時間去發現的bug不是在代碼審查裡能找到的。

　　代碼審查的最大的好處在于,如果你是程式員，而且知道将會有其他同僚來檢查你的代碼，你程式設計态度就完全不一樣了。你寫出的代碼将更加整潔，有更好的注釋，更好的程式結構。因為你很在意别人對你的程式的看法。沒有代碼審查，你可能會認為，你寫的程式基本不會有人看到，除非有人用到了，它不會給你帶來同等的緊迫感。除此之外，還有一個非常重要的好處。代碼審查能傳播知識，培養分享的氛圍。在很多的開發團隊裡，經常每一個人負責一個核心子產品，每個人都隻關注他自己的那個子產品。除非是同僚的子產品影響了自己的程式，他們從不互相交流。這種情況的後果是，每個子產品隻有一個人熟悉裡面的代碼。如果這個人休假或辭職了，其他人則束手無策。通過代碼審查，至少會有兩個人熟悉這些程式。審查者雖然并不能像程式的作者一樣對程式和業務十分了解，但他會熟悉程式的設計和架構還有業務的架構，這個極其重要的。

　　剛開始，大家在代碼審查時經常會犯一些錯誤，導緻很多麻煩，特别是一些缺乏經驗的審查者，他們在代碼審查的時候會給了程式開發者的很不好的感覺，最終導緻程式員抵觸代碼審查制度。

　　針對所有人的審查

　　　　* 首先必須承認：審查者都是根據自己的程式設計習慣來評判别人的代碼。是以很多程式設計上的主張都是一種個人觀點。是以應該讨論它們的利與弊，提出你傾向的觀點，迅速的在團隊達成一緻。

　　　　* 對與審查者和被審查者，大家覺得有壓力，感覺非要說點什麼，非得找出點什麼問題出來才好，别人都提出了點什麼，自己多少也得說點吧。（完全不需要。隻說一句“這段程式寫的真不錯。”就可以了）

　　　　* 盡量使用提問或是建議，而不是指令。(“把這個變量命名成:user_id,你覺得怎樣？”)

　　　　* 請求說明。(“我不明白。你能解釋一下嗎？”)

　　　　* 避免代碼的歸屬之争。(“我的”，“不是我的”，“你的”)

　　　　* 不要諷刺,嘲笑别人的代碼,避免使用一些會被認為或可能會被認為是有關人身特征的詞語。(“笨蛋”，“愚蠢”，“傻逼”，“二”)要把所有人都看作是有魅力的、聰明的、善意的。

　　　　* 要明确。要記着并不是每個人都能了解你的意圖。

　　　　* 要謙虛。(“我不能确定——我們來分析一下。”)

　　　　* 不要用“總是”，“從不”，“永遠”，“毫無…”這樣的修辭語。

　　　　* 如果對于某個代碼，有太多的我不了解或大家都有不同的看法，可以組織一個讨論會，或是技術分享，然後把你們的交流形成共識，總結成文檔

　　　　* 代碼審查，不能時間太短，這樣沒有太多的效果，但是時間也不能太長。畢竟大家還有其他的工作要做。

　　讓别人審查你的代碼

　　　　* 首先要達成共識，了解審查是對事不對人。審查的是你的代碼，而不是你。

　　　　* 對審查者的建議表示肯定和感激。(“對，你說的沒錯。”,“謝謝提醒。我會把它改正。”)

　　　　* 解釋為什麼代碼寫成這樣，可以說明這段代碼的業務邏輯。

　　　　* 整理所作的改動，不必當場改掉，複雜的程式，也可以在以後的疊代中重構它們。

　　　　* 努力站在審查者的立場上了解,同樣也要努力了解作者的立場。。

　　　　* 針對你感覺非常好的地方以及不是很好的地方與開發者交流。

　　　　* 找出既能解決問題又能簡化代碼的方法，讓代碼變得簡單。

　　　　* 提出你的實作方案，但要表現出作者也在考慮這種方案。(“你覺得這裡用一個自定義校驗如何？”)