VIVOTEK Digest

從 Clean Architecture 我們學到要把程式架構畫出來，把核心邏輯與其它細節分開來, 避免核心被汙染，達到最終目標：「最小化軟體生命周期的總成本+最大化程式設計師的生產力」。書本裡面給了一個四層的架構圖：Enterprise Business Rules, Application Business Rules, Interface Adapters, Frameworks & Drivers。簡單說前面兩個就是策略、業務規則、核心價值，後面兩個則是細節、資料庫、框架、通訊協定…等等。在這樣的分層規劃下，我們得以確認依賴關係是由外向內的。如果有需要，我們會利用依賴反轉(Dependency inversion principle，DIP)來維持核心的整潔，這樣的架構也允許我們延遲細節的決定。

事件風暴

第二堂課, Teddy帶我們體驗事件風暴(Event Storming)，事件風暴是一種快速讓群體進入狀況, 跨部門達成共識的方法，不限於軟體，其實可以應用在各種業務領域，協助建構模型。事件風暴的介紹網路上可以查到很多，規則與範例就不在此贅述，因為事件風暴最重要的是溝通的過程，使用文字敘述很難體會，課程後我與YK(同事)為了讓更多同事也能了解這個溝通方法，因此辦了一個小workshop，邀請了三個不同部門的同事，其中包含測試部門、韌體研發、新技術開發部門一起共同討論「韌體自動化測試工具」這個主題。

共通語言

首先，大家想的真的都不一樣。我們先把12個人分成四個小組，讓大家各自列出這個系統中應該存在的Entity再來互通有無一下，結果發現：有一些東西大家都有共識(每一組都有塞一個專家)，一定會有test case，也一定會有report，有一些東西則是我有你沒有，你有我沒有。但是即使是一樣的東西，各自表述之後就會發現，你的report跟我的report可能又不一樣，A組的包山包海，測試結果/細節步驟/結果統計圖，B組的只有成功與失敗，另外還有一個叫做debug log的會包含細節，沒有一個絕對的答案, 重要的是我們要找到共同的語言(ubiquitous language)。共通語言除了釐清彼此的想法以外，還有加速溝通的效果，建立共通語言後，可以提升溝通效率，不論是文件、程式或開會。例如當要做一個跟影像有關的專案的時候，我們可以在早期建模的溝通過程中，發現是不是所有成員都有3A的觀念，知道AE, AF, AWB是什麼，避免專案走到後期，才發現彼此有很大的誤解。