如何讓程式可維護 / 重構的方向 / 程式開發中的互動設計

要解決的問題：
I. 當要程式中增加功能、解決 bug 時，能：
   1. 有概念知道「要修改的地方們」在哪
   2. 能快速切換到「要修改的地方們」
   3. 能在「要修改的地方們」之間快速切換
   4. 「修改的地方們」很容易修改
   5. 「修改的地方們」不多

II. 當程式要重構時，能：
   1. 測試重構後，外部行為是否一樣
   2. 輕易搬移搬動程式、不產生 bug

解法：
把程式切成小區塊，每個區塊只負責單一功能，幫這些區塊建立資訊架構，架構中設計狀態的流程管理。對應工作內容規劃工作環境。用多次微重構，代替大改。先重構、再解 bug、最後才寫新功能。在多人開發、或經常重構的專案，對穩定的外部 API 建立自動化測試。

好習慣：

把程式切成小區塊 ( ex: 4 - 30 行的小 chunks)
   好處：
      好理解、好修改、也容易增加新功能、能塞進人腦的工作記憶裡
  
   方法：
      每個程式區塊 = 一個檔案 or 一個 function or 一個 folding
      每個區塊行數 (after folding)，大於一個螢幕可以顯示時就要 Refactoring


每個區塊只負責單一功能
   好處：
      容易重複利用、減少 dependency、容易理解、容易找到 debug
 
   方法：
      多寫純函數 / Stateless API、良好函數/模組命名、註解輸入/輸出參數


建立程式碼的資訊架構
   好處：
      容易找到要修改的地方 (在人很有限的 short-term memory 消散之前)
 
   方法：
      把程式碼區塊分類
         依功能：模組 / MVC / 前後端 / 測試 / Layout or 細節 / Stable or Develop / Web or iOS or Android
         依架構：樹狀主從架構 / 分階層 / Data Layer / Rendering Layer
         依時間：version


在架構設計中使用流程管理
   好處：
      增加可預測性、減少程式碼依賴
 
   方法：
      單向資料流、State Machine、Single Source of Truth


對應的工作內容建立環境
   好處：
      在程式碼區塊 / 外在環境中移動時，大腦不會 context switch

   Web 互動環境設計：
      1. 要規劃在下列環境簡單移動的方法 (環境一樣要有架構、資訊權重)
            a. editor & browsers
            b. shell / server / database / git
            c. editor 中的不同檔案
            d. 同個檔案中的 區塊、行、字母
            e. MDN / stack overflow / Google Search / Github Search
      2. IDE / shortcut switch / 多螢幕環境 / 切割螢幕畫面
      3. Font / Syntax Highlight / AutoComplete / 文法檢查

 Micro-Refactoring
    好處：
      一次改一點比較好測試、失敗的損失也比較低

 改程式碼的優先順序：重構 > 修 bug > 增加功能
    好處：
      重構會讓修 bug 變簡單、修完 bug 會讓增加新功能變得簡單

 為不常改變行為的外部 API 建立自動化測試
    好處：
      每次重構時能夠確定沒有破壞這些 API

—
Simplicity is the prerequisite for reliability — by Dijkstra.
因為我們是人類，只有相當有限的注意力、短期記憶和工作記憶空間。