此系列會更新 Google 的軟體工程之道的摘要與讀書心得
時間與變化
介於一次性計畫和持續十年的項目，發生了轉變：一個項目必須開始對不斷變化的外部因素做出反應
對於任何一個從一開始就沒有升級計畫的項目，這種轉變可能會非常痛苦，原因有三個，每一個都會使其他原因變得複雜
- 你正在執行本項目尚未完成的任務；更多隱藏的假設已經成立。
- 嘗試進行升級的工程師不太可能具有此類任務的經驗。
- 升級的規模通常比平時大，一次完成幾年的升級，而不是增量升級。
我們需要更清楚的認識到 "碰巧可以工作" 與 "可維護" 之間的差別
海勒姆法則 - 如果有足夠的用戶，你在契約的承諾就無關緊要：你的系統所有可觀察到的行為都會被依賴
靈活或巧妙 對上 無暇與可維護：取決於程式開發風格的分類，程式碼若依賴脆弱或未發布的內容回前者，而遵循最佳實施的方式並且對未來有規劃則是後者
巧妙如果是一種恭維，那就是程式設計；巧妙是一種指責，那就是軟體工程
無法擴整與可擴展的政策 - 用編譯器升級來當作例子
影響程式碼基底靈活性的因素
- 專業知識
- 穩定性
- 一致性
- 熟悉性
- 政策
如果認為這項任務成本過高，將來應該避免，那麼我們可能仍然使用十年前的編譯器版本。由於錯過了優畫的機會，可能就會為運算資源增加 25% 的代價
停滯不前是一種選擇，但往往不是明智之舉
左移
在開發人員早期發現問題時，可以降低成本，將安全性問題左移就顯得特別重要
決策的投入 - 分散式架構
隨著 codebase 越來越大，編譯時間也越來越長，就要投入更多的資源成本在本地機器上，但是大多數情況，高性能的桌上開發機器將處於閒置狀態，這不是好的投資方式。
開發一套分散式的建構系統，部屬到生產環境，加快了所有人的建構速度。但隨著時間變化，分散式建構本身也變得臃腫。
添加分散式建構系統節省的成本可能超過了 "建構與維護" 的負成本。但是這些消耗增加，我們沒有預見所有的成本。
軟體工程與程式設計
程式設計是產生程式碼的直接行為；軟體工程是一組策略、實施方法和工具
留言
張貼留言