Software Engineering at Google 這本書介紹了在 Google 中 Software Engineering 的一些實踐方法論，以及關於程式碼可擴充套件性和可持續性的一些原則。從我個人的學習角度，第一次讀這本書可以發現在我學習中的一些概念在書中有明確的對應，比如 CI 的一些 rule 在 Google 是如何使用的，以及一些軟體開發過程中應該注意到的點。

1. Software Engineering & Programming

“Software engineering” differs from “programming” in dimensionality: program

ming is about producing code. Software engineering extends that to include the maintenance of that code for its useful life span.

最大的區別在於程式碼需要可持續的時間，也就是程式碼的生命週期；如果是學校中的課程大作業，可能 Life span 很短，並不需要考慮太多的相容性設計和一些測試相關的問題，只要保證 It works 就可以滿足要求，但是在實際的工程中需要更多地考慮到程式碼的設計和生命週期的問題，也就是”It's maintainable“. 

2. Maintainable: Hyrum's Law:

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

當一個 API 有足夠的使用者的時候，在約定中你承諾的什麼都無所謂，所有在你係統裡面被觀察到的行為都會被一些使用者直接依賴。海勒姆法則 - Hyrum's Law - 簡書 (jianshu.com) 這裡舉的例子相當好，不同的 SQL 語句為我們提供了對於資料庫操作的封裝，但是當查詢效率有顯著區別的時候，我們就不得不深入檢視 SQL 的細節以優化 SQL 的執行效能。

3. Scalable of System

Your organization’s codebase is sustainable when you are able to change all of the things that you ought to change, safely, and can do so for the life of your codebase.

command center: Self-referential functions and the design of options 

可擴充套件性好的程式碼支援後期面向使用者需求的很多修改，而不是說在程式碼開始階段就設計好所有的需求。

對於組織或者架構的可擴充套件性，應當在設計之初也考慮到類似的設計，比如網路架構 (1條訊息) 說說如何實現可擴充套件性的大型網站架構_deniro_li的部落格-CSDN部落格_網路可擴充套件性

下圖是系統 Upgrade 的必要性隨著時間的變化，可以看到越到後期，系統 Upgrade 的需求越明顯。

4. Beyonce Rule

If you liked it, you should have put a CI test on it.

關於架構的可擴充套件性，Google 的這個 rule 很值得思考，Beyonce Rule 描述的是基礎架構和 CI 測試之間的關係。基礎平臺的架構如果影響到下游產品開發或者有依賴關係，應該對其負責的是下游的產品測試，通過 CI 發現這一問題。

5. Shifting Left

在問題的閉環中，及早發現問題的成本是最低的；也就是通過早期的測試更早的解決問題；我想這和 CI 本身也有共同之處：早發現問題，快速失敗來解決程式碼中的早期問題。

參考：

1. What I learned from Software Engineering at Google | Swizec Teller
2. https://abseil.io/resources/swe_at_google.2.pdf