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

要解決的問題：

  • 當要程式中增加功能、解決 bug 時，能：

    • 有概念知道「要修改的地方們」在哪
    • 能快速切換到「要修改的地方們」
    • 能在「要修改的地方們」之間快速切換
      *「修改的地方們」很容易修改
    • 「修改的地方們」不多

  • 當程式要重構時，能：

    • 測試重構後，外部行為是否一樣
    • 輕易搬移搬動程式、不產生 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
    2
    3
    4
    5
    6
    7
    8
    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.
因為我們是人類，只有相當有限的注意力、短期記憶和工作記憶空間。