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是什麼，避免專案走到後期，才發現彼此有很大的誤解。

可視化流程

除了共通語言以外，事件風暴還提供了一個全面的可視化流程，我們同步大家的共同語言後，把四組合併成兩個組進行事件風暴，我們故意讓大家先用傳統方法從Entities開始發想，再補充上use cases，讓大家先跑一次流程。

事件風暴跟從核心出發不一樣，而是從領域事件開始展開(我們認為有點像是從use cases展開)，兩組分別列出我們在乎的領域事件，看到大家不斷的貼上、移動、調整，對整個流程重新順一次，我想這就是事件風暴要的效果，最後產生一個看得到的用戶故事(User stories)。

我感覺event storming有點類似非coding版本的mob programing，用一種方法把群體的思維聚焦在同一個問題上，並且利用交流讓整體意識調整到相同頻率取得共識，共識後的產物是經過大家認可的業務邏輯與範圍，所以真正執行或實作的時候大家是朝同一個目標努力的。

Clean Architecture 課後心得分享

The Year of Being Agile (Part 1)

The Year of Being Agile (Part 2)

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! 觀後感

Qt/QML Performance Tuning #1

敏捷當中的透明性帶來什麼好處？

應不應該用 UAT 做回歸測試?

在做自動化 UAT 時，最常做的事便是拿 HANDLE，這在以前傳統的 GUI Framework 只要用 Spy++ 或其它開發工具都很容易做到。
但現在 QML 不一樣了，QML 裡頭已經沒有所謂的 window handle，比較接近的是 objectName，你可以用 objectName 來對該元件進行操作（get property, call method…)，問題是要怎麼樣拿到 objectName 呢？最直覺的作法就是直接看 QML source code，有錢一點的可能是用 Squish 之類的工具去做。但是直接看 QML source code 其實是比較花時間的，而 Squish 則是價格比較高，因此我實作了一個 JavaScript Library 可以讓你在 UI 上顯示每個 QML component 的 objectName。
例如你的 GUI Application 原本看起來是這樣：

在呼叫了 LabelQML.addObjectNameFlag(this); 之後，它便會在所有有 objectName 的元件上顯示一個小紅點：

當你滑鼠移至小紅點上方時，便會在畫面中央顯示它的 objectName：
完整程式碼及範例：
https://github.com/diro/LabelQMLComponent
其實作法很簡單，基本上就是 recursive 去列舉所有的 component，並檢查是否有 objectName，若有則建立一個 dynamic QML component（小紅點），當滑鼠移至小紅點時，便會在預先建立的 displayBoard 元件中顯示 objectName。

How to get and display QML objectName in application

How to Integrate Robot Framework with TestRail

http://www.taaze.tw/sing.html?pid=11100 723738
本書獲得《Dr. Dobb’s Journal》肯定，榮獲第21屆Jolt獎。
打造優良的軟體開發團隊，除了要大家有敏捷的觀念外，基礎建設也是非常重要的。前一陣子唸完了 Continuous Delivery 之後，便開始計畫要把不足的部份補完（如果不知道 Continuous Delivery 有什麼好處，可以先上網查查，或著看看書 XD），在幾位同學的努力之下，花了一個多月把缺的部份補上，包含架設CI Server、夠好用的build script、Robot Framework for QML、Unit Test integration。

我們選定的 CI 是用 TeamCity，其實 Jenkins 也不錯，但是比較起來商業化的軟體在易用性及介面上，還是略勝一籌，加上之前也都是在用 TeamCity，我覺得用 TeamCity 可以更快上手。

Unit Test

Unit Test 使用 Google Test，為何捨棄原本的 Boost Testing Framework?一個原因是它在 mock/stub 這一部份還不及 Google Test 完整，因此我們選用了 Google Test。

UAT (User-Accaptance-Testing)

UAT 的部份則是使用 Robot Framework，沒有特別原因，只是因為有其它同事正在用，就一起用吧 XD

Qt/QML Testing Framework，

GUI Application 的測試，有一點很重要的是要以 HANDLE、object ID 來操作，而避免使用”圖形”的方式來操作，因為你的 GUI 有非常大的機率會調整，只要一改，你的 test case 就要全部重來了。但是 QML Application 裡頭是沒有所謂的 window handle 的，跟傳統的 Windows Application 不大一樣，而目前市面上只有 Squish 有辦法去對 QML Application 做到使用 object ID 來操作。（Ubuntu 的 testing tool 似乎也有，但沒有深入研究）
但我們並沒有使用 Squish，而是讓我們的程式原本就具備這樣的”可測性”，也就是說我們自己做了一個 python library，可以讓開發人員透過這個 python library 來操作我們的 QML Application。而 Robot Framework 就是透過這個 python library 來完成 keyword-driven testing。不知道什麼是 keyword-driven testing 的話，可以參考 http://kb.froglogic.com/display/KB/Article+-+Keyword-driven+testing+with+Squish+and+Robot+Framework

就這樣，透過上面四個元件的合作，我們完成了 Continuous Delivery 的目標。這個系統會自動完成下面的工作：

有團隊成員 commit code 之後，開始進行 build，然後執行全部的 unit test
通過 unit test 之後，自動打包成準備釋出的 installer.exe
接下來自動依序發佈到不同平台的 VM 上去進行測試。
系統呼叫 sikuli，自動在各個 VM 裡頭執行 installer.exe，並完成軟體的安裝。
安裝完畢，會呼叫 Robot Framework 開始進行 UAT (User-Acceptance-Testing)。
完畢，產生報告。

有了 Continuous Delivery，現在 RD/UX/PO 都隨時可以下載最新版的”已測試過"軟體來使用，再也不用等人手動去 build 出來了。

更多技術細節，就等其它人分享了 :)

Continuous Delivery

很多書都在強調 code review 的重要性。在我們的軟體部門剛開始成立，並沒有 code review。這個狀況持續了幾年，一直到前年，我才開始認真思考，不做 code review 真的對嗎? 於是我們從那個時候開始逐步推動 code review。

在沒有 code review 的時代，有兩件事情讓我印象深刻。第一件事情已經七、八年了，有一個週末，我們因為程式在下一週初要 release，想當然爾，工作是做不完地。所以我決定週末來加班。那時候我自詡應該當規劃者，所以平常是不寫程式碼地。可是真的來不及了，所以我得跳下來自己幹。沒想到那個週末，當我打開 project 的程式碼一看，我快嚇傻了。一個函式長達一千多行，眼睛東瞄西瞄看到的是許許多多重複的程式碼。這個該怎麼改呢? 到最後就是能頭痛醫頭腳痛醫腳，可想而知，那一個週末沒有什麼好下場了。第二件事發生在三年前左右，我們一個產品內的某一個 service，在屢次的進測，總是領到最多的紅牌。最後在產品被追殺的階段，我們發現那一個 service 無法收斂了。這時候我們開始投人進去那一個 service 進行 code review。不看不會怕，看了之後才知道多可怕。那一個 service 竟然高達一萬四千多行。可怕的是，這一萬四千多行在同一個檔案。是地! 一個 service 就一個檔案。最厲害的地方是，這個 service 破了之前的一千多行記錄，有一個函式高達三千多行。最後那一個 service 只能靠硬測的方式讓他自然地收斂。然後在後面安排 refactor。Refactor 後剩下八九千行，當然也拆了不少的檔案。可以看出來原來的作品中重複的程式碼有多嚴重。我們稱這種大函式叫："吾碼一以貫之"，這種一個函式殺到底的寫作方式，對於寫的人來說當然過癮，不用想太多次該怎麼擺變數，想一次就可以用 "很久"。但是對於看的人來說，實在是痛苦至極，看到第三頁的時候，已經不記得這個變數什麼時後宣告、什麼時候改值。諷刺的是一個函式不能太長這件事，在公司的 coding rule 當中是有提到地，為什麼還會看到這樣的事情出現？問題就在於事情沒有人去看，就容易歪掉。

這種事情就是這樣，開始總是最難地。前年開始推 code review 的時候，第一個遇到的難題就是人力的問題。這其實是一個弔詭的問題，本來寫 code 寫得很用力的團隊，突然要 "插" 一件 "本該做的事"，卻變成當時團隊多出來的事情。於是我只能動用手上所有的資源幫忙 review。然後因為遇到大家的時間不容易湊在一起，所以也請成員架上 Reviewboard 來協助分散式 code review。然後先是一個團隊持續地看到 review 活動，然後是另一個團隊的重要修改也開始 review。最讓人驚艷的是去今年初，已經有一個團隊將 Pre-commit review 自動化架好了 (用 Git + Gerrit + Jenkins)。只要 commit code，系統會自動驗證可否 build，然後會寄出 review request 給設定好的人。所以現在信箱一天會收到將近十封的 review request (說實在，加上 build 成功的訊息，一天信箱會被灌入 3, 40 封信，很快就會爆了 XD)。這樣的自動化，最有趣的地方在於讓你的 code 沒有被 review 過就不能夠 commit。因此現在對那個團隊而言，已經不是 optional, 而是 must。所以 review 活動就會被持續執行。而現在也會發現，因為 code review 的工作被拉出來，組長的工作裡頭自然會加入此項 task，所以比較不會像剛開始一樣覺得根本排不進去。

那麼到底這樣強推 review 有沒有什麼效果呢? 說句老實話，如果你期待 code review 可以大量減少 bug 數量，是比較不切實際地。但是他對於防範 non-trivial 的 bug，尤其是架構性問題、易維護問題、後續加新功能的 side effect 的防範，是有比較大的效果。另一個重點是，因為強制 code review，你可以在無形中強迫 member 去看到其他人被要求了哪些東西，下次他自己寫的時候就不容易重複同樣的錯誤。另外，自己寫的東西有人在看的時候就會比較小心一點，這些都是無形的效果。

現在開始有團隊在導入 scrum 了，在該團隊中更增加了 peer 的 code review。不再單純是上對下的 review。我覺得這樣做又有更進一步的效果，那就是懂 code 的人更多了，對於未來 task 的相互支援，也會變得比較有可能性了。這是我們在 code review 開始前享受不到地。

所以 code review 重要嗎? 非常重要。你們開始做了嗎?

Code review 真的重要嗎?

Unit test (單元測試) 在我剛開始加入團隊的時候，有寫過一陣子。那時候使用的是內部人員自己開發的 framework。當時寫 unit test 的方法可以說相當原始，我們沒有特別去研究 unit test 可以怎麼作，stub 或 mock 更是沒有研究過的議題。大家就只是很努力地在每個模組完成後，補完大部分可能的 test cases。但是久而久之，隨著專案越來越大，架構越來越複雜後，寫 unit test 變成一個令人沮喪的活動，至少當時對我而言是這樣。原因是甚麼？

多年後，我在團隊中又剛好擔任到導入 unit test 的第一線角色。現在因為開發經驗比較豐富，對於測試應該怎麼寫，或是寫 unit test 的人應該專注於哪一部分有了一點點的感覺。在我還是個懵懵懂懂的 RD 時，覺得每次寫一個新模組的 unit test，前置大概要花好幾個小時，在寫一些該模組與其他元件「假」互動的部分，例如與資料庫溝通的模組，透過網路傳送訊息的類別，跟串流伺服器傳輸影音的函式庫。因此，寫久了會問自己，到底是在寫單元測試還是在寫假類別的程式。

[圖片來源: www.wowwiki.com]

在這一次的 unit test 導入計畫中，我們選用了 Google C++ Testing Framework，這部分其實跟之前試用過的 boost 中的 unit test framework 大同小異。同時我們也使用了 Google C++ Mocking Framework，我花了一天的時間閱讀了相關基礎文件後，頓時有種為什麼以前要花時間寫那些「假」互動。原來以前花很多時間在做的事情，使用 framework 只要幾分鐘的時間就完成了，也因此寫 unit test 的人可以真正的思考測試的流程或是設計測試的不同案例。我為了讓實際開發者能專注於如何寫 test cases，也寫了一些包裝過的 utility，期望讓大家寫 unit test 時不要有沮喪的感覺。

從目前的狀況看來，我們只是「有」了 unit test，但是我們還沒有思考覆蓋率，或是維護的問題，持續改善這一部分將是我們要繼續努力的地方。好消息是，我們的 CI 已經整合了 unit test 的部分，這多多少少也會鼓勵大家寫 unit test。只有當 RD 覺得 unit test 很好用時，他們才會願意花時間且認真的撰寫 unit test。我本人也不例外 XD

Unit test 的美麗與哀愁

QML - Introduction of QML Multi-Media

QtLeapMotionLibrary

Qt 原本就已經提供了 QTest 可以用來開發單元測試，但整體感覺還是沒有 google test 完整，因此實務上我們還是使用 google test 來進行單元測試。

Google test 搭配 Qt 一般來說有二點要處理：
1. Qt Signal
2. Event Loop

Qt Signal

因為你的 slots 沒辦法用 MOCK_METHOD 製造出來，或著說QObject::connect 無法連結到 MOCK_METHOD 做出來的偽slot ([苦主](https://groups.google.com/forum/#!topic/googlemock/RTgynKPa6ew))
因此，最好的方式仍舊是搭配 QTestLib 裡頭的 QSignalSpy 使用([前輩已經說過了](http://stackoverflow.com/questions/22390208/google-test-mock-with-qt-signals))。
QSignalSpy 可以幫助你檢查某個 signal 被 emitted 的次數，以及它每次 emit 所帶回的參數是什麼，算是蠻方便的：

QCheckBox *box = new QCheckBox(0);
QSignalSpy spy(box, SIGNAL(clicked(bool)));
box->animateClick();
EXPECT_EQ(1, spy.count())
QList<QVariant> arguments = spy.takeFirst();
EXPECT_TRUE(arguments.at(0).toBool());

不過，在用QSignalSpy的時侯要想一下，你有 event loop 嗎?不是每個unit test都像範例這麼單純的，如果你串起來不會動，就想想 event loop 吧 :)

Event Loop
因為許多功能都必需有 Qt 的 event loop 才能運作，因此勢必要呼叫 QCoreApplication::exec() 才能跑。那麼這個原本都是放在main()裡頭的 QCoreApplication::exec() 現在要放在那裡呢?當然就是放在每個 test case 之中了。

這邊的範例是我會呼叫 trackEvent() 功能，並等待 signal TrackEventFinished 回來時再離開 event loop：

TEST_F(PluginMixPanelFixture, Send_1_Event_With_Extra_Properties)
{
**int argc = 0;
QCoreApplication app(argc, NULL);**
auto conn = std::make_shared<QMetaObject::Connection>();
*conn = QObject::connect(pTestingPlugin, &PluginMixPanelClient::TrackEventFinished, [ = ]()
{
QCoreApplication::quit();
});

QString event = "[test] login function with extra properties";
static QVariantMap property;
property.insert("prop_size", 1000);
property.insert("prop_alias", "diro");
pTestingPlugin->TrackEvent(event, property);
**app.exec();**
QObject::disconnect(*conn);
}

第一個常見現象：開週會Why are meetings so ineffective?

第二個常見現象：同事間的工作互換困難Why is collective work difficult?

第三個常見現象: 加班

Why work overtime?

敏捷開發Why OverCooked can teach you agile?

Get back in sync

Realtime review

How to avoid boring meetings?

How to develop a cohesive team?

Why collective intelligence matters?

Iteration based method

敏捷帶來的影響How does agile affect my work and daily life?

起因

內容簡介

Currying

講者提的範例

結論

VIVOTEK Digest

Trending

Categories

聯絡我們

徵才

第一個常見現象：開週會
Why are meetings so ineffective?

第二個常見現象：同事間的工作互換困難
Why is collective work difficult?

敏捷開發
Why OverCooked can teach you agile?

敏捷帶來的影響
How does agile affect my work and daily life?