「軟體架構的目標是最小化 『建置和維護系統所需的人力』」

「架構的規則都是一樣的！ 年輕設計師可能會認為這是無稽之談，可能會堅定認為現在的一切都是新的、是不同的。很不幸，他們錯了。即使出現那麼多新語言、框架、範式...，現在的規則與 1946 年 Alan Turing 寫下第一個機器碼時，並無分別」

「本書就是要來講述這些規則的 － 那些永恆、不變的規則」

取自: Clean Architecture (p.10 & pp.xi-xiii)

CH1: 設計與結構

真實案例

• 回顧 Day1 ，我們曾提及為什麼要有良好的軟體設計與結構? 以 80 年代某不願具名軟體公司的內部統計資料簡述:
  工程人員的增長:
  
  同一時期的生產力:
  
  每行程式碼的平均成本:
  
  發佈版本與月開發薪資表
  

從上圖可發現

1. Release 版本 8 與 版本 1 相比，每行程式碼的平均成本高出了 40 倍
2. 對於開發者來說，他們的生產力將逐漸降到 0

   「盡管所有的英雄加了班也奉獻了精力，但他們根本不會得到任何東西了。現在這些努力是用來管理這個爛攤子的。他們的工作已經改變了，是用來將這個爛攤子從某個地方轉移到另一個地方，這樣他們就可以再增加一個小小的功能特性 (Feature)」

   取自: Clean Architecture (p.7)

3. 對於高層管理來說，最初每月僅花了幾萬美元就換得了許多功能，但最後的 30 萬美元卻幾乎沒得到任何東西!

什麼地方出了錯?

迷思: 編寫紊亂的 Code 可以在短期走得更快，只有長期下來才會變慢

• 過度自信: 認為未來有能力將製造的紊亂清除乾淨
• 製造紊亂總是比保持整潔的開發速度還要慢
• 走的快的唯一方法是走的好

CH2: 兩種價值觀的故事

每一個軟體系統都提供了兩種不同的價值

• 行為 (業務價值)
  我們透過幫利益相關者制定功能規格 (Functional Specification) 或需求文件 (Requirement Document)，並實作符合這些要求的程式碼來創造或節省資金
• 結構 (技術價值)
  如果我們希望機器的行為難以改變，我們會將之稱為硬體 (Hardware)，軟體被叫做是軟的 (Soft) 代表它是可以輕易改變機器行為的一種方式，也就是說，它必須很容易改變

迷思: 軟體系統「能動」比「好改」還重要

軟體系統能夠工作比較重要，還是軟體系統更容易變更比較重要?

「業務經理通常會說軟體系統能夠工作比較重要。反過來，開發人員也會經常跟著這種態度去做。但這是錯誤的態度」

取自: Clean Architecture (p.13)

論證一:

1. 如果有一個能動的程式，但不可能修改，那麼當需求改變時，這個程式將變得毫無用處
2. 如果有一個程式還不能動但易於更改，那麼我可以使其運作，並隨著需求變化而繼續運作。因此，程式將持續是有用的

讀者可能不覺得這說法有說服力，但是，確實有系統實務上不可能再改變，因為改的成本超過了帶來的利益

論證二: Eisenhower 矩陣

取自: https://hive.com/blog/eisenhower-matrix/

我們可安排做事的優先順序:

1. 迫切 (Urgent) 且 重要 (Important)
2. 不迫切 (Non-Urgent) 且 重要 (Important)
3. 迫切 (Urgent) 且 不重要 (Unimportant)
4. 不迫切 (Non-Urgent) 且 不重要 (Non-Important)

• 軟體的第 1 個價值 — 行為 (Behavior) 是迫切的，但並不總是特別重要
• 軟體的第 2 個價值 — 結構 (Structure) 是重要的，但從不特別迫切

我們可發現，程式碼的結構位於此 List 的前 2 位，而程式碼的行為只佔據了 1 & 3 的位置

為架構而戰

困境: 業務經理沒有能力評估架構的重要性

• 而這就是軟體開發人員該去做的，軟體開發團隊有責任
  1. 主張架構的重要性高於功能的迫切性
  2. 為對公司是最好的事情而爭鬥

「只要記住: 如果架構最後才出現，那麼開發系統將變得更昂貴。系統的最終修改將變得幾乎不可能」

取自: Clean Architecture (p.15)

Reference

1. How The Eisenhower Matrix Can Revolutionize Your Project Management Efforts