軟件開發(fā)

代碼庫

大部分的 Google 代碼都存在統(tǒng)一的源代碼庫中，可供 Google 內(nèi)部所有工程師訪問。但是 Chrome 和 Android 則分別有單獨的代碼庫。

Google 的代碼庫，在 2015 年 1 月的統(tǒng)計中，共計 86T 數(shù)據(jù)，上10億個文件，9百萬個源代碼文件，其中包含了 20 億行代碼。迄今為止共計 3500 萬次提交，每個工作日平均發(fā)生 4 萬次更新。

任何 Google 員工，都可以隨意的訪問所有代碼，并下載、編譯，可以在自己的環(huán)境下自行改寫，但任何更改的提交，都需要通過代碼負責人的審批才可以。

所有的開發(fā)都在庫的頭部進行。對代碼進行任何更改后，自動化系統(tǒng)將進行測試，并在幾分鐘內(nèi)通知開發(fā)者和代碼審查者，對更改的測試是否失敗。

代碼庫中每個分支都有單獨的文件注明“代碼所有人”，只有代碼所有人才有權(quán)利審核提交的更改。通常情況下，項目組的所有成員都是“代碼所有人”。

編譯系統(tǒng)

Google 使用分布式編譯系統(tǒng)，叫做 Blaze。Blaze 提供了標準的命令，用于編譯和測試庫中的所有代碼。Blaze 這種統(tǒng)一的編譯工具，讓 Google 公司的所有工程師都能隨時編譯和測試任何軟件，也都能跨項目工作。

程序員需要撰寫“BUILD”文件，用來引導 Blaze 如何編譯軟件。在Go語言的代碼中，build 文件可以自動生成。

每個編譯步驟必須是“隔離”的，只依賴于聲明的輸入。為了實現(xiàn)編譯的分布式運行，必須強制要求正確輸入所有的依賴：只有聲明了的輸入才被發(fā)送到進行編譯的機器上去。

每個編譯步驟的結(jié)果是確定的。這樣保證了編譯系統(tǒng)可以緩存編譯結(jié)果。軟件工程師可以回退到老的版本號，并重新編譯，且得到完全一樣的二進制結(jié)果。

編譯結(jié)果緩存在云端。包括中間結(jié)果，這樣當有別的編譯請求過來，系統(tǒng)直接應用緩存的結(jié)果。

增量的重新編譯非?？臁＞幾g系統(tǒng)運行在內(nèi)存中，當重新執(zhí)行編譯任務時，它能夠分析文件上次編譯后發(fā)生的增量變化。

提交前檢查。Google 有專門的自動化工具，用來在發(fā)起代碼審查和準備提交更改到代碼庫時，進行一整套的標準檢查。

代碼審查

Google 開發(fā)了基于 Web 的代碼審查管理工具。程序員可以申請對代碼進行審查，審查者可以在瀏覽器上比較差異，并寫上評語。當寫代碼的人發(fā)起一次審查申請，則系統(tǒng)自動發(fā)郵件給審查者，并附上代碼查看頁的鏈接。

對源代碼的任何更改，必須經(jīng)過最少一次審查。如果更改不是由“代碼所有人”做出，則還必須由所有人中的一位進行審查。

系統(tǒng)可以自動推薦合適的審查者。當然，寫程序的人，可以自己選擇審查者。

Google 鼓勵工程師們，將每一次代碼更改控制在較小的規(guī)模上。 30-99 行的代碼更改，通常視為“中等”；300 行以上則標記為“大”； 1000-1999 行，則是“巨大”；

測試

單元測試是必須的，在 Google 的開發(fā)中廣為采用。集成測試和回歸測試，也較為普及。Google 有一個自動化的工具，用來衡量測試覆蓋的范圍，這個結(jié)果也在代碼瀏覽器中可以查看。

部署前一定要做壓力測試。項目組要用表格或者圖標顯示關鍵參數(shù)，尤其是壓力之下的延遲和錯誤率。

Bug 跟蹤

Google 使用的 Bug 跟蹤工具叫 Buganizer。有的團隊，安排專人分配 Bug，有的團隊則在例行的會議中分配。

開發(fā)語言

Google 內(nèi)部有四大語言，一般都建議工程師在這四種里挑選。四大語言是：  C ，Java， Python， Go。不用多說，減少語言數(shù)量，可以增加代碼復用，并提高內(nèi)部協(xié)作。

每種語言都有代碼規(guī)范，保證風格統(tǒng)一。公司范圍內(nèi)，還有針對“代碼可讀性”的培訓，由經(jīng)驗豐富的老司機，對新人進行培訓。代碼審查，也需要對“可讀性”做專門的評審。

在不同語言之間的交互操作，要通過Protocol Buffers 來處理。Protocol Buffers 是 Google公司開發(fā)的一種數(shù)據(jù)描述語言，類似于XML能夠?qū)⒔Y(jié)構(gòu)化數(shù)據(jù)序列化，可用于數(shù)據(jù)存儲、通信協(xié)議等方面

調(diào)試工具和性能分析工具

 Google 的服務器連接了很多庫，提供用于調(diào)試服務器的工具。服務器崩潰時，可以自動導出堆棧軌跡到日志文件。 還有 Web 界面用于調(diào)試，可以用來查看呼入和呼出的 RPC 調(diào)用、更改的命令行標志值、資源消耗、性能分析等。

發(fā)版

Google 的大部分項目組，都有固定的軟件工程師負責發(fā)版。

大部分的軟件，發(fā)版比較頻繁。通常是周發(fā)版，或者每兩周發(fā)版，有些項目組甚至每天發(fā)。所以，自動化進行發(fā)版就是必須的了。頻繁發(fā)版有助于工程師們保持斗志，提高整體速度，實現(xiàn)更多的迭代，從而也可以獲得更多的反饋，并做出更多有益的更正。

上線

要上線任何更改，并對用戶可用，則需要項目組外很多人的審批。審批來自多個方面，包括法律合規(guī)、隱私保護、安全要求、可靠性、業(yè)務需求等等。

Google 有一個內(nèi)部的上線審批工具，用來執(zhí)行審查和上線審批。通過定制，這個工具，對不同的產(chǎn)品有不同的審查和審批流程。

過錯總結(jié)

發(fā)生了重大的服務事故后，相關人員要起草過錯總結(jié)報告。文檔描述事故細節(jié)，包括標題、概要、影響、時間段、原因、故障組件、行動。 總結(jié)的聚焦在于問題，以及未來如何解決，而不是聚焦在于人，也不是為了懲罰責任人。

頻繁的重寫代碼

Google 鼓勵頻繁的重寫代碼，任何軟件每隔幾年就重寫一遍。一來可以優(yōu)化產(chǎn)品，采用最先進技術，去掉無用的功能，另外還可以轉(zhuǎn)移知識到新員工，并保持員工的斗志。

項目管理

20%的自由時間

盡人皆知，google的工程師擁有 20%的自由時間，可以隨意做感興趣的東西，而無需審批。這當然是為了激發(fā)工程師的各種創(chuàng)意，同時也讓工程師們保持高效率，而不是窒息在必須完成的任務中。 另外，也考慮到，很多員工都會私下里自己做一些東西，那么還不如鼓勵大家將這些研究方向公開。

目標和關鍵結(jié)果

不論個人還是團隊，都要明確的寫下自己的目標，并評估達成目標的進度。每個季度的末尾，要根據(jù)關鍵結(jié)果，對目標達成情況進行打分，分數(shù)從 0 分到 1 分。這 OKR 分數(shù)是全公司內(nèi)部公開的。但這并不直接用作個人績效評估的輸入。

平均得分是 0.65，但鼓勵大家將目標定的高一些，所以在可完成任務之上，再加 50% 的工作量是正常的。

項目立項

對于項目立項審批，以及項目取消，Google并沒有清楚定義的流程。即便是在 Google 做過 10 年的老經(jīng)理，也不知道決策是如何做出的。很可能因為在公司范圍內(nèi)，流程并不一致，經(jīng)理們可以自行判斷并決策。有時候，決策是由下而上進行的，因為項目組的人都走光了。有時候，決策是自上而下的，老板們決定哪些項目得到更多的預算，那些則必須關閉。

機構(gòu)重組

當關閉一個大項目時，工程師們可以自行尋找新機會，加入新團隊。有的時候，還會搞“去碎片化”行動，把瑣碎的分散的團隊合并，這個時間工程師也可以自行選擇團隊和工作地點。

經(jīng)常進行重組，有利于突破大公司的低效陷阱。

人的管理

崗位

Google 將“技術路線”和“管理路線”分開；將“技術領導” 從“管理”中分出；將“研究”綜合到“工程”中；設置“產(chǎn)品經(jīng)理”、“項目經(jīng)理”、和“站點可靠性”來支持工程師們。

工程中主要的崗位包括：

- 工程經(jīng)理

這是工程序列中唯一的“人員管理”崗位。軟件工程師也“可能”管理人，但工程經(jīng)理“總是”管理人。工程經(jīng)理通常以前就是工程師，具備技術經(jīng)驗，以及管理人的技能。

技術領導力與人員管理能力之間，是有區(qū)別的。

“工程經(jīng)理”不一定帶領項目；項目通常由“技術組長”負責，當然“技術組長”也可能由“工程經(jīng)理”擔任，但大多數(shù)情況下都是“工程師”。項目的“技術組長”對項目中的技術問題，具有決定權(quán)。

經(jīng)理負責選擇“技術組長”，并監(jiān)控團隊績效。工程經(jīng)理還負責職場發(fā)展的培訓及引領，進行績效評估，并部分負責薪酬制定。還要做一些招聘工作。

一般來說，工程經(jīng)理管理 3 - 30 個人，普遍情況下是 8 - 12 人。

- 工程師

在 Google，“工程”和“管理”的職業(yè)發(fā)展路線是不同的。工程師可以管理下屬，但這不是必須的。在更高層次，領導力是必須的，但領導力不一定從對人的管理中來。比如，開發(fā)了極具影響力的軟件，或者寫的代碼被很多工程師使用，也是一種領導力。

- 研究科學家

科學家的招聘的門檻更高，需要有學術上的論文發(fā)表能力和代碼能力。除了科學家需要論文和著作外，科學家和工程師沒有顯著的區(qū)別。在Google，科學家和工程師一起工作，同樣研發(fā)產(chǎn)品，同在一個團隊。這樣的安排為的將研究成果更好的導入產(chǎn)品中。

- 站點可靠性工程師

對系統(tǒng)的維護由軟件工程師團隊負責，而不是通常的系統(tǒng)管理員。站點可靠性工程師的技能要求，比軟件開發(fā)工程師要稍低。

- 產(chǎn)品經(jīng)理

產(chǎn)品經(jīng)理負責管理產(chǎn)品，他們協(xié)調(diào)軟件工程師的工作，宣講功能特性，與其他團隊配合，跟蹤bug和進度，保證一切順暢運行以開發(fā)出高質(zhì)量的產(chǎn)品。產(chǎn)品經(jīng)理不寫代碼。

- 計劃經(jīng)理/技術計劃經(jīng)理

計劃經(jīng)理有點類似產(chǎn)品經(jīng)理，但他們不管產(chǎn)品，而是管理項目、過程、或運營。

工程師與產(chǎn)品經(jīng)理、計劃經(jīng)理的比例，一般非常高，大約在4：1 到30：1之間。

設施

Google 有很先進的各種設備，包括游戲房、健身房，以及提供各種美食的免費餐廳，這一切都是為的將員工留在公司，多多工作。還可以帶朋友來蹭飯，這樣就增加了將朋友招聘進來的機會。

Google 的座位都是開放的，甚至有點擁擠，這有助于加強交流，但同時也影響了個人的專注，算是權(quán)衡之下的損失了。員工雖然有自己的座位，但每 6 -12 個月就要換一換，也是為了加強交流。

培訓

Google 的培訓有一下幾種：

- 新員工 （Nooglers）都要參加一個入職培訓教程
- 技術員工要參加一個“Codelabs”，進行短期的在線培訓課程，其中還有編碼練習
- 許多在線和現(xiàn)場的培訓課程
- 對于參加外部機構(gòu)的課程，Google也給予支持

每個新員工，都被指派一名正式的“導師” 和一名“搭檔”，以幫助他盡快上手。

換崗

鼓勵換崗流動，以在公司范圍內(nèi)傳播知識，并提高跨組織的交流。在一個崗位工作 12 個月后，可以選擇其他項目，也可以選擇換個辦公室。

績效評估和獎勵

Google 非常歡迎互相評價。 工程師可以彼此互贈正面評價，一種是“同事獎金”，一種是“點贊”。每名員工，每年擁有兩次機會，給予其他員工以“同事獎金”提名，獎金是 100 美元。這種“同事獎金”是為了獎勵員工在職責之外幫助他人?！包c贊”則僅僅是表揚，沒有現(xiàn)金獎勵。

經(jīng)理可以發(fā)放獎金，包括一種在項目完成后的特殊獎金。Google和其他公司一樣，也有年底績效獎和股權(quán)激勵。

績效優(yōu)秀，可以晉升。而績效差的，則需要進行改進，但有意思的是 Google 很少開除員工。員工還要對經(jīng)理的績效進行評估，以保證管理效率和管理質(zhì)量。

著作權(quán)歸作者所有

本文轉(zhuǎn)自：簡書

微信號：IdeaofSE