從 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,用一種方法把群體的思維聚焦在同一個問題上,並且利用交流讓整體意識調整到相同頻率取得共識,共識後的產物是經過大家認可的業務邏輯與範圍,所以真正執行或實作的時候大家是朝同一個目標努力的。
|
在我們團隊快要一年了
一年的時間
寶寶可以長牙
台灣可以賣出 10 億杯飲料
營業額可以突破千億…
營業額可以突破千億…
| 經濟部統計處: 飲料店營業額在台灣逐年攀升 |
不說飲料
最近回顧了這一年的行事曆
我是有點吃驚的
我是有點吃驚的
OMG!
原來工作的方式,可以這樣影響生活
越工作越有活力
原來工作的方式,可以這樣影響生活
越工作越有活力
如何影響呢?
我先賣個關子,先來看幾個大部分的組織會遇到的現象。
第一個常見現象:開週會
Why are meetings so ineffective?
一個規模不大的四人團隊
一人報告一小時
一場 weekly meeting 就是四個小時
一人報告一小時
一場 weekly meeting 就是四個小時
如果你曾經有在電影院睡著的經驗
應該不難體會四個小時以上的會議有多累
應該不難體會四個小時以上的會議有多累
為什麼 weekly meeting 要開這麼久?
畢竟是一週的進度回報,如果每個人報告一個小時
相當於把他五個工作天,一天八小時的工作量
用 40 倍速的快進,講給你聽
奇怪的是,我們心理從來沒有出現這樣的聲音
“哇! 我聽到了 1/40 的超級濃縮精華/乾貨耶! ”
我們只希望他能再快個 40 倍
這不能怪同事,就像在電影院睡著其實也不能怪導演
這不能怪同事,就像在電影院睡著其實也不能怪導演
沒有哪個導演拍片是為了讓觀眾睡的
比較可能的是 —
那個議題和你沒有共鳴
Great movies tell stories that have deep emotional resonance
|
第二個常見現象:同事間的工作互換困難
Why is collective work difficult?
我們很常因為負責了某個案子,後續的東西都交給你來處理
因為這是短期看來最省時間的做法
因為這是短期看來最省時間的做法
當你在公司一陣子了,你會自然而然地有一個對照表:
“X module 的問題要找同事 A
Y module 的問題找同事 B”
“X module 的問題要找同事 A
Y module 的問題找同事 B”
你應該也對這種情況不陌生 —
同事 B: “A 請假耶,這問題要等他回來才能處理喔! ”
很少同事 B 會說: “A 請假,那你先把東西給我,我可以處理”
同事 B: “A 請假耶,這問題要等他回來才能處理喔! ”
很少同事 B 會說: “A 請假,那你先把東西給我,我可以處理”
但其實,這種工作互換、集體協作的例子,在生活中明明很常見
比如說便利商店的店員,A 忙著做咖啡、B 來幫忙結帳
從沒見過哪個店員跟你說:
“不好意思我不能幫您結帳,負責收銀的今天請假,我只會泡咖啡”
“不好意思我不能幫您結帳,負責收銀的今天請假,我只會泡咖啡”
上述這種情況在組織裡卻很常發生,原因是什麼呢?
可能是訓練文化
不知不覺把 ”人” 訓練成一台 “機器” (咖啡機/收銀機)
不知不覺把 ”人” 訓練成一台 “機器” (咖啡機/收銀機)
因此當我發現這裡的 team member 可以輕鬆的交換手頭上的工作
我是很驚訝的
我是很驚訝的
Machine learning or human learning?
|
第三個常見現象: 加班
Why work overtime?
你有玩過比手畫腳這類的傳話遊戲嗎? 通常結果都是各種歪樓
你可能會說,如果大家都能看到題目就不會有問題
No,還是不行
比如先前 U Think I Do 系列
就把朋友、家人、社會、學校、自己
看到一件事情的不同面向
放在一張圖裡,非常有趣
比如先前 U Think I Do 系列
就把朋友、家人、社會、學校、自己
看到一件事情的不同面向
放在一張圖裡,非常有趣
不同角度的生命科學系
|
撇除那種時程明顯不合理的情況
大多數的加班來自於
每個人對事物的理解不同:
大多數的加班來自於
每個人對事物的理解不同:
以為自己了解對方想要的功能
↓
發現不是對方想要的功能
↓
“盡量” 修改,改不完就加班
↓
發現不是對方想要的功能
↓
“盡量” 修改,改不完就加班
這個 “盡量” 可能妥協了很多事情
如果前面幾次靠著加班,都很幸運的在 deadline 前完工了
如果前面幾次靠著加班,都很幸運的在 deadline 前完工了
再遇到這種情況的時候,就會習慣性的把加班變成解決方法
而忘了去想該修正哪些流程
而忘了去想該修正哪些流程
又下班了?! 我還想工作
|
PM、RD、UX 都用自己的角度去理解、開發功能,在溝通不足、流程不透明的情況下,這個專案就會越來越像一個黑盒子
當老闆問這件事情什麼時候可以做完
是不會有人知道的
是不會有人知道的
高中物理就告訴我們,根據不確定性原理
專案的完成和沒完成,是同時存在的
只有打開黑盒子的一瞬間才會塌縮到一種可能性上
這種 “既完成又沒完成”
把人逼的 “既死又活” 的現象
把人逼的 “既死又活” 的現象
我們稱之為 —
薛丁格的專案
Schrödinger’s Cat 薛丁格的貓
|
本篇文章未完,你可以現在前往 Part2
也可以往下滑留下一些意見
The Year of Being Agile (Part 1)
我們再歸納一下,一般的組織常遇到三個現象:
1. 開冗長的週會
2. 同事間工作互換很困難
3. 加班
2. 同事間工作互換很困難
3. 加班
而我們 team 恰恰相反,有這三個很獨特的地方:
1. 不用開週會
2. 協作容易,你的同事就是你的分身
3. 不用加班
2. 協作容易,你的同事就是你的分身
3. 不用加班
這些特徵好像很難同時並存,你想,不開會怎麼知道同事在做什麼?
同事之間不了解,溝通成本就大
人越多就越複雜,花的時間也多
怎可能不用加班事情還能準時做完?
敏捷開發
Why OverCooked can teach you agile?
來講講 OverCooked 這個遊戲
一開始食物的訂單不多,每個人可以各司其職
專門切肉,專門煮菜,專門洗碗
而隨著訂單暴增和廚房地形改變
如果還是一個人只負責做一件事,時間肯定是不夠用的
一款具備敏捷精神的遊戲
|
Get back in sync
左上角可以看到現在的訂單有哪些
一回合的時間完成越多訂單得分越高
這是一款用嘴巴打仗的遊戲
你準備要拿料還是煮菜
需要什麼幫忙
哪邊需要修正
都要即時說出來
每個玩家都可以看到夥伴的狀況
這種快速 team sync 的方式就是 —
daily scrum meeting / standup meeting
Realtime review
這款遊戲一次最多四位玩家
如果有八個人玩呢?
一般情況就是多出來的四個會在旁邊
觀戰並且嘴砲給建議
等到下一回合再換這一組人拿搖桿
這種 driver & navigator 的方式 —
pair programming / mob programming
The programmer as navigator
|
介紹完遊戲,應該就不難回答我們一開始的問題
How to avoid boring meetings?
這個 team 不是不開會
而是不開沒有效率的會
daily meeting 有一些限制:
最多 15 分鐘,站著開
類似遊戲一回合的計時制
講求快速同步最新狀況
How to develop a cohesive team?
再來講協作:
關心不等於了解
想要了解一件事情
沒有什麼比實際參與還有效的
針對複雜的 task 安排 pair / mob
提倡 collective code ownership
簡單說就是共榮共享
但這樣講可能有點土
所以來看一下維基百科的定義:
合作或協作(英語:Collaboration)是指一種由兩個或兩個以上的個人或團體作為一個共同的目標而交集或在一起共同工作,舉例說明:一個知識分子可以透過合作的關係而去分享知識,再而經過學習和共識達到創作的目標
從上面描述看的出來
合作和凝聚力脫不了關係
那怎樣才能有好的凝聚力呢?
借用本公司的四大核心價值
誠信、 關懷、創新、當責
誠信、 關懷、創新、當責
肯定每個人的付出
讓每個人都看到自己的貢獻 —
一個人走得快一群人走得遠
Why collective intelligence matters?
電影環太平洋裡面
龐大的機器人無法由一人駕駛
需要兩位駕駛員連接彼此的腦神經
共享對方的情感、記憶、經歷
並且認同對方的處境之後
才能同步操控
Pacific Rim: Uprising (2018)
|
好的溝通和協作
就是用心和時間
灌溉的共同記憶
他會形成一個生命體
持續成長
或者說他就是一個生命
你們必須承擔起照顧這個生命的責任
也是這份承擔
讓你們之間的關聯
獨一無二
True collaboration yields better results
|
Iteration based method
Iteration 翻成中文『迭代』
在敏捷方法中是指
把一個大任務切成許多小週期可以完成的的任務
把一個大任務切成許多小週期可以完成的的任務
騰訊創始人馬化騰說:
小步快跑、快速迭代
小步快跑、快速迭代
這是他的產品思路
也成為互聯網創業法則
也成為互聯網創業法則
敏捷開發裡的迭代週期是一個 sprint
sprint 這字有短跑衝刺的意思
很符合迭代的概念
一個 sprint 一般為 2 ~ 4 週
sprint 這字有短跑衝刺的意思
很符合迭代的概念
一個 sprint 一般為 2 ~ 4 週
由團隊討論這個 sprint 能完成的功能
並在 sprint 結束時做個『試營運』
並在 sprint 結束時做個『試營運』
拿到客戶的 feedback
並且快速的衡量修正
並且快速的衡量修正
為了好懂,借個圖舉例
比較了傳統方法與敏捷開發法
如何在三個迭代週期完成蒙娜麗莎
如何在三個迭代週期完成蒙娜麗莎
Jeff Patton did an Iterative Mona Lisa.
|
先來看傳統的開發方法:
在第一階段可以看到蒙娜麗莎的頭
第二階段能看到蒙娜麗莎的左下半身
第三階段是完整的蒙娜麗莎
在第一階段可以看到蒙娜麗莎的頭
第二階段能看到蒙娜麗莎的左下半身
第三階段是完整的蒙娜麗莎
換成用敏捷開發會怎樣呢?
在第一階段是極簡主義派的蒙娜麗莎
第二階段是簡單上色派的蒙娜麗莎
第三階段是佛羅倫薩畫派的蒙娜麗莎
第二階段是簡單上色派的蒙娜麗莎
第三階段是佛羅倫薩畫派的蒙娜麗莎
不論哪個階段都是最小可行產品
很傳神地描述了敏捷的精神 —
很傳神地描述了敏捷的精神 —
接受反饋、迅速擴張
盡快給客戶有價值的產品
盡快給客戶有價值的產品
敏捷帶來的影響
How does agile affect my work and daily life?
所以回到一開始我賣的關子
那個讓我吃驚的行事曆
那個讓我吃驚的行事曆
我發現從以前到現在
晚上時間的利用有了很大的改變
從同事電腦辦公桌變家人散步吹吹風
以前晚下班總要負責關公司的門
有時候關得太順就會不小心鎖到別人
下圖的例外就是我補充的
關門 SOP
|
這一年有了固定的下班時間後
我開始能每天帶著媽媽去運動
我開始能每天帶著媽媽去運動
運動的地方是學校的操場
晚上學校警衛要關門的時候
看著警衛一邊關燈一邊趕人
看著警衛一邊關燈一邊趕人
這種熟悉又親切的感覺 —
等我退休了或許可以來當警衛吧 😝
前是把家當旅館現在是家事盡量管
The Year of Being Agile (Part 2)
平常 C++ 的開發工具是 Microsoft Visual Studio,然後現在的測試框架是使用 Google Test,以前都是一邊寫,一邊手動執行
test case 來驗證,沒有辦法跟 VS 內建的 Test Explorer 做整合,真的蠻原始的 =.=
最近因為 TDD 的關係,這樣子的開發環境真的太鳥了,所以認真研究了一下解決方案,發現了 Google Test Adapter 這個好東西:
https://github.com/csoltenborn/GoogleTestAdapter
很簡單,照著 github 上的說明安裝完後就可以使用。幾個要注意調整的地方:
public class E : VisualCommanderExt.IExtension
{
public void SetSite(EnvDTE80.DTE2 DTE_, Microsoft.VisualStudio.Shell.Package package)
{
DTE = DTE_;
events = DTE.Events;
documentEvents = events.DocumentEvents;
documentEvents.DocumentSaved += OnDocumentSaved;
}
public void Close()
{
documentEvents.DocumentSaved -= OnDocumentSaved;
}
private void OnDocumentSaved(EnvDTE.Document doc)
{
if(doc.Language == "C/C++")
{
DTE.ExecuteCommand("Build.BuildSolution");
DTE.ExecuteCommand("Test.RunAllTestsInSolution");
}
}
private EnvDTE80.DTE2 DTE;
private EnvDTE.Events events;
private EnvDTE.DocumentEvents documentEvents;
}
完工,現在只要存檔,就會自動 Build,並且在 Test Explorer 看到紅燈綠燈了
最近因為 TDD 的關係,這樣子的開發環境真的太鳥了,所以認真研究了一下解決方案,發現了 Google Test Adapter 這個好東西:
https://github.com/csoltenborn/GoogleTestAdapter
很簡單,照著 github 上的說明安裝完後就可以使用。幾個要注意調整的地方:
- 原本它會搜尋結尾為 test / tests 的執行檔來分析裡面的 test case,所以如果你的 Unit Test 程式不是 xxxTest.exe 的話,請記得到 [TOOLS] –> [Option] –> [Google Test Adapter] –> [General] ,裡面有一個 Regex for test discovery,我是使用 UT_[\w]*.exe
- 在同一頁中還有一個 Working directory & PATH extension,如果你的執行環境不是在預設的 output directory,也請記得修改。
- 修改 Unit Test Project 會自動跑 test case,但修改原本的 project 並不會被偵測到
- 希望可以每次存檔後,就自動 Build & Test ,這樣只要專注綠燈/紅燈就好了。
public class E : VisualCommanderExt.IExtension
{
public void SetSite(EnvDTE80.DTE2 DTE_, Microsoft.VisualStudio.Shell.Package package)
{
DTE = DTE_;
events = DTE.Events;
documentEvents = events.DocumentEvents;
documentEvents.DocumentSaved += OnDocumentSaved;
}
public void Close()
{
documentEvents.DocumentSaved -= OnDocumentSaved;
}
private void OnDocumentSaved(EnvDTE.Document doc)
{
if(doc.Language == "C/C++")
{
DTE.ExecuteCommand("Build.BuildSolution");
DTE.ExecuteCommand("Test.RunAllTestsInSolution");
}
}
private EnvDTE80.DTE2 DTE;
private EnvDTE.Events events;
private EnvDTE.DocumentEvents documentEvents;
}
完工,現在只要存檔,就會自動 Build,並且在 Test Explorer 看到紅燈綠燈了
Google Test Adapter
起因
Diro 分享了一個影片
以下簡單記錄我看完的心得
內容簡介
Speaker 是 Brian Lonsdorf (CTO of Loop/Recur, 多麼 geek 的公司名 XD)
LinkedIn: https://www.linkedin.com/in/drboolean
GitHub: https://github.com/DrBoolean
整個影片的重點在說明 Underscore 這個 library 雖然宣稱提供了一些有用的 functional programming helpers, 但是它的介面設計讓使用的人很難寫出真的 functional language 特性的 codes
Currying
以下他用幾個例子來說明 Underscore 的問題要看以下他舉的例子前, 先說明一個東西 - Currying
假設你有一個 function 叫 add
var add = function(x, y) {
return x + y;
}
假設你希望可以這樣寫var add2 = add(2); // return: function()
add2(10); // return: 12
add2(5); // return: 7
那你就要修改一下你的 add 定義var add = function(x) {
return function(y) {
return x + y;
}
}
var add2 = add(2); // return: function(y) {...}
add2(10); // return: 12
add2(5); // return 7
有更 generic 的作法, 請參考 http://blog.rx836.tw/blog/javascript-currying/作者也有提到一個幫你把你的 function 轉成 curried function 的 library (wu.js)
所以假設這樣寫會把你的 function 轉成 curried function\
var add = function(x, y) {
return x + y;
}.autoCurry();
舉幾個實際點的例子 (畢竟 add 有點沒感覺)var modulo = function(divisor, dividend) {
return dividend % divisor;
}.autoCurry();
modulo(3, 9); // return: 0
var isOdd = module(2);
isOdd(6); // return: 0
isOdd(7); // return: 1
var filter = function(f, xs) {
return xs.filter(f);
}.autoCurry();
filter(isOdd, [1, 2, 3, 4, 5]); // return: [1, 3, 5]
var getTheOdds = filter(isOdd);
getTheOdds([1, 2, 3, 4, 5]); // return: [1, 3, 5]
講者提的範例
- 範例一
var firstTwoLetters = function(words) {
return _.map(words, function(word) {
return _.first(word, 2);
});
};
firstTwoLetters(['jim', 'kate']); // return: ['ji', 'ka']
因為 Underscore 的參數順序是先 array 再 function所以沒辦法寫得更好
他認為如果 Underscore 能把參數順序顛倒且 API 是 curried functions
就可以寫成這樣
// _.first(n, array) 參數顛倒
var firstTwoLetters = function(words) {
return _.map(words, _.first(2));
};
// 更進一步, _.map(f, array) 參數顛倒
var firstTwo = _.map(_.first(2));
filterTwo(['jim', 'kate']);
- 範例二
var sortedPhones = function(users) {
return _.chain(users)
.sortBy(function(user) { return user.signup_date; })
.map(function(user) { return user.phone; })
.value();
};
sortedPhones(users);
他將其改寫為var sortedPhones = _.compose(
_.map(function(user){ return user.phone; }),
_.sortBy(function(useR){ return user.signup_date}));
sortedPhones(users);
更進一步var dot = function(prop, obj) {
return obj[prop];
}.autoCurry();
var sortedPhones = _.compose(_.map(dot('phone')),
_.sortBy(dot('signup_date')));
sortedPhones(users);
結論
我個人認為, 看完這個影片比看 Functional Javascript 這本書還更能感受 functional language 的特性 XD不過我也還不是很懂, 大家就一起學習吧
Hey Underscore, You're Doing It Wrong! 觀後感
https://blog.qt.io/blog/2013/04/15/evolution-of-the-qml-engine-part-1/
這一系列 QML engine 的文章(其實目前也只有一篇....)深入探討了 QML engine 的內部運作機制。Lars Knoll 指出了目前 QML engine 比較大的問題包括:
- Several object models
- 也就是一個 QML item 必需有3個object models,分別存在於 V8 engine, QML engine, Native Qt (以QObject 形式存在),不但耗費很多記憶體,要 sync 三個物件的值也是一大工程
- Bindings done through JS closures
- 每個 property binding 都是一個 JS closure,因此要先重新把 binding expression 重組成 JS closure,然後 V8 再 parsing 一次這個 closure。很慢,因此提出了一個輕量、快速的 V4 engine 來幫忙處理簡單的 expression(這也是為什麼官方的 performance tuning 文件叫你要盡量簡單化 binding expression)。
- Data type conversions
- Qt 跟 V8 之間的 data type 轉換很花時間,此外如果是 string 的話,memory copy 的成本也不低。當然,有些改善方法,但那就是拿記憶體或程式複雜度換來的了
- QML scoping rules
- QML element 實際上是樹狀結構,跟傳統的 JS engine 其實不大一樣,QML engine 用了很複雜的方法來處理這段(through nesting slow and deprecated with() statements)。
- Throwing away QML type info
- type info 會被丟棄..
- iOS and WinRT support
- V8要求系統記憶體可以被設定成 executable,但這在iOS及WinRT是做不到的...所以只能另外做一套 JS engine 了..
- Working with upstream V8
- Qt 裡面的 V8 跟標準版的 V8 程式碼已經差很多了..而且好像很難 merge 了...
Qt/QML Performance Tuning #1
VIVOTEK Digest
這裡是 VIVOTEK 晶睿通訊 的技術部落格,我們在這裡分享與敏捷、Qt/QML及其它軟體相關技術
Trending
-
「不要試圖覆蓋所有使用案例。Spec.不是用來替代組合回歸測試的。」 - Spec by Example 中文版 p.151 但我們明明覺得現在用 Robot Framework 實現自動化 UAT 來替代組合回歸測試是很正確的做法,為什麼作者覺得這樣不對? 我認為...
-
平常 C++ 的開發工具是 Microsoft Visual Studio,然後現在的測試框架是使用 Google Test,以前都是一邊寫,一邊手動執行 test case 來驗證,沒有辦法跟 VS 內建的 Test Explorer 做整合,真的蠻原始的 =.= 最近因為...
-
針對常用的match role, 可利用QHash (or QMap) 多存一份, 來加快 search 效率 我們在設計model通常都會定義一個存unique string value的IdRole當作model item的索引, 且會很頻繁對這個role作ma...
Categories
Programming
19
Culture
11
Testing
6
scrum
6
Agile
5
performance tuning
4
Book
3
Code Quality
2
Qt
2
Event Storming
1
database
1
file system
1
virtual machine
1





