GCA

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

Vue 3.0 reactive, computed 原始碼分析  此文件大量使用了程式碼，請善用 搜尋 ( Ctrl+F ) 來 trace 整段 code 在 Vue 3.0，computed 寫法也有所改變，寫法可以參考  Composition API ，裡面提供的例子如下 const state = reactive ( { count : 0 , double : computed ( ( ) => state . count * 2 ) } ) 讓我們用 Test Case 來看看 computed 可以做什麼事情 computed 可以傳入一個 function，function 裡面的值只要有改變，或是被給值，就會更新 computed 的回傳值中的 value。 以下面的例子來說，可以發現  computed(() => value.foo)  裡面用到了  value.foo ，所以當  value.foo = 1 時， cValue 中的  value  就會跟著更新為 1 it ( 'should return updated value' , ( ) => { const value = reactive < { foo ? : number } > ( { } ) const cValue = computed ( ( ) => value . foo ) expect ( cValue . value ) . toBe ( undefined ) value . foo = 1 expect ( cValue . value ) . toBe ( 1 ) } ) Computed 知道了 computed 的功能之後，讓我們來追一下原始碼是怎麼讓 computed 更新的，還有其中的奧妙之處。 首先我們直接看進去 computed 這個 function 的實作。以原先的 Test Case 來說，可以直接看到傳入的方法符合  getterOrOptions: (() => T) |