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

這個系列是這本書的讀書筆記，這本書總共有四個部分。所以應該總共也就有四篇。

第一部分只有一章，所以可以水一篇，開心。

什麼是軟件工程

軟件工程是隨着時間的推移不停地對代碼進行集成 (Programming integrated over time)，這本書將軟件項目分成兩種，一種是 programming，一種是 software engineering，具體的區別：

Google 上新項目，默認這些項目都會存活十年以上，所以一般也會按照這個持續時間進行相關的設計。

有很多工作十年的老碼農，從來沒設計過存活一年~ 兩年以上的系統。存活時間很長的系統，需要考慮升級的便利性，有些公司可能在一些依賴項的升級的時候吃了大虧 (比如某司的 mysql 升級大故障)，得出我們再也不升級的結論，但這樣的決定會讓你陷入未來的安全漏洞無法修復，性能提升無法享受的尷尬境地。

海拉姆定律 (Hyrum's rule)，人們會依賴所有你的 API 的可被觀測到的特性，即使這些特性不是你文檔裏承諾的特性。這裏有個很好的例子，程序員們會依賴 hash table 的輸出順序，顯然這樣是不應該的。有些語言會額外地對 hash table 的輸出做隨機化，但你可能就想不到會有人依賴這種隨機化。只要是可能會被用戶觀測到的 API 的規律，都可能會被用戶依賴。

在探討擴展性時，特意提到了 build 系統的擴展性，不能讓開發者把時間浪費在等待 build 上。Google 建立了自己的分佈式 build 系統。

業界當前的老項目 / lib 做 deprecation 的時候，一般作者是不管用戶的升級的，不過 Google 會要求 inf 和原始庫的開發團隊專門來負責升級這件事情，並且給 Deprecation 專門做了相關的系統。各種子系統的升級問題被當成 subproblem，由升級的熟手們挨個兒解決。

基於分支開發的業界實踐很普遍，不過分支開發經常會由於排隊排得比較靠後導致合入主幹代碼時引入大量的修改，所以最後反而大家更不願意頻繁進行代碼合併了，這本書也給出瞭解決分支研發的這種麻煩的解決方案。

在升級的時候，可能會碰到破壞了應用功能的情況，這種情況說明 CI 裏的測試寫的不完整，需要應用側補全，如果碰到了這種問題，不能把鍋甩給執行升級任務的團隊。

Google 內部建立了問題的覆盤文化，都是對事不對人。對於大家畏懼的升級，只要經常做，就不會再產生畏懼了。前面說到的 Hyrum's rule，因爲經常升級，所以那些文檔裏沒有承諾的特性如果被用戶依賴了，用戶也能儘快地發現。

Google 做的生產力方面的事情，除了提升效率之外，都是儘量提升開發者的體驗 (萬惡的資本主義啊)。

在版本控制方面，不建議使用 fork，而是全局使用相同的版本，Google 自己建設了一套叫 Piper 的代碼管理系統，在版本管理的章節中會有具體的說明。這本書的作者認爲一致性相比 fork 的靈活性有更大的價值。在 monorepo 中，一個庫的版本一定是固定在某一個版本的。

用數據驅動自己的開發與決策。

勇於承認過往的決策錯誤，這樣的人會受人尊敬。

第一部分沒什麼重要內容~

ps. 這本書現在作者公開了，可以免費下載：

https://abseil.io/resources/swe_at_google.2.pdf

心疼我的 60 刀。

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

猜你喜歡