這篇文章講了什麼？
如題，本屌入職100天之後的經驗和教訓，具體包含：
- 對開發的一點感悟。
- 對如何提問的一點見解。
- 對Google開發流程的吐槽。
如果你
- 打算去國外工作。
- 對Google的開發流程感興趣。
- 想成為一個不錯的開發者。
那麼請繼續閱讀。
- 覺得使用英文單詞和縮略語就是裝逼（例如此人LRui@和其代表作）。
- 無法忍受一個來自新人的言論。
那麼請點選頁面左上角或右上角的關閉，謝謝。
正文
差別
不同于一般公司，Google所使用的技術絕大多數是自己的技術，基礎類庫、檔案IO、網絡通信，什麼都是自己的。盡管開源了不少，但更多的東西是不對外開放，這樣就帶來兩個問題：
- 缺乏學習資源（由于Google技術大多不對外開放，是以是沒有書籍可供參考，隻能通過内部教程和文檔再加上項目代碼，自己去一點點摸索）。
- 出了問題沒法Google（廢話，Google會把自己的内部技術放到Google Search上麼），也沒法Stackoverflow（同前）。
以上兩點對于本屌這個曾經的微軟系程式員打擊極大——至少本屌從來沒有在沒有書看且沒法Google的環境下寫代碼做項目。
經驗&教訓
- 使用郵件清單（Mail list），讨論組（Discussion group）。
- 學會如何使用Email提問。
- 如果必要，聯系代碼原作者。
文檔vs代碼
Google的文檔是非常出色的——無論是設計文檔還是API文檔都很專業，但前提是你的項目有文檔。
比如本屌做第一個項目時，打開項目文檔時看到的是這貨：
然後問mentor要文檔時mentor的表情：
另外的一個問題是同步，你看到的文檔很有可能不是最新的：
是以即便按照文檔編寫代碼，也會有一定的幾率出錯：
- 沒有依照文檔，代碼有問題。
- 依照文檔，但文檔有問題。
- 文檔和代碼都有問題。-_-
在被以上可能性痛虐三周之後，本屌終于領悟到凡事都要靠代碼這個硬道理，走上了寫什麼之前都要看三遍代碼（文檔代碼，項目實作代碼，項目引用代碼）的康莊大道。
- 代碼即是文檔，引用即是示例代碼。
- 文檔隻是輔助。
提問
看文檔讀代碼并不能解決所有的問題，如果一個任務糾結了15分鐘還沒有頭緒，準備提問吧。
找準提問對象
每個人都有自己擅長的領域，問正确的人正确的問題會極大提高工作效率，反之亦然。
這就要求對身邊的同僚有一個了解——知道對方擅長什麼，不擅長什麼。剛剛入職時本屌有一個毛病，就是把所有的問題都傾瀉在mentor一人身上——一開始mentor會耐心的解答，但是時間長了就發現他的反應變的越來越慢，後來經Manager提醒才恍然大悟，開始和每個同僚交流，并閱讀他們的CV以了解他們的經曆，提問問題的效率大大增加。
清晰描述上下文和目标，而非實作
提問的首要因素是描述你想做什麼（What you want），而不是描述你做了什麼（What you've done）——xxx對這個話題有精彩的描述。
比如說在GuiceBerry裡如何使用GuiceBerryRule引用Guice注入的對象是一個很蠢的問題，因為：
- 涉及到了實作。
- 問題本身就是錯誤的。
而如何在JUnit下實作一個全局的Pre/Post Method而不使用繼承，就是一個不錯的問題：
- 明确的上下文和目标。
- 邏輯合理，且不涉及任何實作（Implementation）。
尋找Pointer，而非Value
多數情況下解決問題需要的隻是一個連結（Pointer），而并不需要整個方案（Value），好比C語言為了提高效率傳遞Pointer而非Value，Caller給你一個Pointer，Dereference的任務交給Callee即可。
另一個比方是問路，一個正常的問路人絕壁不會要求指路人把他帶到目的地去——一條正确的路線或一份清晰的地圖就足夠。
- 問正确的人正确的問題。
- 尋求Pointer，而非Value。
交流
話題
盡管UK充斥着中國制造，但中國對于他們來說仍然是一個神秘的國度，是以初次和外國人聊天聊China是個不錯的話題，Food、Kungfu和Weather都是不錯的選擇。
然而不能總聊China——不停地說自己的國家誰都會煩，這時就需要去了解他們的文化，除了技術以外，本屌比較喜歡聊新聞、電影和電視劇。
活動
融入國外生活的另一個方式是參加他們的活動——每次室内攀岩、桌球或是乒乓本屌都不會落下，算是乒乓外交吧。
比較有趣的是他們都認為中國人個個都是乒乓高手，盡管本屌的水準并不怎麼樣。
此外在國外Pub和Party也是重要的社交場合，不過電影裡看到的不太一樣。前者是幾個人邊喝酒邊扯淡，後者是一堆人邊喝酒邊扯淡，由于本屌的英語水準實在拙計，是以這種場合一般隻有練聽力的份 -_-
- 對于天性悶騷的天朝IT屌而言，運動是一項很好的融于外國人圈子的方式。
- 和外國人交流的難點在不在于1v1私聊，而在于1vN群聊，文化背景的缺失加上不同的口音使得交流難上加難。
- 用Blog練習Formal writting，用Reddit上練習Informal speaking。
開發
程式設計 V.S. 開發
首先說說本屌對程式設計和開發的了解。
- 程式設計（Programming）偏向于計算機科學（Computer Science）這一端，涉及到離散數學，資料結構，算法設計，人工智能等等，側重于計算機，目标在于讓計算機完成一個指定的任務。
- 開發（Development）偏向于軟體工程（Software Engineering）這一端，涉及到進度管理，軟體架構，互動設計等等，側重于團隊，目标在于讓團隊按時傳遞可用的軟體。
- 學校裡側重程式設計，公司裡側重開發。
- 程式設計為開發提供理論基礎，開發把程式設計轉化為商業價值。
應屆IT屌從學校到公司的最大的轉變就是從程式設計到開發的轉變：
- 一部分人接受轉變，從各種項目經驗中吸收教訓，成為卓越的開發者（Developer，比如DHH）
- 一部分人拒絕轉變，鑽研基礎理論，成為卓越的研究者（Researcher，比如Wangyin）
- 至于剩下的——就是真正意義的碼農（Code monkey，恕不舉例）。
- 本屌的理論基礎薄弱+天賦一般，程式設計這條線路走不通，是以成為一個專業開發者是本屌的目标，也是接下來幾年的努力方向。
- 準備這個書單做起。
代碼評審
Google對代碼品質要求很高，任何送出的代碼都需要自備測試，且需要得得到具有代碼審查資格的專家開發者的認可，即LGTM（Looks Good To Me）。是以Google寫代碼大概是這樣的：
最慘的當屬第一次代碼評審
至于本屌的第一次代碼評審
不到200行程式，大改四次，小改155處，耗時三周。
搞的本屌感覺此生都不會再愛了 -_-
但代碼審查仍然是必須的：
- 團隊中編寫代碼不同于個人程式，需要遵守很多規則和潛規則：大到基本的Coding Style Guideline，小到Project-specific Convention。
- 英語詞彙量很重要，不同的詞彙會帶給代碼不同的含義，例如build，create，establish，calculate和compute都表示建構一個對象，但它們的引申義就很不一樣。
熟悉關鍵技術
關鍵技術，就是自己日常工作所依賴的技術以及工具。使用頻率越高，越需要熟練。
本屌在入職頭兩個月就犯了老毛病——啥都想學，啥都想碰，看這個人說Parserc就去搞，看那個人說Haskell炫就去做，結果連個屁都沒搞出來，效率還一落千丈。
直到春節請了兩周假自省了下，才發現問題所在：自己仍然在用學校時的方式在公司工作——什麼都好奇，什麼都想學一把。
但問題在于現在是在工作，有明确的任務和時間點，而且本屌遠遠做不到遊刃有餘，這會玩個人拓展不是找事麼。
于是春節回去後重新制定了學習目标：
- 熟練Google的内部工具鍊，通讀這些工具的設計文檔，架構文檔和使用手冊。
- 熟悉Google的基礎類庫，閱讀文檔，做練習，并閱讀其實作
- 熟悉自己項目架構和關鍵代碼。
然後每周除了周六都在折騰上面的一坨。效果很顯著——開發效率比之前高了至少一倍，不少問題變的可以獨立解決。
- 人的精力是有限的，尤其是工作之後。
- 工作的主線任務是高效完成工作，拓展能力等支線任務等主線任務搞妥了再搞也不遲。
- 學習很重要，但要計算機會成本——不是所有的學習都能帶來足夠的回報。
- 80/20配置設定，8成時間學習工作相關内容（這裡指直接相關），2成時間學習工作無關内容。
總結
- 學會用各種方式問正确的人正确的問題。
- 80%時間熟練工作技術，20%時間個人拓展。
- 理論+實踐，不斷疊代，學習如何成為一個卓越的開發者。
此外如果覺得自己水準不錯，歡迎站内信我進行内部推薦。
以上。