Google新人的成長思考

此處重點，本文章來自轉載：Apocalypsa

這篇文章講了什麼？

如題，本屌入職100天之後的經驗和教訓，具體包含：

• 對開發的一點感悟。

• 對如何提問的一點見解。

• 對Google開發流程的吐槽。

如果你

• 打算去國外工作。

• 對Google的開發流程感興趣。

• 想成為一個不錯的開發者。

那麼請繼續閱讀。

如果你

• 覺得使用英文單詞和縮略語就是裝逼（例如此人LRui@和其代表作）。

• 無法忍受一個來自新人的言論。

那麼請點選頁面左上角或右上角的關閉，謝謝。

正文

區別

不同於一般公司，Google所使用的技術絕大多數是自己的技術，基礎類庫、檔案IO、網路通訊，什麼都是自己的。儘管開源了不少，但更多的東西是不對外開放，這樣就帶來兩個問題：

1. 缺乏學習資源（由於Google技術大多不對外開放，所以是沒有書籍可供參考，只能通過內部教程和文件再加上專案程式碼，自己去一點點摸索）。

2. 出了問題沒法Google（廢話，Google會把自己的內部技術放到Google Search上麼），也沒法Stackoverflow（同前）。

以上兩點對於本屌這個曾經的微軟系程式設計師打擊極大——至少本屌從來沒有在沒有書看且沒法Google的環境下寫程式碼做專案。

經驗&教訓

• 使用郵件列表（Mail list），討論組（Discussion group）。

• 學會如何使用Email提問。

• 如果必要，聯絡程式碼原作者。

文件vs程式碼

Google的文件是非常出色的——無論是設計文件還是API文件都很專業，但前提是你的專案有文件。

比如本屌做第一個專案時，開啟專案文件時看到的是這貨：

然後問mentor要文件時mentor的表情：

另外的一個問題是同步，你看到的文件很有可能不是最新的：

所以即便按照文件編寫程式碼，也會有一定的機率出錯：

1. 沒有依照文件，程式碼有問題。

2. 依照文件，但文件有問題。

3. 文件和程式碼都有問題。-_-

在被以上可能性痛虐三週之後，本屌終於領悟到凡事都要靠程式碼這個硬道理，走上了寫什麼之前都要看三遍程式碼（文件程式碼，專案實現程式碼，專案引用程式碼）的康莊大道。

經驗&教訓

• 程式碼即是文件，引用即是示例程式碼。

• 文件只是輔助。

提問

看文件讀程式碼並不能解決所有的問題，如果一個任務糾結了15分鐘還沒有頭緒，準備提問吧。

找準提問物件

每個人都有自己擅長的領域，問正確的人正確的問題會極大提高工作效率，反之亦然。

這就要求對身邊的同事有一個瞭解——知道對方擅長什麼，不擅長什麼。剛剛入職時本屌有一個毛病，就是把所有的問題都傾瀉在mentor一人身上——一開始mentor會耐心的解答，但是時間長了就發現他的反應變的越來越慢，後來經Manager提醒才恍然大悟，開始和每個同事交流，並閱讀他們的CV以瞭解他們的經歷，提問問題的效率大大增加。

清晰描述上下文和目標，而非實現

提問的首要因素是描述你想做什麼（What you want），而不是描述你做了什麼（What you've done）——xxx對這個話題有精彩的描述。

比如說在GuiceBerry裡如何使用GuiceBerryRule引用Guice注入的物件是一個很蠢的問題，因為：

1. 涉及到了實現。

2. 問題本身就是錯誤的。

而如何在JUnit下實現一個全域性的Pre/Post Method而不使用繼承，就是一個不錯的問題：

1. 明確的上下文和目標。

2. 邏輯合理，且不涉及任何實現（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屌從學校到公司的最大的轉變就是從程式設計到開發的轉變：

1. 一部分人接受轉變，從各種專案經驗中吸收教訓，成為卓越的開發者（Developer，比如DHH）

2. 一部分人拒絕轉變，鑽研基礎理論，成為卓越的研究者（Researcher，比如Wangyin）

3. 至於剩下的——就是真正意義的碼農（Code monkey，恕不舉例）。

經驗&教訓

• 本屌的理論基礎薄弱+天賦一般，程式設計這條線路走不通，所以成為一個專業開發者是本屌的目標，也是接下來幾年的努力方向。

• 準備這個書單做起。

程式碼評審

Google對程式碼質量要求很高，任何提交的程式碼都需要自備測試，且需要得得到具有程式碼審查資格的專家開發者的認可，即LGTM（Looks Good To Me）。所以Google寫程式碼大概是這樣的：

最慘的當屬第一次程式碼評審

至於本屌的第一次程式碼評審

不到200行程式，大改四次，小改155處，耗時三週。

搞的本屌感覺此生都不會再愛了 -_-

但程式碼審查仍然是必須的：

經驗&教訓

• 團隊中編寫程式碼不同於個人程式，需要遵守很多規則和潛規則：大到基本的Coding Style Guideline，小到Project-specific Convention。

• 英語詞彙量很重要，不同的詞彙會帶給程式碼不同的含義，例如build，create，establish，calculate和compute都表示構建一個物件，但它們的引申義就很不一樣。

熟悉關鍵技術

關鍵技術，就是自己日常工作所依賴的技術以及工具。使用頻率越高，越需要熟練。

本屌在入職頭兩個月就犯了老毛病——啥都想學，啥都想碰，看這個人說Parserc就去搞，看那個人說Haskell炫就去做，結果連個屁都沒搞出來，效率還一落千丈。

直到春節請了兩週假自省了下，才發現問題所在：自己仍然在用學校時的方式在公司工作——什麼都好奇，什麼都想學一把。

但問題在於現在是在工作，有明確的任務和時間點，而且本屌遠遠做不到遊刃有餘，這會玩個人擴充不是找事麼。

於是春節回去後重新制定了學習目標：

1. 熟練Google的內部工具鏈，通讀這些工具的設計文件，架構文件和使用手冊。

2. 熟悉Google的基礎類庫，閱讀文件，做練習，並閱讀其實現

3. 熟悉自己專案架構和關鍵程式碼。

然後每週除了週六都在折騰上面的一坨。效果很顯著——開發效率比之前高了至少一倍，不少問題變的可以獨立解決。

經驗&教訓

• 人的精力是有限的，尤其是工作之後。

• 工作的主線任務是高效完成工作，擴充能力等支線任務等主線任務搞妥了再搞也不遲。

• 學習很重要，但要計算機會成本——不是所有的學習都能帶來足夠的回報。

• 80/20分配，8成時間學習工作相關內容（這裡指直接相關），2成時間學習工作無關內容。

總結

1. 學會用各種方式問正確的人正確的問題。

2. 80%時間熟練工作技術，20%時間個人擴充。

3. 理論+實踐，不斷迭代，學習如何成為一個卓越的開發者。

此外如果覺得自己水平不錯，歡迎站內信我進行內部推薦。

以上。