《谷歌的軟件工程》筆記 -二-

這本書第二部分講的是文化，對於技術人員來說稍微有點無聊，不過決定我們在一家公司工作舒服不舒服的，其實主要就是這些文化內容，如果用這一部分裏的內容去考覈那些我們日常工作中的人，可能結果也會令人失望。

這一部分的內容可以看出 Google 和國內公司的文化有巨大的差異，對國內的工程師和 manager 來說，有一些思想有借鑑意義，而另一些只當參考即可 (全信的話，你一定會被坑得很慘)。

軟件開發要依賴團隊協作

Google 內部的代碼管理系統收到過很多人的需求，希望能把項目設置成 private，這個需求來自於很多人在項目寫完之前，不想讓別人看到自己的代碼，這種心態是由於研發人員的不安全感。比如他們可能害怕：

• 別人嘲笑你，這樣的錯誤你都犯，和你的工作年限是不是匹配啊，可能你其實是個菜雞

• 明明是自己想出來的 idea，但是最終卻被別人搶去邀功了

對代碼的 “隱藏” 行爲並不能給我們帶來好處，從項目開始設計一直到完成，中間要經歷很長時間，如果你能夠讓自己的同事早期就參與到項目反饋中，那他們可以及時地向你提出一些你可能沒有考慮到的問題。

如果你走了彎路，不做完就不公開，那最後可能會浪費很多無意義的時間。比如你可能自己 high 了半天，做完之後別人告訴你社區 / 公司裏已經有更完善的輪子了，那你的工作就白搞了。做研發的時候必須要確認：

• 你在做正確的事情

• 你在用正確的方法做事

• 這件事情之前沒有人做過

靠你自己，這三點很難保證，同事間的反饋非常重要，並且越早期的反饋效果越好，能讓你在錯誤的路上儘早調頭，這樣風險也最小。

書中提出了一個叫 bus factor 的概念，其實就是團隊中的一些核心人員，如果他們休假了或者離職了，組裏的工作要停擺，那麼工作的安排就是有問題的。這裏特意強調了文檔、pair programming 的重要性。

團隊內的溝通有三個基本的原則：

• 謙虛

• 尊重

• 信任

要對他人的處境感同身受，向他人提意見時，應該是一些建設性的建議，而不是無意義的人身攻擊或者謾罵。

作爲被提意見的人，我們也不應該把代碼和自身綁的太緊，是代碼和項目上的問題，就事論事就可以，要願意接受他人的意見，勇於承認錯誤。承認錯誤並不會影響你個人的名譽，願意承認錯誤的人會更被他人所尊重。

在團隊內要重視失敗的項目，做業務也要 fail fast 並且不斷迭代。當失敗時，要建立不針對個人的覆盤文化，道歉、藉口或者互相指責沒有任何意義。覆盤要關心的應該是我們從失敗中學到了什麼，並且由於這些失敗的經驗，有什麼樣的變化是必須要被推動的。書裏也給出了一個覆盤的模板，感興趣的讀者可以閱讀一下 p39。

作爲軟件公司裏共事的同事，我們應該有共同的目標，所以不需要像政客那樣死鴨子嘴硬不願認錯，這樣對誰都沒有好處。

知識分享

Google 內部對於知識的分享非常重視，首先項目要有豐富的文檔，這方面外企做的都挺不錯的。文檔能夠讓你的團隊 "Scale"，因爲後來者能夠通過文檔瞭解你們的項目背景，設計初衷，開發進度等情況。

文檔平臺要支持檢索，並且要有評論區，這樣方便大家來針對某些技術方案進行討論。在國內某家公司工作的時候，我非常驚詫的一點是他們的內部文檔系統內容檢索功能稀爛，極大影響了工作效率，有人吐槽卻被熟視無睹。

其次 Google 有內部的技術交流社區，包括動態的羣聊和郵件列表 (他們的郵件列表和國內的內部論壇比較類似)。並且建立了專門的 QA 系統，類似內部版本的 Stack Overflow。

Google 內部還建立了分享文化，有專門的 Tech Talks 和內部企業培訓課。現在有一些分享也會公開到 Youtube 上，之前我看到過一些。

Google 內部的代碼也是對所有人開放的。

有一點比較神奇的是，在 Google 內部，如果你經常幫助同事，理論上同事可以給你一個 peer bonus 的評分 (好像)，這個 peer bonus 也會成爲你工資以外的一筆收入，這部分錢完全是你的同事決定的，和你的 manager 沒啥關係。

也就是說，幫助別人也是可以獲得回報的。

Google 內部建立了各種各樣的 Developer Guide 站點，幫助新人學習和 landing。同時有 codelab 幫助員工來進行一些技能的鍛鍊與學習。

一些代碼規範和經驗會直接沉澱到靜態分析工具中。內部的一些事故、新聞會有專門的 NewsLetter，每隔一段時間發給所有員工，大家可以從這些有意思的內部事故中學習到別人的事故經驗。

還有一個 Readability 的認證，我以前就聽人講起過 Google 的這套機制，據說 python 之父入職 Google 之後，都好幾次考 Readability 的認證沒有通過。具體來說就是你要了解公司內部對於代碼規範的一些要求，並且參與考試，會有已經獲得了 Readability 的工程師們幫你 review 代碼，如果大家都通過了，那麼你就獲得了 Readability 的認證。之後自己也可以申請成爲 Readability 的 Reviewer。

只有通過了 Readability 的認證，才能正式向線上提交代碼。

這一點我覺得還挺重要的，不知道爲啥國內公司沒有借鑑學習，大家每天都在埋怨代碼很屎，但是好像也沒有人提出可以借鑑 Google 的做法去做類似的考覈。

平等的工程

這個問題是國際化公司要面對的問題，公司要 Diversity 並不是響應某些國家政府的要求，而是因爲他們要在全世界做生意，每個國家因爲政治、風俗的原因都有一些禁忌，如果公司內沒有了解當地風俗的人，那就很容易在一些當地的敏感問題上犯錯。

比如 Google 曾經的人臉識別算法把黑人識別成了猩猩，而且公司對於這場輿論危機的反應又異常地慢，影響很惡劣。

產品發佈的時候，要多做評估，不要着急發佈導致你的產品對某一些區域的用戶產生了傷害。

這一節體會不深，沒有在這樣的公司工作過。

如何領導一個團隊

在 Google 的制度設計中一般有兩條線，一個團隊裏會有一個 Manager，負責績效管理和跨團隊協調；另一個角色是 Tech Lead，這個角色比較類似國內某些公司說的架構師，主要負責組內的項目架構設計，技術把關，核心組件的實現，以及其他人的方案的 Review，有些團隊比較小，所以可能有人兼任 Manager 和 Tech Lead。

一個好的工程師不一定是一個好的 Manager，對於 Manager 來說，做好這個角色切換也並不容易，可能新的工作中很難獲得原有的熟悉的成就感。而人們又傾向於晉升到他們所不勝任的位置上去。但你應該努力讓自己的職業生涯也能 "Scale"，不要偏安於一隅，如果只靠一個人寫代碼，你的產出終究是有上限的，而一羣人則可以在你的幫助下做出，做好更大的項目。

與傳統的 Manager 角色不同，互聯網公司的工程師們需要一定的時間來思考和創造，所以在互聯網公司內做 Manager 也不應該用那些傳統公司的胡蘿蔔 + 大棒策略來管理自己的員工。

Manager 不應該成爲保姆一樣的角色，而應該給成員們定出清晰的技術、業務目標，成爲團隊的催化劑，讓大家的生產力得到提升，移除團隊成員們前進的障礙，保護成員不被公司內的政治所傷害，維護好組內的氣氛，對組員誠實。

看看上面這些要求。。。怕是沒幾個人能達到的吧。。

這一節還指出了一些當 Manager 的誤區：

• 第一是隻招聘聽話的人，這樣你永遠得不到負向的反饋，那很多決策上也比較容易出問題。

• 第二是無視那些表現差勁的成員，沒有與他們及時溝通，且沒有針對性地讓他們來改進績效，這樣會影響組內那些績效優秀的人，他們會認爲你無法區分好壞，最終離開你的團隊

• 第三是忽視一些人的因素，只考慮技術因素，比如可能有的成員家庭有一些事情，你不能還是照以往那樣去做工作安排，這是把人當成了純粹的工具

• 第四是和組員成爲過於好的朋友，這樣可能無法更客觀地去處理問題，同時也會傷害你與朋友的感情 (談工作傷感情)

• 不要爲了填滿 HC 降低招聘門檻

• 不要把組員當成小孩，該給的工作材料補充要做好，比如紙、筆，這些花不了幾個錢，但是能提高大家工作、交流的效率

對於 Manager 來說，有服務組員的意識，關注團隊的核心方向，把精力放在怎麼樣讓組員們工作舒服和提升效率上。一些很具體的工作，能讓別人代理的工作儘量讓別人來代理，不要所有事情都親力親爲。一方面是培養他人，另一方面能夠讓自己有更多的機會來考慮別的事情，繼續向上提升。

領導大團隊

簡單來說，大領導們基本都得脫離技術一線，之前在技術上的積累對工作的幫助就越來越小了。這時候可能會讓人氣餒，但也沒有辦法，這裏給我們提出了三個成爲好領導的指導原則，三個 Always：

• Always Be Deciding，到了這個階段做的就不是技術細節了，所以你所有的決策都是關於正確的 trade-off 相關的，都是要做什麼事情，不要做什麼事情。這個決策過程也是要不斷迭代的，一邊決策，一邊根據效果來對決策進行調整，書裏舉了個例子，Google 早期的搜索體驗優化聚焦在搜索結果展示上，而這會影響搜索的速度和帶寬，速度又會拉低用戶體驗，所以會導致每做一段時間展示優化，就得回去做性能優化；剛做完性能優化，馬上就被新的功能優化拉回到原地。通過反覆的折騰，Google 總結出了搜索體驗的三個關鍵要素：Latency，Capacity，Quality，後續的決策就是在這三個指標之間進行權衡。

• Always Be Leaving，這個原則比較神奇，就是你要儘量讓團隊能夠 Self-Driving，然後讓自己的角色變得可有可無，基本的策略和解決技術問題類似，把一個大的問題劃分成子問題，然後把這些子問題代理給下面的團隊 leader，讓 下面的團隊去解決這些子問題。重點關注一些戰略層面的事情，讓這些商業、技術問題的解決是可持續的。在決策過程中，要保證下面的團隊的目標是一直被錨定的，不要發生偏移。然後就要開始問自己，有哪些事情是非自己做不可的，找出來這些問題，解決掉，這樣當自己離開時，團隊依然能夠自行運轉。(個人意見，這個有點站着說話不腰疼，沒有幾個人願意放棄手上已有的權力吧)

• Always Be Scaling，這裏講的比較虛，遇到問題，分析問題，然後通過痛苦的掙扎來解決問題，總結經驗，對團隊做獎賞，然後再去解決新的問題。在決策循環中要分清重要和緊急的問題，同時維持好自己的精力，讓自己儘量聚焦中 20% 的重要問題上，其它的委派給下面的 leader 們。

總結一下，高度不夠，看着比較虛。內容也有點站着說話不腰痛。

衡量工程生產力

《人月神話》裏的故事大家已經都知道了，給項目加人是沒法加速軟件的研發的。

提升單體工程師的工作效率卻可以加速項目研發，Google 爲了提升生產力，找了很多人來研究到底該監控什麼樣的指標，這裏面還有很多心理學家和行爲學家。。以數據驅動的方式來研究生產效率的提升。

爲了讓指標有意義，Google 發明了一套 GSM：Goals，Signals，Metrics 的方法來衡量一個指標是否合理。

Goal 是定指標的時候必須要考慮的目標，這些目標要儘量能夠都滿足，不能使其中一個向上而其它向下。這裏的 Goals 主要有 QUANTS 五個方面：

• Quality of the code，你的工具和指標應該能讓代碼質量得到提升，或者至少也不應該有負面的影響。

• Attention from engineers，你的工具和指標會不會讓工程師的注意力反覆被打斷？比如因爲頻繁推送的 notification，你的工具會讓工程師不斷地進行上下文切換麼？

• Intellectual complexity，你的工具和指標會不會增加工程師的心智負擔？會不會讓因爲這些工具讓工程師完成任務變得更難了？

• Tempo and velocity，工程師能以多快的速度完成任務？多快發佈新的版本？在給定的時間內能完成多少任務？

• Satisfaction，工程師對工具是否滿意？工具是否滿足了工程師們的需求？工程師是否經常被工具惹惱？

書裏以 Readability 爲例，根據上述框架來分析，每一點都要儘量達到要求。

Signal 是指我們以什麼樣的表現來判斷我們的目標是否已經達成了。其實就是你要收集一些反饋或者數據，來判斷你的工具是不是真的達成了上面那些 Goal，而不是你自己吹牛逼，還是 Readability 這套體系：

唉，說白了，就是你的晉升 PPT 上，這些東西要能自圓其說，不能是硬凹。每一條都有論據能對號入座。

Metrics 就是你要作爲生產力衡量的工具或者指標，這些指標需要是可以量化的，直接從書裏摘一些例子吧：

在收集到數據之後，研究工程效率的團隊都要給出後續改進的建議列表，這裏面的 action 可能是給生產力工具增加一個 feature，提升某個工具的延遲，改進公司內的文檔，移除一些已經過時的老流程。

上面這些 action 儘量都是 tool driven 的，經過開發或者改進，能集成到工程師的工作 workflow 流程中。而不是在工具不支持的前提下，讓工程師改變他們使用或者思考工具的方法。

這一點我還是比較欣賞 Google 的，能用工具解決的，都儘量用工具來解決。通過工具的不斷改進，來提升工程師的工作滿意度和他們的效率。

總結

對於我們工程師來說，改變公司的文化是很難的，所以這一部分裏的內容可能也就只是個參考。

如果你特別較真兒，用文內的 GSM 框架去衡量國內公司的那些生產力指標，那大概率也是會失望而歸的。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/j59HejHj5hzKovfsGdrIdg