http://www.taaze.tw/sing.html?pid=11100723738
本書獲得《Dr. Dobb’s Journal》肯定，榮獲第21屆Jolt獎。
打造優良的軟體開發團隊，除了要大家有敏捷的觀念外，基礎建設也是非常重要的。前一陣子唸完了 Continuous Delivery 之後， 便開始計畫要把不足的部份補完（如果不知道 Continuous Delivery 有什麼好處，可以先上網查查，或著看看書 XD），在幾位同學的努力之下，花了一個多月把缺的部份補上，包含架設CI Server、夠好用的build script、Robot Framework for QML、Unit Test integration。
- CI
- 我們選定的 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 出來了。
更多技術細節，就等其它人分享了 :)
家裡附近有幾家早餐店，其中一家大部份只有老闆娘一個人獨撐大局，另外二家則是有好幾個員工。每家早餐店的客人數量感覺都差不多，不過員工多的反而常常出餐慢、上錯餐點，而一人早餐店卻可以做的非常有條理，速度也不錯。根據我長久以來的觀察，我發現了其中的奧秘...
一人早餐店：老闆娘具備了明星早餐店員工該有的特質：
- 記憶力超強、超級會認人：她可以一邊接電話收預訂早餐的訂單，一邊聽在現場的客人跟她點餐，而且不會搞混。當你點過一次鐵板麵加半熟蛋後，以後你再來點鐵板麵加蛋時，她就會直接跟你確認：「蛋半熟厚？」，點過漢堡不加生洋蔥，以後她就會直接跟你確認：「洋蔥不要厚」。
- 手腳快：是的，他一個人可以顧好四台烤箱、一排烤麵包機、正在煮的義大利麵跟那檯永不停息的鐵板爐，而且每當有一些新訂單進來時，他總能瞬間將生產排程最佳化
- 心算快：要結帳時，他瞄一眼你的桌子，就知道你總共吃了那些，總共多少錢～
人海早餐店：這裡的員工通常不具備明星架勢
- 記憶力普普：你講過一次的東西他可能在覆誦時就漏了，還有打電話來訂結果做錯餐的，當然，這裡的員工也不大會記得你愛吃什麼，什麼要加什麼不加，蛋是全熟還半熟，所以你每次都必需交待一遍（不過更慘的是，現在交待的也不見的記得清楚就是了..）
- 手腳快不起來：每個人速度還好，但是做一個漢堡要三個人做－＞A對甲說：幫我烤一份漢堡，再對乙說：幫我煎一個豬排，最後再由A統一加工，每當A說：再幫我烤一份漢堡時，甲就開始想到底是剛才要烤的那份還是要再加一份，然後就需要進行「溝通」，每當有新的訂單進來時，也無法將生產排程最佳化，因為每個人都只能看到 local 的東西，沒有辦法綜觀全局。甲還不時要同步一下，問說：「所以現在總共烤二個嗎？」
- 心算普普：當你結帳時，櫃台那位還很有可能要轉頭問另一位店員說：「他的多少錢？」，天啊，這樣不是很像冗員嗎.........而且被問的那位還要看看單子慢慢算，真的是很慢啊 =.="
當踏出人海早餐店，看著店門口寫著的：「徵工作夥伴」，我心都涼了.......下次應該帶幾本軟體專案管理的書給老闆看看，不然以我後早餐的選擇可能會變很少了。
不過我的心得是，軟體開發跟開早餐店有許多相同之處，軟體開發應該要找明星級人才來，而不是找一堆普通的人才，明星級人才可以一個人獨立完成相當規模的程式（C++ 5,000~100,00行），他不需要花時間在與其它人溝通，但如果你雇了三個普通的人才，他們花在溝通協調的時間（甲：喂，我這個不是thread-safe哦！乙：為什麼呼叫進去會block住這麼久？丙：你的介面很難用耶），可能明星級人才都已經把事情做完了（一個人做，他很清楚怎麼設計最好，別人還在 Multi-Thread 打滾時，他已經想出了一個高效的 Single-Thread 解法）。
你還認為三個臭皮匠勝過一個諸葛亮嗎，我不認為，因為扣除溝通這一點外，還有一句人月神話裡的名言：「在接受相同的訓練、同樣都是兩年資歷的情況下，優秀專業程式設計師的生產力要比差勁的程式設計師好上十倍」。如果要打造一個大型的軟體，你需要的會是幾個諸葛亮，而不是一堆臭皮匠。
後記：
今天早上又去了人海早餐店，點完餐，報紙翻沒幾頁時，店員竟然已經拎著我的早餐給我，對我說：「先生，你的餐好了，一共NT$135」，我眼淚都快流出來了，你們真的進步了，出餐的速度變快了。回到家，我真的流下淚來，我點了蘿蔔糕、漢堡、鐵板麵加一杯豆漿及薏仁漿，但是袋子裡面只有漢堡、鐵板麵跟薏仁漿，也就是有40%的餐點是沒有給我的（不過錢倒是100%都有算到）..............我無言了。只能說加油了....
Dreaming in Code,不知道大家是否還記得 Mitch Kapor? Lotus 的創辦人,也就是當年紅極一時的Lotus 1-2-3的作者之一。當年Mitch Kapor與Bill Gates可以說是軟體業界的兩大名人,後來因為一些因素,Mitch Kapor離開了Lotus。隔了一段時間之後,他帶了一堆駭客級的程式設計師(如Netscape Navigator的作者， MAC kernel的作者．．．),準備打造一套PIM軟體 - Chandler，耗時三年，卻始終無法正式推出．．Why?請見
Dreaming in Code
