[心得] Correct/Changeable/Clean Code;行為科學

Correct/Changeable/Clean Code 與行為科學

> "I know it when I see it."

「我看到時就會知道」這句話可用在以下情形：

某人在試著去定義一件事，但那件事本身是主觀的、沒有明確的定義；那個人就可
以說「 (我不知道該如何去定義那件事，但) 我看到時就會知道」。

在 1964 年，美國最高法院大法官 Potter Stewart 在審理一言論自由案件 (某一
電影被州法院認定為「猥褻」 (obscenity, 不受言論自由保護), 案中的藝術電影
院經理上訴到最高法院) 時， Stewart 表示他大概永遠無法明確地定義「什麼樣
的東西才符合『硬色情』的定義，但「我 (Stewart) 看到時就會知道」。

我對 "dirty code" 有類似的感受；我無法確實定義何謂 dirty code, 但我看到
時就會知道 XD 而因為無法確實定義 dirty code, 我換從 clean code 的角度來
看，抽出兩個概念：

* Clean Code 無瑕的程式碼
* Correct Code 正確的程式碼
* Changeable Code 改得動的程式碼

我主張「無瑕的程式碼是『改得動的正確程式碼』通過多重需求變動考驗的產品。」

# 「正確的程式碼 (correct code) 」第一

正確的程式碼帶給顧客「顧客想要的價值」。

* 付錢的人才是顧客
* 顧客付錢給你，是為了更接近它的目標 (更好的自己 / 更好的環境)
* Job to be Done, JTBD; 顧客為了更接近它的目標所必須完成的工作項目

* 正確的程式碼能滿足顧客的 JTBD 。

# 「改得動的程式碼 (changeable code) 」第二

改得動的程式碼讓疊代進化是可行的。

* 是否可維護 ( maintainable ): 在改動程式碼邏輯後，能否測試既有功能仍正
確運作？

* 是否可重構 ( refactorable ): 在改動程式碼架構後，能否測試既有功能仍正
確運作？

* 建構 ( build ) 及 佈署 ( deploy ) 能否穩定可靠地重覆執行？

* 能否追蹤「誰為了什麼在何時動了什麼 code ; 佈署了哪個版本」？

# 「無瑕的程式碼 (clean code) 」第三

是否可擴充 ( extensible ) / 滿足新需求 ; 是否優雅 ( elegant / graceful /
style ) ; 是否好懂 ( easy to understand ) ; 是否效能最佳化 ; 是否符合潮流 ;
是否能規模化 ; 等等。

# 行為科學

以上論述的「 correct 第一、 changeable 第二、 clean 第三」可簡化為「先求
有，再求好」，但為什麼後半句的「再求好」在現實中很難做到？

原因是因為：

* 人腦會高估「現狀、已擁有的東西」的價值達 2~4 倍。
* 人腦會覺得「利益要是成本的 2~4 倍」才值得做出改變。

也就是為什麼會不時會聽到「用 資料夾+日期 做版控，不願改變」的故事。

## 那麼，該怎麼辦？

這是個很微妙的問題，它有兩個層次：

(1) 「人腦抗拒改變」是個行為科學的題目，不是「科技技術」的題目。從行為科
學的角度著手會有效很多。

(2) 這篇文章的讀者 ( Soft_Job 版鄉民、我的 FB 追蹤者 ) 應該有不少是
「習慣了從『科技技術』角度著手解決問題的工程師」，我們能否 *改變*
我們自己從「科技技術」角度著手解決問題的習慣呢？

這裡有兩個切入的角度：

(a) 提昇大腦對 改變帶來的利益 的感受

以 "dirty code" 為例，與其從「 dirty code 的功與過」著手，不如從以下
角度切入：

* Correct Code 能讓我們拿到今天的薪水

* 學會「導入、實現 Changeable Code 文化」的能力，事實上是在學「行為
科學 / 呼叫人腦 API 」的能力，也就是「影響力 == 銷售能力」，能讓我
們明天拿到更好的待遇

(b) 降低大腦對 改變需要的成本 的感受

這可以想像成：一樣是往上爬升 10 公尺，「爬 100 階 10 公分的樓梯」會
比「爬一面 10 公尺的牆」簡單得多。

這個在這一單篇文章的篇幅中很難做到，因為每個人的「成本」不太一樣，大
致上可歸納為以下兩種荷爾蒙的影響：

* 有些人是以 多巴胺/成就感 為 (主要) 能量來源；過關斬將一點一點進步
，會帶給它的大腦很多獎勵。

* 有些人是以 催產素/歸屬感 為 (主要) 能量來源；跟志同道合的夥伴一起
學習，會帶給它的大腦很多獎勵。

在這樣一篇單向傳遞訊息的文章中，很難做到。

---

先寫到這裡。

歡迎提問、討論 :)

---

一些參考資料：

英文：行為、心理
* https://hbr.org/2006/06/eager-sellers-and-stony-buyers-understanding-the-psychology-of-new-product-adoption
* https://www.hanselman.com/blog/maslows-hierarchy-of-needs-of-software-development
* https://dubroy.com/blog/a-hierarchy-of-needs-for-code/

* 中文： Kano 滿意度模型： https://www.hansshih.com/post/85896168800/kano

--

同意；短短八字道盡 軟工至高境界 之一 XD

是的，陷在那樣的困境中，有想更上一層樓的心，但不得其門而入，是很難受的。 有興趣的話可以來談談你覺得的「好」該是什麼樣子，然後一起來找方法把那個 「好」拆成更小的題目，來實現它。

這需要把「合理的『理』」的脈絡納入考量，例如說： * 目前有多少糧草？ * 還能撐多久？ * (硬幹 "dirty code" ) 做到「正確」要花多少糧草？ * 能得到多少糧草？ * 怎麼樣才算「改得動」？ * 例如說，目前產品的複雜度，是需要全套的「 CI + CD + 自動化測試」，還是 「 (有版控的) build / deploy script ; 加上測試步驟列表文件」就可以先 頂得住？ * 做到「改得動」要花多少糧草？ 把這類脈絡納入考量後，會比較容易判斷「是否合理」 :)

同意；「有人願意出錢買帳」是最直接的驗證價值的方法。