本書對「複雜性」採取一個務實的定義：

複雜性是任何與軟體系統結構有關、使其難以理解或難以修改的特性。

換言之：難以理解、難以修改 → 複雜；容易理解、容易修改 → 簡單。

複雜性的多種樣貌#

複雜性可以以許多形式呈現，例如：

• 看不懂某段程式碼是怎麼運作的
• 想做一點點小改進，卻得花上很多力氣
• 不清楚系統裡哪些部位需要被修改才能完成任務
• 修了一個 bug 卻又冒出另一個

從成本與效益的角度理解#

• 複雜系統：要做出一點小改進，都需要投入大量工作
• 簡單系統：相同甚至更大的改進，反而花費較少力氣

複雜性與系統規模無關#

人們常用「複雜」來形容大型且功能繁複的系統。但本書的定義裡：

• 即使是大型系統，只要好維護，就不算複雜
• 反過來說，一個小而功能單純的系統，也可能極其複雜

當然在現實中，幾乎所有龐大且精細的系統都很難維護，所以它們也符合本書定義的「複雜」。

複雜性由「最常見的活動」決定#

如果系統某些部位非常複雜，但幾乎沒人會碰它們，那它們對整體複雜性的影響就有限。可以用一個粗略的數學式來表達：

$$ C = \sum_{p} c_p \cdot t_p $$

• $c_p$：第 $p$ 部分的複雜度
• $t_p$：開發者花在該部分上的時間比例
• $C$：系統整體的複雜度

把複雜性隔離（isolate）在沒人會看到的地方，效果幾乎等同於完全消除它。

複雜性對讀者比作者更明顯#

• 你寫的程式自己覺得單純，但別人覺得複雜——那它就是複雜的
• 遇到這種情況，值得追問對方為何覺得複雜，多半能挖出有趣的教訓

身為開發者，你的職責不只是寫出自己好維護的程式，而是寫出別人也容易上手的程式。