Google 的軟體工程經驗總結
摘錄翻譯自“Software Engineering at Google”,作者:Fergus Henderson
軟體開發
程式碼庫
大部分的 Google 程式碼都存在統一的原始碼庫中,可供 Google 內部所有工程師訪問。但是 Chrome 和 Android 則分別有單獨的程式碼庫。
Google 的程式碼庫,在 2015 年 1 月的統計中,共計 86T 資料,上10億個檔案,9百萬個原始碼檔案,其中包含了 20 億行程式碼。迄今為止共計 3500 萬次提交,每個工作日平均發生 4 萬次更新。
任何 Google 員工,都可以隨意的訪問所有程式碼,並下載、編譯,可以在自己的環境下自行改寫,但任何更改的提交,都需要通過程式碼負責人的審批才可以。
所有的開發都在庫的頭部進行。對程式碼進行任何更改後,自動化系統將進行測試,並在幾分鐘內通知開發者和程式碼審查者,對更改的測試是否失敗。
程式碼庫中每個分支都有單獨的檔案註明“程式碼所有人”,只有程式碼所有人才有權利稽核提交的更改。通常情況下,專案組的所有成員都是“程式碼所有人”。
編譯系統
Google 使用分散式編譯系統,叫做 Blaze。Blaze 提供了標準的命令,用於編譯和測試庫中的所有程式碼。Blaze 這種統一的編譯工具,讓 Google 公司的所有工程師都能隨時編譯和測試任何軟體,也都能跨專案工作。
程式設計師需要撰寫“BUILD”檔案,用來引導 Blaze 如何編譯軟體。在Go語言的程式碼中,build 檔案可以自動生成。
每個編譯步驟必須是“隔離”的,只依賴於宣告的輸入。為了實現編譯的分散式執行,必須強制要求正確輸入所有的依賴:只有宣告瞭的輸入才被髮送到進行編譯的機器上去。
每個編譯步驟的結果是確定的。這樣保證了編譯系統可以快取編譯結果。軟體工程師可以回退到老的版本號,並重新編譯,且得到完全一樣的二進位制結果。
編譯結果快取在雲端。包括中間結果,這樣當有別的編譯請求過來,系統直接應用快取的結果。
增量的重新編譯非常快。編譯系統執行在記憶體中,當重新執行編譯任務時,它能夠分析檔案上次編譯後發生的增量變化。
提交前檢查。Google 有專門的自動化工具,用來在發起程式碼審查和準備提交更改到程式碼庫時,進行一整套的標準檢查。
程式碼審查
Google 開發了基於 Web 的程式碼審查管理工具。程式設計師可以申請對程式碼進行審查,審查者可以在瀏覽器上比較差異,並寫上評語。當寫程式碼的人發起一次審查申請,則系統自動發郵件給審查者,並附上程式碼檢視頁的連結。
對原始碼的任何更改,必須經過最少一次審查。如果更改不是由“程式碼所有人”做出,則還必須由所有人中的一位進行審查。
系統可以自動推薦合適的審查者。當然,寫程式的人,可以自己選擇審查者。
Google 鼓勵工程師們,將每一次程式碼更改控制在較小的規模上。 30-99 行的程式碼更改,通常視為“中等”;300 行以上則標記為“大”; 1000-1999 行,則是“巨大”;
測試
單元測試是必須的,在 Google 的開發中廣為採用。整合測試和迴歸測試,也較為普及。Google 有一個自動化的工具,用來衡量測試覆蓋的範圍,這個結果也在程式碼瀏覽器中可以檢視。
部署前一定要做壓力測試。專案組要用表格或者圖示顯示關鍵引數,尤其是壓力之下的延遲和錯誤率。
Bug 跟蹤
Google 使用的 Bug 跟蹤工具叫 Buganizer。有的團隊,安排專人分配 Bug,有的團隊則在例行的會議中分配。
開發語言
Google 內部有四大語言,一般都建議工程師在這四種裡挑選。四大語言是: C++,Java, Python, Go。不用多說,減少語言數量,可以增加程式碼複用,並提高內部協作。
每種語言都有程式碼規範,保證風格統一。公司範圍內,還有針對“程式碼可讀性”的培訓,由經驗豐富的老司機,對新人進行培訓。程式碼審查,也需要對“可讀性”做專門的評審。
在不同語言之間的互動操作,要通過Protocol Buffers 來處理。Protocol Buffers 是 Google公司開發的一種資料描述語言,類似於XML能夠將結構化資料序列化,可用於資料儲存、通訊協議等方面
除錯工具和效能分析工具
Google 的伺服器連線了很多庫,提供用於除錯伺服器的工具。伺服器崩潰時,可以自動匯出堆疊軌跡到日誌檔案。 還有 Web 介面用於除錯,可以用來檢視呼入和撥出的 RPC 呼叫、更改的命令列標誌值、資源消耗、效能分析等。
發版
Google 的大部分專案組,都有固定的軟體工程師負責發版。
大部分的軟體,發版比較頻繁。通常是周發版,或者每兩週發版,有些專案組甚至每天發。所以,自動化進行發版就是必須的了。頻繁發版有助於工程師們保持鬥志,提高整體速度,實現更多的迭代,從而也可以獲得更多的反饋,並做出更多有益的更正。
上線
要上線任何更改,並對使用者可用,則需要專案組外很多人的審批。審批來自多個方面,包括法律合規、隱私保護、安全要求、可靠性、業務需求等等。
Google 有一個內部的上線審批工具,用來執行審查和上線審批。通過定製,這個工具,對不同的產品有不同的審查和審批流程。
過錯總結
發生了重大的服務事故後,相關人員要起草過錯總結報告。文件描述事故細節,包括標題、概要、影響、時間段、原因、故障元件、行動。 總結的聚焦在於問題,以及未來如何解決,而不是聚焦在於人,也不是為了懲罰責任人。
頻繁的重寫程式碼
Google 鼓勵頻繁的重寫程式碼,任何軟體每隔幾年就重寫一遍。一來可以優化產品,採用最先進技術,去掉無用的功能,另外還可以轉移知識到新員工,並保持員工的鬥志。
專案管理
20%的自由時間
盡人皆知,google的工程師擁有 20%的自由時間,可以隨意做感興趣的東西,而無需審批。這當然是為了激發工程師的各種創意,同時也讓工程師們保持高效率,而不是窒息在必須完成的任務中。 另外,也考慮到,很多員工都會私下裡自己做一些東西,那麼還不如鼓勵大家將這些研究方向公開。
目標和關鍵結果
不論個人還是團隊,都要明確的寫下自己的目標,並評估達成目標的進度。每個季度的末尾,要根據關鍵結果,對目標達成情況進行打分,分數從 0 分到 1 分。這 OKR 分數是全公司內部公開的。但這並不直接用作個人績效評估的輸入。
平均得分是 0.65,但鼓勵大家將目標定的高一些,所以在可完成任務之上,再加 50% 的工作量是正常的。
專案立項
對於專案立項審批,以及專案取消,Google並沒有清楚定義的流程。即便是在 Google 做過 10 年的老經理,也不知道決策是如何做出的。很可能因為在公司範圍內,流程並不一致,經理們可以自行判斷並決策。有時候,決策是由下而上進行的,因為專案組的人都走光了。有時候,決策是自上而下的,老闆們決定哪些專案得到更多的預算,那些則必須關閉。
機構重組
當關閉一個大專案時,工程師們可以自行尋找新機會,加入新團隊。有的時候,還會搞“去碎片化”行動,把瑣碎的分散的團隊合併,這個時間工程師也可以自行選擇團隊和工作地點。
經常進行重組,有利於突破大公司的低效陷阱。
人的管理
崗位
Google 將“技術路線”和“管理路線”分開;將“技術領導” 從“管理”中分出;將“研究”綜合到“工程”中;設定“產品經理”、“專案經理”、和“站點可靠性”來支援工程師們。
工程中主要的崗位包括:
工程經理
這是工程式列中唯一的“人員管理”崗位。軟體工程師也“可能”管理人,但工程經理“總是”管理人。工程經理通常以前就是工程師,具備技術經驗,以及管理人的技能。
技術領導力與人員管理能力之間,是有區別的。
“工程經理”不一定帶領專案;專案通常由“技術組長”負責,當然“技術組長”也可能由“工程經理”擔任,但大多數情況下都是“工程師”。專案的“技術組長”對專案中的技術問題,具有決定權。
經理負責選擇“技術組長”,並監控團隊績效。工程經理還負責職場發展的培訓及引領,進行績效評估,並部分負責薪酬制定。還要做一些招聘工作。
一般來說,工程經理管理 3 – 30 個人,普遍情況下是 8 – 12 人。
工程師
在 Google,“工程”和“管理”的職業發展路線是不同的。工程師可以管理下屬,但這不是必須的。在更高層次,領導力是必須的,但領導力不一定從對人的管理中來。比如,開發了極具影響力的軟體,或者寫的程式碼被很多工程師使用,也是一種領導力。
研究科學家
科學家的招聘的門檻更高,需要有學術上的論文發表能力和程式碼能力。除了科學家需要論文和著作外,科學家和工程師沒有顯著的區別。在Google,科學家和工程師一起工作,同樣研發產品,同在一個團隊。這樣的安排為的將研究成果更好的匯入產品中。
站點可靠性工程師
對系統的維護由軟體工程師團隊負責,而不是通常的系統管理員。站點可靠性工程師的技能要求,比軟體開發工程師要稍低。
產品經理
產品經理負責管理產品,他們協調軟體工程師的工作,宣講功能特性,與其他團隊配合,跟蹤bug和進度,保證一切順暢執行以開發出高質量的產品。產品經理不寫程式碼。
計劃經理/技術計劃經理
計劃經理有點類似產品經理,但他們不管產品,而是管理專案、過程、或運營。
工程師與產品經理、計劃經理的比例,一般非常高,大約在4:1 到30:1之間。
設施
Google 有很先進的各種裝置,包括遊戲房、健身房,以及提供各種美食的免費餐廳,這一切都是為的將員工留在公司,多多工作。還可以帶朋友來蹭飯,這樣就增加了將朋友招聘進來的機會。
Google 的座位都是開放的,甚至有點擁擠,這有助於加強交流,但同時也影響了個人的專注,算是權衡之下的損失了。員工雖然有自己的座位,但每 6 -12 個月就要換一換,也是為了加強交流。
培訓
Google 的培訓有一下幾種:
- 新員工 (Nooglers)都要參加一個入職培訓教程
- 技術員工要參加一個“Codelabs”,進行短期的線上培訓課程,其中還有編碼練習
- 許多線上和現場的培訓課程
- 對於參加外部機構的課程,Google也給予支援
每個新員工,都被指派一名正式的“導師” 和一名“搭檔”,以幫助他儘快上手。
換崗
鼓勵換崗流動,以在公司範圍內傳播知識,並提高跨組織的交流。在一個崗位工作 12 個月後,可以選擇其他專案,也可以選擇換個辦公室。
績效評估和獎勵
Google 非常歡迎互相評價。 工程師可以彼此互贈正面評價,一種是“同事獎金”,一種是“點贊”。每名員工,每年擁有兩次機會,給予其他員工以“同事獎金”提名,獎金是 100 美元。這種“同事獎金”是為了獎勵員工在職責之外幫助他人。“點贊”則僅僅是表揚,沒有現金獎勵。
經理可以發放獎金,包括一種在專案完成後的特殊獎金。Google和其他公司一樣,也有年底績效獎和股權激勵。
績效優秀,可以晉升。而績效差的,則需要進行改進,但有意思的是 Google 很少開除員工。員工還要對經理的績效進行評估,以保證管理效率和管理質量。
相關文章
- 《軟體專案經驗總結》
- 軟體工程總結軟體工程
- 軟體工程——個人總結軟體工程
- 《軟體工程》個人總結軟體工程
- Google、Facebook、Rocket fuel面試經驗總結Go面試
- 軟體反破解技術經驗總結:歡迎加入您的經驗
- 軟體工程實踐----初步接觸軟體工程的總結軟體工程
- 對於《軟體工程》的總結軟體工程
- 軟體工程實踐總結軟體工程
- 《軟體工程》課程總結軟體工程
- 軟體工程管理的一點經驗之工程構建軟體工程
- 業務中介軟體設計方法論經驗總結
- 軟體工程--總作業(已經完成)軟體工程
- 軟體工程個人最終總結軟體工程
- Google Test交流與測試開發經驗總結Go
- Android 開發軟體架構思考以及經驗總結Android架構
- 軟體工程實踐總結作業軟體工程
- 《軟體工程》課程設計總結軟體工程
- 一位測試大神的軟體測試工作經驗總結
- 軟體工程之四則運算總結軟體工程
- 作業8: 軟體工程學習總結軟體工程
- 0503《軟體工程》的簡單小總結與展望軟體工程
- 軟體測試工程師的工作總結(轉)工程師
- 工作經驗總結
- vue經驗總結Vue
- mysql經驗總結MySql
- Java經驗總結Java
- Storm經驗總結ORM
- Resin 經驗總結
- 《軟體測試實戰:微軟技術專家經驗總結》前言微軟
- 軟體工程專案之攝影App(總結)軟體工程APP
- 軟體開發工程師工作總結(轉)工程師
- 軟體工程單元測試作業總結軟體工程
- 我的軟體開發生涯 :10年開發經驗總結和爆棧人生
- IT職場管理經驗總結
- Eclipse經驗總結Eclipse
- mysql使用經驗總結MySql
- 考試經驗總結