聽完之後人資邀稿
寫完順便紀錄一下
----
聽演講之前有先看過Clean Architecture這本書
這場演講前面大部分的概念都有從書中聽過
最後面用一個範例展示,加上透過Teddy深入淺出的敘述有幫助我進一步理解架構的分層
Teddy會引導並鼓勵聽者跟他互動,如果都不回答
Teddy就會用諷刺的方式說,這就是全公司最好的答案了嗎?
一開場Teddy丟出一個問題"什麼是架構"
讓大家敘述一陣子之後,Teddy說
The architecture of a software is the shape given to that system by those who build it.
The form of that shape is in the division of the system into components, the arrangement of those components, and the ways in which those components communicate with each other.
架構等於軟體的形狀
架構把系統分成元件,把相同的東西整理在一起(在一起在一起)
最後再把元件溝通的方式定出來
然後Teddy就舉了一個例子,"家"就是一個架構
我們規劃出廁所 客廳 廚房
接下來我們就很清楚微波爐 馬桶放哪裡
客廳去廚房應該經過廁所嗎?
到這邊我都覺得淺顯易懂
BUT!
當Teddy說到"架構跟功能無關",我有點困惑
因為我覺得不同架構,通常不就是為了解決某種問題而存在著嗎?
我知道我們不應該被框架綁架,最重要的是保留彈性,盡可能插件化大部分元件
但我真的不太理解架構跟功能無關這句話
提出疑問,我的意思是"使用Client/Server架構感覺就是為了這個架構的功能存在"
Teddy的回答是 "就算是單機的程式我們也可以用client-server寫",我仍不太理解
後來Teddy用美術館外觀舉例,來解釋"架構跟功能無關"
四種不同外觀的建築都可以成為美術館,包含這間地下室
但我仍覺得同樣道理就無法套用到餐廳 機場 保齡球館
總之架構跟功能無關這點我仍無法理解,也許再閱讀更多架構的書籍會有不同想法吧
後來看Teddy的部落格文章,以下這句就比較同意
"雖然架構的外觀與功能基本無關，但好的架構本身卻需要能夠反應系統的功能。"
架構最好要一看就知道是做什麼
後來Teddy用不同建築的平面圖解釋會什麼叫吶喊的架構
那美術館的平面圖呢??我又困惑了
也許美術館本身的架構核心業務不是建築外觀本身吧
建築外觀對他來說是不重要的細節
美術館不變的核心價值是什麼?大家可以想一想
我覺得是展示並保護文物
要用什麼方式展示,如何安排動線是細節
有什麼保護規範,溫溼度控制與物理隔離,則是細節
軟體的終極目標是
不論在開發 佈署 維運 維護的哪一個環節都能夠
"最小化軟體生命周期的總成本 + 最大化程式設計師的生產力"
這句話說得非常好,有幾個重點要注意
"軟體生命週期",假設是一個隨手的測試程式,需不需要設計架構?
假設已經有一個維護多年的一大包程式碼,但認為他的架構有應該改善的地方
在"最小化生命周期的總成本 + 最大化程式設計師的生產力"的思維下
什麼時間點該投入部分開發資源去重構他,一直都是一個值得討論的問題
架構師這個詞總是讓我們想到重大的決定和厚實的技術實力
年輕的軟體開發人員似乎離架構很遠
但事實上,架構師應該要寫程式,並持續是個程式設計師
因為如果他們沒有遇到他們給其他程式設計師產生的問題,他們就不能把工作做好
架構可大可小,即便只是一個很小bash shell web cgi,也是有可能要考慮架構的
一個工程師如果沒有架構的思維,就可能在生命週期短的程式上投入太多設計架構的成本
或是在一個生命週期很長的程式上面,太小看它會造成的影響
因為一個cgi一但提供出去給其他人使用,他就不是細節了
他變成其他人的use case,會有越來越多的程式依賴在他之上
有一天它就變得不可變動,因為影響太大
好的架構必須保持選項是開放的
軟體系統可以分成策略跟細節,策略是業務規則也是核心價值
細節是其他能夠與策略溝通但不影響策略行為的一切必需品
細節包含IO設備,資料庫,web系統,伺服器,框架,通訊協定等等
隨著技術發展,需求改變,我們會改變細節
架構必須允許細節的決定能夠被延遲
"一個好的架構師可以將不作出決定的數量給最大化"
每一個程式設計師,不論頭銜是什麼,都應該保持架構師的思維
為了下一個接手的人好,或是為了三個月後的自己好
最後Teddy畫出一張靶圖
我在書裡面有看過這張圖,但我不是很理解
我知道分層的時候我們可以用一個簡單的方法
離IO越近的就是level越低,離IO越遠就level越高
level高的不希望受到level低的部分的變動影響
所以我們要從level低的往level高的依賴
Entity & Use case最好要完全隔離IO
被最多人依賴的,就是Entity,就是核心,也是最少改動的部分
上面幾句說起來簡單,設計起來難
層次到底要怎麼切?怎麼跨層?怎麼處理相依性?
最後演講的程式範例有稍微幫助釐清四層的界線在哪裡
書中有提到use case要定義input跟output的雙向介面
包含資料型別的實作,所以外部要傳參數進來時,要把參數轉型成use case的input
以上這些概念聽得懂,但還沒有融會貫通
接下來應該要繼續充實自己對軟體架構的分層與劃定邊界的能力
才能真正學以致用
