PTT推薦

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

看板Soft_Job標題[心得] Correct/Changeable/Clean Code;行為科學作者
AmosYang
(twy30)
時間推噓13 推:13 噓:0 →:2

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

--

※ PTT留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 136.56.2.86 (美國)
PTT 網址

taipoo04/15 07:15推你的觀點

jobintan04/15 08:00改得動比較重要,不用擔心改A壞B。

> 不用擔心改A壞B

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

Dinowchang04/15 09:21永遠有新東西要做,所以"再求好"永遠沒時間做

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

ian9091104/15 11:08

uijin04/15 11:31頭頭是道

Nonsense804/15 13:17很有趣

ming878604/15 15:08

TheTruth4404/15 17:34

goldie04/15 18:06

agra04/15 21:48如果高估改變成本並抗拒是人性,第一天就要求程式碼先改得動

agra04/15 21:48再往正確前進是否更合理?

> 合理

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

f82102704/15 23:44

※ 編輯: AmosYang (136.56.2.86 美國), 04/16/2021 01:16:34

leolarrel04/16 17:38真正好的code,就是老闆願意花薪水讓你重構的code

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

※ 編輯: AmosYang (136.56.2.86 美國), 04/17/2021 01:15:55

magus04/19 18:42

csfgsj04/20 10:55推用心