iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 2
0

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


圖片出自於: 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]: 位能 - 維基百科,自由的百科全書


上一篇
「可不可以不要寫糙 code 」指是什麼?
下一篇
過度使用全域變數
系列文
可不可以不要寫糙 code30

尚未有邦友留言

立即登入留言