google確實是一家很酷的公司。不論是在公司內部或是外部，google都做了很多讓人讚嘆的的事情。這裡我想介紹一些不涉及商業機密，但鮮為外人所知的事情。
google的**之所以優秀原因其實很簡單：他們非常重視**審查。**審查並不是google獨有的，它被公認為是乙個很好的（提高**質量的）手段，很多人已經在日常開發中採用**審查。但我還沒有看到哪一家大公司（像google這樣）應用得如此廣泛。在google，任何的產品或者專案**在檢入（**倉庫）之前都需要進行有效的審查。
每個人都要參與**審查，而且這裡我指的不是非正式的審查：它是軟體開發環節中非常重要而且通用的規則。不僅是產品**，所有的**都需要進行審查。審查**不需要投入很多的精力，但是（與不做審查相比）產生的效果卻是天壤之別。
關於**審查（code review），jonathan danylko 的看法是「**要經常檢查（包括自查和其他同事檢查）
。不要把別人的檢查，看成是對**風格的苛求。應該把它們看作是有建設性的批評。對個人來說，經常檢查你的**並且自問，「我怎樣才能寫得更好呢？」 這會加速你的成長，讓你成為乙個更優秀的程式設計師
。」你能從**審查中收穫什麼？
事實顯而易見，有另外乙個人檢查即將提交的**，能夠幫助找到bug。這是**審查眾所周知且經常被提及的好處。但依據我的經驗，這是最沒有價值的乙個好處。人們確實可以在**審查中找到bug。然而坦率地說，在**審查中找到的bug絕大多數都是一些**作者花上幾分鐘就能找到的小bug。那些真正需要花時間才能找到的bug在**審查中是檢查不到的。
**審查最大的好處在於它是一種社交的途徑。如果你程式設計的時候就知道會有同事檢查你的**，那麼你的程式會有所不同。你寫的**會更加整潔，有著較好的注釋，結構也組織的不錯——因為你知道會有人來檢查你的**，而且你很在意他們的意見。如果沒有**審查，你知道**會在最後才會審查。因為不是馬上就要檢查，所以對你而言並不緊迫，因而你不會想著先自檢一遍。
**審查還有乙個更大的好處，就是可以分享知識。在很多的開發團隊中，每個人都會負責並且專注於乙個核心模組。除非別的同事負責的模組出現問題導致自己的**不能執行，否則他們是不會去關注別人的工作。這樣產生的結果是，每乙個模組的**只有乙個人比較熟悉。假如事不湊巧，那位程式設計師正好休假或者離開了公司，那麼沒有人了解那些**了。如果有**審查的環節，那麼至少會有兩個人熟悉**——**的作者和審閱者。審閱者雖然沒有作者對**那麼了解——但是他同樣熟悉**的設計和結構，這些資訊是無價之寶。
當然，沒有什麼事情是那麼簡單的。以我的的經驗看來，要做好**審查需要一段時間練習。我注意到經驗不足的審閱者通常會落入一些**審查的陷阱，這些陷阱往往會造成很多的麻煩，給那些希望嘗試**審查的人們留下了壞印象，成為了他們採納**審查的乙個主要障礙。
**審查最重要規則是對即將提交的**中查詢問題——你需要做的就是確認**是正確的。而通常會犯的乙個錯誤，也是剛剛接觸**審查的新手容易犯的乙個錯誤，即審閱者會判斷這段**是否按照自己思路來實現。
當有乙個問題需要解決時，通常會有幾十種的辦法。當選定乙個解決方法時，會有百萬種**實現。因此，作為乙個審閱者，你的工作不是確保**是按照你的方式來編寫的——因為這是不可能的事情。審閱者的工作是確保原作者編寫的**是正確的。如果你沒有遵守這個規則，你可能會到處碰壁，審查結束時你的心情很糟糕，對你來說肯定不是一件好事情。
問題在於這是不自覺就會犯的乙個錯誤。假定你是乙個程式設計師，當你在看乙個問題的時候，你會得到乙個自己的解決方案——並且你認為你看到的就是這個問題（應該採用的）解決辦法。如果想要成為一名好的審查者，你需要知道這是不對的。
第二個誤區就是人們感覺一定要說點什麼（才算是做了**審查）。**的作者花了很多的時間和精力來編寫**——你難道不應該說點什麼嗎？
答案是：你不應該。
如果只是說「哦，這看起來這不錯！」，這永遠沒錯。反之，如果你不斷地去查詢一些「問題」並加以指責，那麼我肯定你的信譽會蕩然無存。如果你不斷地去製造一些事情來說些什麼，那麼**的作者會認為，當你的言論只是為了避免冷場。從此，你的意見不會受到重視。
第三個誤區就是速度。你不應該匆忙完成一次**審查——但是也不要拖延。你的同事在那裡等著你的審查結果。如果你和同事不願意抽出時間來做**審查或者一直拖延，大家會對這次的審查感到厭煩，也會認為以後的**審查也只會帶來麻煩。看起來好像**審查會打斷你的工作，其實不必如此。你不必要在別人要求你審查的時候馬上丟掉手頭上的事情。但是在幾個小時之內，當你工作中間休息的時候——喝杯茶，去一下洗手間或者聊聊天，散散步。當你再回來工作的時候，你可以開始並完成這個**審查。如果你這麼做了，沒有人會站在你身邊一直等著你給出審查結果。
我們在google所做的事情中另外乙個讓我感到異常有效、有用的制度是嚴格的編碼規範。
在到google工作之前，我一直認為編碼規範沒有什麼用處。我堅信這些規範都是官僚制度下產生的浪費大家的程式設計時間、影響人們開發效率的東西。
我是大錯特錯了。
在谷歌，我可以檢視任何的**，進入所有谷歌的**庫，我有權檢視它們。事實上，這種許可權是很少人能擁有的。但是，讓我感到驚訝的卻是，如此多的編碼規範 —— 縮排，命名，檔案結構，注釋風格 —— 這一切讓我出乎意料的輕鬆的閱讀任意一段**，並輕易的看懂它們。這讓我震驚 —— 因為我以為這些規範是微不足道的東西。它們不可能有這麼大的作用 —— 但它們卻起到了這麼大的作用。當你發現只通過看程式的基本語法結構就能讀懂一段**，這種時間上的節省不能不讓人震撼！
反對編碼規範的人很多，下面是一些常見的理由，對於這些理由，我以前是深信不疑。
這是浪費時間！
我是乙個優秀的程式設計師
，我不願意浪費時間幹這些愚蠢的事。我的技術很好，我可以寫出清晰的、易於理解的**。為什麼我要浪費時間遵守這些愚蠢的規範？答案是：統一是有價值的。就像我前面說的 —— 你看到的任何的一行** —— 不論是由你寫的，還是由你身邊的同事，還是由乙個跟你相差11個時區的距離人寫的 —— 它們都有統一的結構，相同的命名規範
—— 這帶來的效果是巨大的。你只需要花這麼少的功夫就能看懂乙個你不熟悉(或完全未見過)的程式，因為你一見它們就會覺得面熟。
我是個藝術家！
這種話很滑稽，但它反映了一種常見的抱怨。我們程式設計師
對於自己的編碼風格通常懷有很高的自負。我寫出的的**的確能反映出我的一些特質，它是我思考的一種體現。它是我的技能和創造力的印證。如果你強迫我遵守什麼愚蠢的規範，這是在打壓我的創造力。可問題是，你的風格裡的重要的部分，它對你的思想和創造力的體現，並不是藏身於這些微不足道的句法形式裡。(如果是的話，那麼，你是乙個相當糟糕的程式設計師。)規範事實上可以讓人們可以更容易的看出你的創造力
—— 因為他們看明白了你的作品，人們對你的認識不會因不熟悉的編碼形式而受到干擾。
所有人都能穿的鞋不會合任何人的腳！
如果你使用的編碼規範並不是為你的專案專門設計的，它對你的專案也許並不是最佳方案。這沒事。同樣，這只是語法：非最優並不表示是不好。對你的專案來說它不是最理想的，但並不能表明它不值得遵守。不錯，對於你的專案，你並沒有從中獲得該有的好處，但對於乙個大型公司來說，它帶來的好處是巨大的。除此之外，專門針對某個專案制定編碼規範一般效果會更好。乙個專案擁有自己的編碼風格無可厚非。但是，根據我的經驗，在乙個大型公司裡，你最好有乙個統一的編碼規範，特定專案可以擴充套件自己特定的專案方言和結構。
我善長制定編碼規範！
這應該是最常見的抱怨型別了。它是其它幾種反對聲音的混合體，但它卻有自身態度的直接表現。有一部分反對者深信，他們是比制定編碼規範的人更好的程式設計師，俯身屈從這些小學生制定的規範，將會降低**的質量。對於此，客氣點說，就是胡扯。純屬傲慢自大，荒唐可笑。事實上他們的意思就是，沒有人配得上給他們制定規範，對他們的**的任何改動都是一種破壞。如果參照任何一種合理的編碼規範，你都不能寫出合格的**，那只能說你是個爛程式設計師。
當你按照某種編碼規範進行程式設計時，必然會有某些地方讓你搖頭不爽。肯定會在某些地方你的編碼風格會優於這些規範。但是，這不重要。在某些地方，編碼規範也有優於你的程式設計風格的時候。但是，這也不重要。只要這規範不是完全的不可理喻，在程式的可理解性上得到的好處會大大的補償你的損失。
但是，如果編碼規範真的是完全不可理喻呢？
如果是這樣，那就麻煩了：你被糟蹋了。但這並不是因為這荒謬的編碼規範。這是因為你在跟一群蠢貨一起工作。想通過把編碼規範制定的足夠荒謬來阻止乙個優秀的程式設計師寫出優秀的**，這需要努力。這需要乙個執著的、冷靜的、進了水的大腦。如果這群蠢貨能強行頒布不可用的編碼規範，那他們就能幹出其它很多傻事情。如果你為這群蠢貨幹活，你的確被糟蹋了 —— 不論你幹什麼、有沒有規範。(我並不是說罕有公司被一群蠢貨管理；事實很不幸，我們這個世界從來就不缺蠢貨，而且很多蠢貨都擁有自己的公司。)
程式設計師應該養成的良好習慣
1 總結自己一天任務的完成情況 最好的方式是寫工作日誌，把自己今天完成了什麼事情，遇見了什麼問題都記錄下來，日後翻看好處多多 好記性不如爛筆頭。2 考慮自己明天應該做的主要工作 把明天要做的事情列出來，並按照優先順序排列，第二天應該把自己效率最高的時間分配給最重要的工作 worklist。計畫很重要...
程式設計師應該養成的良好習慣
1 總結自己一天任務的完成情況 最好的方式是寫工作日誌，把自己今天完成了什麼事情，遇見了什麼問題都記錄下來，日後翻看好處多多 好記性不如爛筆頭。2 考慮自己明天應該做的主要工作 把明天要做的事情列出來，並按照優先順序排列，第二天應該把自己效率最高的時間分配給最重要的工作 worklist。計畫很重要...
好的程式設計師習慣養成
好的程式設計師習慣養成 前言 對於學習某一新的事物，如果對其沒有興趣，那麼對於這件事物的吸收的效率會大大下降。對此，僅以此篇獻給那些正在學習拼搏的人們 增加知識儲備，培養興趣的基礎 知識是興趣產生的基礎條件，因而要培養某種興趣，就應有某種知識的積累，如要培養程式設計的興趣，就應先接觸一些程式設計的作...