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

作者: AmosYang (泛用人型編碼器)   2021-04-15 06:22:51
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 公尺的牆」簡單得多。
這個在這一單篇文章的篇幅中很難做到,因為每個人的「成本」不太一樣,大
致上可歸納為以下兩種荷爾蒙的影響:
* 有些人是以 多巴胺/成就感 為 (主要) 能量來源;過關斬將一點一點進步
,會帶給它的大腦很多獎勵。
* 有些人是以 催產素/歸屬感 為 (主要) 能量來源;跟志同道合的夥伴一起
學習,會帶給它的大腦很多獎勵。
在這樣一篇單向傳遞訊息的文章中,很難做到。
作者: taipoo (要成功要積極)   2021-04-15 07:15:00
推你的觀點
作者: jobintan (Robin Artemstein)   2021-04-15 08:00:00
改得動比較重要,不用擔心改A壞B。
作者: Dinowchang (Dinow)   2021-04-15 09:21:00
永遠有新東西要做,所以"再求好"永遠沒時間做
作者: ian90911 (xopowo)   2021-04-15 11:08:00
作者: uijin   2021-04-15 11:31:00
頭頭是道
作者: Nonsense8 (胡說)   2021-04-15 13:17:00
很有趣
作者: ming8786   2021-04-15 15:08:00
作者: TheTruth44 (WillieTheLord)   2021-04-15 17:34:00
作者: goldie (阿良)   2021-04-15 18:06:00
作者: agra (一審有罪就下台!)   2021-04-15 21:48:00
如果高估改變成本並抗拒是人性,第一天就要求程式碼先改得動再往正確前進是否更合理?
作者: f821027 (蛋餅)   2021-04-15 23:44:00
作者: leolarrel (真.粽子無雙)   2021-04-16 17:38:00
真正好的code,就是老闆願意花薪水讓你重構的code
作者: magus (Magus)   2021-04-19 18:42:00
作者: csfgsj (切割對半)   2021-04-20 10:55:00
推用心

Links booklink

Contact Us: admin [ a t ] ucptt.com