文章同步於it邦

前言

今天要來講整個系列的重頭戲之一了 - Clean Architecture

這個主題一樣不太好寫，主要是時間不多，以及要用有限的篇幅來說明整本書其實非常困難
我推薦工程師們可以來看看這本書

我還是那句話，程式隨便找個人來寫都可以，但要寫好就不是那麼容易
要寫到不太需要解釋一看就懂更不容易
但一個產品的Code太爛是有機會使整個公司倒閉的

前幾週可以看到我分享了各種架構與設計面的例子
那我們回到根本的問題，到底什麼是設計？什麼是架構？兩者又有何區別？

CH.1 什麼是設計與架構

舉個例子，一棟房子的架構就相當於它的形狀、外觀、房間格局等等。那我的房子該怎麼裝潢就是設計，房間布局、插座位置、這個開關控制什麼等等。

換到程式面上來說，用我前幾週的文章舉例：
我使用CSR + MVC框架作為我後端程式的架構，內部的程式設計參考SOLID的各種原則。
用更實際一點的就是，前端：Vue3(CSR，把view拆開)，後端：PHP Laravel(MVC)，Code都要盡可能地符合 SOLID

這一切的目標就是

軟體架構的目標是最小化建置和維護『需求系統』所需要的人力資源
-Clean Architecture (P.4)

也就是說品質的標準就是看你每次滿足客戶需求時所花的精力。當隨著版本更新，所花費的精力變多的時候，就代表這個設計不好。

用一句我的話來說就是，你的設計不夠彈性！

引用書中的例子，書中舉出龜兔賽跑的案例

踏實和穩定持續是贏得比賽的關鍵。
這場比賽不是比迅速，也不是比誰強壯。
越快的，反而速度越慢。
-Clean Architecture (P.8)

部分開發者容易陷入，我晚點再來整理這些Code，只能先上市
進入市場後你只會發現，這些Code你不會清，且一堆競爭對手，你只能永遠跑在最前面。

然後為了保持產品的開發速度以及版本迭代，就會一直高速產出爛扣，但他們堅信這些只是短期會更好的做法，長期才會有影響。實際上是，產出紊亂的開發速度絕對比保持整潔的開發速度慢。

曾有人做過一個實驗，他每天都完成一個程式，將整數轉換成羅馬數字。當預定地驗收測試通過時，工作就完成。
每一天的任務花不到30分鐘，第一天、第三天、第五天使用了測試驅動開發(TDD, test-driven development)的著名簡潔原則，在另外三天則不遵守原則。

結果顯示，使用TDD的時間比起非TDD快速，時間省了接近10%

所以，一言以蔽之就是

想要走到快，唯一的方式就是走的好。
-Clean Architecture (P.10)

所以阿，那些還在說單元測試不重要的，其實就是你沒有去了解跟嘗試而已
現在，就，開始，寫測試。

其實這可以呼應到Clean Coder中 Uncle Bob對於進入心流區(心理學中稱為 flow)的反對
Uncle Bob認為這會雖然使開發效率上升，但實際上你只會容易寫出一堆難改的Code而已

這些技巧其實會再導入敏捷開發時更為有效，當我們將需求的粒度切小，就有機會一直將產品快速的產出以及交付。此時，在這個情況下，就必須將程式碼調整得更加彈性，不然改不動的狀況就會很快出現。

關於敏捷開發，會在最後的期間才會講到，請到大家稍等。

Clean Architecture ch.1
龜兔賽跑
以前修心理學的印象