良好程式碼的優點大同小異。
不好的程式碼的糙點卻各有巧妙之處。

圖片出自於: https://unsplash.com/photos/dq7kElwnFFg

先解釋什麼是「複雜性」

看過人月神話的朋友相信都知道《沒有銀彈》這篇論文裡提到

軟體的複雜是屬於本質上的特性，而非附屬的特性。
--《人月神話》, 沒有銀彈: 軟體工程的本質性與附屬性工作, p.239

這篇論文，我個人的解讀如下

軟體工程的工作分成本質性問題與附屬性問題

1. 本質性問題: 本身保有一定的複雜性，無法降低 → 沒救了
2. 附屬性問題: 管理複雜性的手法，太多種了 → 學不完

所以軟體工程的工作內容是「管理複雜性」

良好的管理複雜性[1]

如何把軟體工程的工作做好，等同於如何做好管理複雜度

David Parnas 主張，模組應該要被良好的介面封裝 (encapsulate) 起來，模組的內部應該是程式設計師私有的東西，不應該公開讓人知曉，不是他負責的模組，就要對其內部機構加以保護，而非曝露出去，這樣程式計師做起事來會最有效率
--《人月神話》, 《人月神話》二十年, p.345

用例子看複雜性

問題本身: 用瀏覽器的 console 印出 hello world 吧!!

本質性問題，用程式碼呈現的最低底限

console.log('hello world')

附屬性問題，管理複雜性

呼叫 function 印出 hello world

function print(words) {
  console.log(words);
}

print('hello world')

用 Object 的 Methods

const object = {
  method: function (words) {
    console.log(words)
  }
}

object.method('hello world')

這一行 hello world 代表著會真正執行目標的程式碼。
而其它的程式碼是用來輔助管理，讓開發者容易理解、好猜中、好找...這樣的程式可能在訴說著什麼樣的內容。

這有什麼厲害之處？

也許你會說，這是架構問題呀，這不是寫不寫 糙 code 的原因呀。

來看一些生活上或以前國高中會遇上的例子

# 這是曝露過多複雜度的例子
F = (m * x * h) / (s * s) ## 單位: kg * m^2 / s^2

這是什麼？
這不是一般這個物理定律出現在人們眼中的樣貌。
無法直覺的理解，而心中不由自主的出現了「這在寫什麼？」的問題
也許在這問題前，還有個發語詞「糙」

整理先逆推一下這個公式

E = m * x * 1/s * 1/s * h ## v = x / s
E = m * v * 1/s * h       ## g = v / s
E = m * g * h             ## 原本的樣貌

這是一個位能[2]的公式。

用了四個符號，代表著一個「能量」概念的表現，以及可以改變能量的變因。隱藏了不必要的複雜度: 將「加速度」的概念呈現成一個符號。

回到軟體與複雜度，又有什麼「糙點」？

而軟體工程，由在人月神話作者的論文「沒有銀彈」中就已經提到這個使用方式。

數學和物理學之所以能在過去三個世紀突飛猛進，就是藉由為複雜現象建立出簡單的模型 (model) ，然後從模型中推導出現象的特性，並透過實驗來驗證這些特性。
這種方式之所以行得通，是因為在模型中所排除掉的複雜性 並非現象的本質。
--《人月神話》, 沒有銀彈: 軟體工程的本質性與附屬性工作, p.239

運用這樣的技巧，就可以實現這種，將問題看似簡化，其實保留本質的做法。

之後的文章內容，將會大量的運用這樣的技巧並且帶入其它相輔相成的觀念

[1]: 《Code Complete 2/e》, Ch5 Design in Construction, Importance of Managing Complexity, (中文版 p. 81)
[2]: 位能 - 維基百科，自由的百科全書