讀 Tidy first 心得

Kent Beck 正在點出現在軟體開發的調適性

這本書真的寫得很簡潔也很易懂，即使是英文我想閱讀起來也不是很困難。心得寫作我也寫得簡單一點，以下列點是我反思跟想後面實踐的部分。

先簡潔，再複雜

這個觀點非常基本，但是很常被忽略。在文章寫作上我們也是先寫的清楚，再開始較為複雜的邏輯解說，因為有個大方向被確認了，所以細節就變得容易。書中用下面的 Guard Clauses 來說明：

if queue_name not in self.Queues:
  ... handling some logic ....
return;

//改成
if queue_name in self. Queues:
  return

... handling some logic ....

這段神奇之處在哪裡？雖然只是把 not 的邏輯改成別的，然後 return，但身為 code reader，我就知道後面的邏輯都在處理 queue_name not in self.Queues 這件事，閱讀理解的負擔程度大幅降低。

其實光是稍微調整個排序，認知負擔改變得非常多，我覺得光是這件事就能影響不少事情，即使這只是非常非常小的事情。

雖然 Kent Beck 這幾個章節內容都很短，但是很值得用來 retro。不愧是最精煉的男人？

不要一開始就想著過度開發(over engineering)

一般初學 clean code, design patters, 或是 DDD 的人都會有過度工程的傾向，我也是這樣過來的，看到這本書之後我也拿來反思之前會不時想過度開發。在 Cohesion Order 的章節中， Kent 舉例很棒的公式：

cost(uncoupling) + cost(change) < cost(coupling) + cost(change)

雖然在講的東西是要不要 decoupling，但我們也能延伸到要不要用新技術解決某個陳舊的問題，一模一樣的公式。這個公式會陪伴我們到最後一個觀念：到底要不要執 tidy。

到底要不要執行 tidy

最後一個 part 真的很有趣，我第一次看到有搞軟工的傢伙把 time value 的概念引進軟體工程， Kent 說到選擇權的概念，是怎麼一回事？

原來 Kent 也在華爾街做過金融交易相關的軟體。這邊簡介選擇權是一種衍生性金融商品，買方花了權利金（手續費）要在未來買一個東西，他有權利以某個一開始約定好的價格，購買這個東西。那到底為什麼選擇權的概念出現在軟體工程這邊？

如果你聽過技術債，這個名詞用來解釋我們故意先欠著品質，後面再來還品質的債務，選擇權的概念其實也是差不多的，不過根據 Kent 的敘述以及文章的說明，他只考慮了 call option（我前面的說明）的概念。

Kent 提到軟體開發是一種設計，我們要改變軟體行為（或是其他行為）就是一種預期未來會很有價值的事，我們針對這個改變所做的設計是支付權利金的概念，用以購買改變未來的行動力。所以在過程中我們執行了好幾次買權（設計方案），最終我們找出最有價值的選擇權（設計方案）來執行我們的軟體設計達成目標。

結語

想起今年度很多東西都在喊左移，其實都是慢慢的把 time value 的概念(或是 DevOps 社群的艦長說的調適性概念)引入，都是為了賺取某種預期未來的價值呢！