從 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是什麼，避免專案走到後期，才發現彼此有很大的誤解。
可視化流程
除了共通語言以外，事件風暴還提供了一個全面的可視化流程，我們同步大家的共同語言後，把四組合併成兩個組進行事件風暴，我們故意讓大家先用傳統方法從Entities開始發想，再補充上use cases，讓大家先跑一次流程。
事件風暴跟從核心出發不一樣，而是從領域事件開始展開(我們認為有點像是從use cases展開)，兩組分別列出我們在乎的領域事件，看到大家不斷的貼上、移動、調整，對整個流程重新順一次，我想這就是事件風暴要的效果，最後產生一個看得到的用戶故事(User stories)。
我感覺event storming有點類似非coding版本的mob programing，用一種方法把群體的思維聚焦在同一個問題上，並且利用交流讓整體意識調整到相同頻率取得共識，共識後的產物是經過大家認可的業務邏輯與範圍，所以真正執行或實作的時候大家是朝同一個目標努力的。
|
Trending
-
「不要試圖覆蓋所有使用案例。Spec.不是用來替代組合回歸測試的。」 － Spec by Example 中文版 p.151 但我們明明覺得現在用 Robot Framework 實現自動化 UAT 來替代組合回歸測試是很正確的做法，為什麼作者覺得這樣不對? 我認為... -
平常 C++ 的開發工具是 Microsoft Visual Studio，然後現在的測試框架是使用 Google Test，以前都是一邊寫，一邊手動執行 test case 來驗證，沒有辦法跟 VS 內建的 Test Explorer 做整合，真的蠻原始的 =.= 最近因為... -
「從A到A+」這本書已經上市十餘年了，裡頭一個很重要的觀念就是－ 先找對人，再決定要做什麼 。最近 「 Google 模式 」 一書也很夯，在 Livehouse.in Sega 的 加持 下，在網路上更是瘋狂的洗板 XD，而裡頭一個很重要的觀念，一樣是 先找對人，再來做事... -
針對常用的match role, 可利用QHash (or QMap) 多存一份, 來加快 search 效率 我們在設計model通常都會定義一個存unique string value的IdRole當作model item的索引, 且會很頻繁對這個role作ma...
