People over Process (1)

April 28 22:28~23:52

幾天前指導教授拿了一篇 IEEE Software 上面熱騰騰剛出爐的 paper 給 Teddy 看：

People over Process: Key Challenges in Agile Development, July/August, 2011, IEEE Software, pp. 48-57.

自從畢業之後很少有時間去看 IEEE Software 上面的 papers，以前還在念書的時候，每期的 IEEE Software 上面文章 Teddy 都會快速翻過一次，看看有沒有值得看而且看得懂的文章。工作之後『國事如麻』，專案嗷嗷待哺，鮮少有時間定期去找看看有沒有值得讀的 papers。還好有善心人士介紹，這次才有機緣讀到好 paper。這篇 paper 是作者訪問了 17 個採用 agile methods 的組織，整理出這些組織在實施 agile methods 時遇到關於『人』的挑戰。這幾個受訪單位，採用的 agile methods 包含了 ：

• XP + Scrum：10 家
• Lean：2 家
• Crystal：1 家
• XP：2 家
• Scrum：2 家

由此看來 XP, Scrum 佔了大多數，給鄉民們參考一下。

接下來分幾天介紹一下 paper 中所提到的 『People challenges』，每一點 Teddy 都十分贊同。

Developer fear of skill-deficiency exposure 

第一個挑戰是『開發人員擔心自己能力不足之處被暴露出來』。Agile 團隊強調溝通與互相合作，一切講求透明化。套句古人所說的話：『知之為知之，不知為不知，是知也』。說來容易，做起來卻不簡單。試想一下，假設你到這間公司工作已經三年多了，某日你被要求與某個新進同事進行 pair programming，而且由你主筆。此時你可能心裡會想，糟了，讓同事知道我變數名稱取得很爛，我不太會寫 unit tests，或是我根本不會用 Eclipse 上面的 refactoring 功能....等等等。這種感覺，就好像是明天要期末考了，而你卻都還沒唸書。哇，agile 好可怕啊。

或是在每天 daily Scrum meeting 的時候，有一個實做 DAO（Data Access Object）的 task 你做了兩天還沒做完，此時你內心又會想，糟了，別人做類似的功能只花了五個小時，但是我寫了兩天居然還沒寫完，這樣別人不是發現我對於 database 不熟這件事了嗎！這豈不是又要動搖國本啊...XD。

又或者在跟團隊成員討論設計的時候，耶，怎麼別人開口就是『這邊可以套用 Observer pattern』，『把這個物件作成一個 Singleton』，不然就是『這裡要傳入一個 Collecting Parameter』，『這段程式要放在一個 blanket catch 裡面』。剛剛『花生』什麼事情，你們講的是中文嗎，我怎麼都聽不懂？

***

在傳統的軟體開發中，大家各作各的，雖然是同一個 team，但是在某些團隊中，其團隊成員的互動幾乎可以用『老死不相往來』來形容。既然別人不知到我在幹麼，這樣我的弱點就不會被發現。反正我每天也是都跟大家一樣加班到很晚啊，事情做不完我也沒辦法（Teddy 內心獨白：這個現象好像可以用濫竽充數來形容）。Developers 雖然付出加班的代價，但是獲得『保有自己能力不足不被發現』的安全感。受傷的是誰？一開始是專案進度，接著是公司，最後傷到自己。

所以要不要採用 agile methods？當然是寧死不從啊。為什麼？這樣我的缺點不是被大家看光光了，這和沒穿衣服上街有何不同，堅決反對啦。我們要爭取 司法人權 coding 人權。

解法呢？Paper 建議 provide an environment where developers feel safe to expose their weaknesses。Teddy 知道鄉民們在想什麼，這句不是廢話，的確是廢話。不過 paper 厲害的地方就是可以講得讓鄉民們覺的這是一句『值得購買的廢話』：

• 在受訪的 company C 中，開發人員每兩週將內心覺的不方便公開討論的議題寫在小紙上。但是關於這張小紙條要傳給誰 paper 居然沒交代...XD。
• 在 company D 中，資淺的開發人員可以自行決定是否在 stand-up meetings 中說出自以遇到的問題。
• 在 company B, D, M 中，資淺的開發人員另外還有一個特別為他們準備且時間較常的 stand-up meetings。在這個加長版的 stand-up meetings 中，有專門的 mentors 提供特別服務。
• 至少有九間受訪公司在實施 pair programming 時，採用『能力較弱開發人員』搭配『有經驗開發人員』的方式來提昇能力較弱開發人員的能力。

***

以上幾項，Teddy 只實施過 pair programming 這一項，非常有用。另外對於新人 Teddy 也會親自施予若干小時的『特訓』。還有一點，找人的時候如果能找到接受 agile 精神的人，那就可以省了許多功夫。剛好這一陣子新進的幾位新人都學過 Scrum，所以 Teddy 算是用到賺到，幾乎立即可上手。

***

友藏內心獨白：絕大部分的問題，幾乎都是人的問題。

還少一本書：零與無限大

April 26 22:02~23:20

Teddy 還真是個烏鴉嘴，幾天前在『一步到位還是一槍斃命？ 』才提到大陸高鐵，沒想到馬上發生了後車撞前車的『特大』意外事故。不過有一事 Teddy 不明，電視新聞報導時一直用『動車』這個名詞，這個詞翻成台灣的習慣用語，倒底是『火車』，『電車』，還是『高鐵』呢？

***

幾天前在 Facebook 上面的『Scrum Community in Taiwan』 社群中，有人問到「什麼時候不適合施行 Sc​rum 或 Agile」，Teddy 給了一個很簡單的答案：

關於『什麼時候不適合施行 Scrum 或 Agile』答​案其實很簡單：『看看自己的老闆，公司文化，團隊現況』​答案就出來了。我想台灣 99% 以上都屬於『不適合施行 Scrum or Agile 的公司』。以下是 Teddy 的想法：如果今天有人跑去天安門廣場大喊『XX黨』下台​，或是去利比亞首都大喊『XX費』下台，下場如何可想而​知。公司老闆不支持，team members 也不想了解，這都是常見的現象。除非想要導入的『那個人​』跟老闆很熟（老闆的兒子？）或是想當烈士，否則還是不​要導入為佳。

說實話，以台灣一般公司的文化與主事者的心態，說要去導入 Scrum 是極為困難的一件事。Teddy 曾經聽過一個故事，某公司的高高層對一位新進員工（高階主管）說：

不要把你在以前公司所做的那一套帶到我們公司來，我們公司有自己的文化與做事的方法，你自己要想辦法融入，不要試圖去改變。

Teddy 相信很多公司都是抱持著這種『排斥改變』的心態：好的，我了解了，你所建議的這個方法看起來似乎不錯，but I don't care。謝謝不聯絡。

***

這幾天 Teddy 在讀許文龍的『零與無限大』這本書，書中描述了許文龍先生經營事業的作法，其中有很多作法都與一般熟知的經營方式不同。也就是因為許文龍先生有著打破既有框架的勇氣，所以獲得了成功。舉幾個例子：

• 一般的公司與它的原料供應商之間，存在的都是利益衝突的對立關係。公司的採購想辦法殺價同時拼命的拿回扣，而原料供應商則不停的派 辣妹 業務來推銷產品。許文龍則是一次直接跟原料供應商簽訂 10 年的合約，至於價格則是由雙方來談（細節請參考 pp. 38-39）。總之就是想辦法將與供應商共享利益，把原本的對立關係轉變成非對立。
• 在公司創造一個『找答案，不找責任』的環境（p. 63）。Teddy 相信台灣絕大部分的公司，都是『找羔羊（代罪羔羊），不找答案』。
• 早在 1985 年，奇美公司就實施週休二日。為了彌補減少的工時，奇美投入千萬元更新自動化設備來因應（p. 68）。
• 經營，就是一種『適應環境的行為』...什麼事情都要到『現場』去講才準...在戰爭中，指揮官一定要到前線，才能看到地圖上看不到的東西（pp. 127-128）。
• 奇美可以說是一個『無文字的社會』...我們人一生的時間實在有限，用這些時間來做事，比較實在。人家問說，為什麼奇美一個人可以做那麼多事？我說：因為他們不用寫報告，可以一直做事（p. 132）。Teddy  內心獨白：好香好濃的 agile 味道...XD。
• 管理的事，真的是少做比較好。因為管理是成本很高的東西，為了管理，會使得整個工作效能都降低（p. 133）。
• 抽屜理論：政府要成功改造，必須先歸零（整理抽屜時，先把抽屜整個清空，再把需要的的東西挑進來）。現在的社會，並不是過去的延長。在科學跳要的時代，以過去的思考模式並不能解決目前的問題（p. 189）。

這本書有 399 頁，整本書的內容都十分精彩，有興趣的鄉民們可以去找一本來看。

***

許文龍是受日本教育長大的，他在書中說他曾經讀過一本日本人翻譯的『生態學』的書，受這本書的影響很大。因此他的很多思考模式，是從『整個生態』的角度來看，格局也就變得比較大。 Teddy 讀完本書之後，倒是看到很多 TPS（Toyota Production System），Lean 與 Agile 精神。天下的事，一事通，萬事通，也許這就是這個道理吧。

回到一開始的那個問題：『什麼時候不適合施行 Sc​rum 或 Agile』？Teddy 說，什麼時候都不適合，什麼時候也都適合。

***

友藏內心獨白：結尾那一句一定要搞的那麼玄嗎？

一步到位還是一槍斃命？

April 22 23:46~23:24

這幾年中國大陸的高鐵建設突飛猛進，從南到北蓋了有幾千公里的高鐵。從電視新聞的畫面看起來，感覺挺不錯的，平穩的車廂，高檔次的服務人員，以及還算合理的票價。但是，鄉親啊，電視是『聞不到味道滴』，此話怎說？

Teddy 的一位友人最近剛從大陸回台灣，友人從大陸南方搭高鐵到武漢，再從武漢搭到上海，也算是繞了大半圈的大陸。據友人表示，大陸高鐵雖好，但有一個最大的缺點：『煙味太重』。

Teddy 問：什麼，有人在高鐵上拜拜？ 大陸高鐵上可以抽煙啊？

友人說：不行，但是很多人跑到廁所抽煙。雖然車上一直廣播說不要在廁所抽煙，但是根本沒人理會。我搭的還是頭等車廂，如果是次一等的車廂，那味道可更多了。 在武漢的時候，還有人提著『鮮魚』上車，整個車廂搞得都是魚腥味。

Teddy 內心獨白：經常在早上搭 307  公車經過果菜市場的人，就能夠體會到整車都是『新鮮食材』味道的那種感覺了。

硬體可以幾內年建設完畢，人的習慣...終生難改。這一代是不可能了，看看下一代會不會長進一點。有辦法把人的水準搞到一步到位 Teddy 就佩服你。

***

今天看到一則新聞，說宏碁斥資近百億元台幣併購雲端公司 iGware（Teddy 內心獨白：這是什麼東東？），報導中說：

...評估雖然可讓宏碁在過去幾無著墨的雲端運算領域「一步到位」...

怎麼好像有種看到大陸高鐵的感覺...

***

友藏內心獨白：別鐵齒，誰說不會有人在『雲端上抽煙』。

多準備幾包吧

April 21 20:03~23:01

這個『包』，不是紅包，不是名牌包，更不是蒙古包，而是『軟體開發包』。

『軟體開發包』 是什麼包？話說 Teddy 自從開發了跨平台軟體之後，才發現原本開發跨平台（跨作業系統）的軟體已經是不簡單了，如果還和底層的硬體扯上關係，那就更是麻煩。例如，你的程式要讀電腦晶片組中的資料，而這個電腦上跑的可能是各種不同版本的 Windows 或是 Linux 作業系統，所以當程式開發完成之後，在這些不同的作業系統中測試你的程式是絕對需要的工作。有時候萬一發生問題，免不了可能需要在發生問題的環境中（例如，在 CentOS 6.0 x64 上程式有問題）安裝你的開發環境（例如 Eclipse）『就地觀察』發生問題的原因，如果能夠順便將 bugs 給『就地正法』那就更好了。

如果你的程式只要在某個型號的電腦上執行也就算了，萬一你的程式需要支援，例如說，30 款具有不同晶片組的電腦，那頭就大了。光是開發，測試與 debug 的『環境設定』工作就做不完了，怎麼辦？請老闆增加人手幫忙，想太多，不可能。加班，不但做不完而且品質與效率變得差，行不通。

***

之前 Teddy  讀了幾本 Lean 的書，其中提到 Toyota 之所以會成功的原因之一，是因為它的組裝線具備有『少量多樣』的組裝能力，並且可以達到接單生產與零庫存的目標（傳統的汽車組裝線都是『單一（或是少樣）產品，大量生產』以達到經濟規模為目的）。要做到『少量多樣』其實是很不容易的，因為工廠需要因應不同的產品而調整組裝線（調整機台，改變使用的工具，校對儀器等等）。學過作業系統（OS）的人都知道，這種 context switch 是一種浪費，過於頻繁的 context switch 甚至會造成『CPU 花在 context switch 的時間大於執行工作的時間』這種現象。所以，Toyota 想盡辦法改善組裝線，並採用自動化的方式將『調整組裝線』的時間降到最低，克服了這個問題。

有一天 Teddy 就在想，每次測試軟體功能，都要先安裝作業系統（準備一個乾淨的環境），然後安裝待測軟體（一直按下一步，下一步），然後手動測試想要測試的功能。後來用 Robot Framework 寫了許多自動化的功能測試，但是在一個全新的環境中要執行這些 Robot test cases，還是每次都要先把相關的工具都裝好（例如裝 Robot 本身，還有 Python 等等），也是挺不方便且花時間。Teddy 在『落實的能力 』裡面有提可以寫一些簡單的 scripts 製作『自動化功能測試包』，以綠色軟體的方式隨時佈署到待測平台上面執行自動化功能測試。長久下來所節省的手動安裝測試工具的時間是很可觀的。

最近 Teddy 又在想，有時候需要把整個開發環境從平常使用的開發機上面複製一份到有問題的電腦中進行 debug（當然也可以用遠端更新的方式來 debug，但是有時候直接在出問題的電腦中 trace 問題會比較容易）。問題來了，遇到這種情況，要把『整個開發環境複製一份到有問題的電腦中』有時候還挺花時間的，而且很容易出錯，丟三落四的，什麼該 copy 的檔案忘了 copy，該設定的環境變數也沒改到。所以，如果除了『自動化功能測試包』以外，如果能夠有『自動化開發環境安裝包』，自動安裝（自動解壓縮並執行一個設定的 script）之後就可以立刻開發軟體，那就更方便了。

除了上面 Teddy 提到的這『兩包』，還有什麼『包』可以讓開發軟體變得比較『順』一點呢？

***

友藏內心獨白：『自動化分散式 CI 包』好像也挺不錯的。

下一個軟體也許會更好...嗎？

July 20 22:15~23:10

如果有一天你接到通知，告知你即將繼承某個遠房親戚的 1 千萬遺產，你會有怎樣的反應？這種天上掉下來的禮物，在欣然接受之前，要先調查一下，這筆『遺產』到底是正數，還是負數。萬一不小心繼承了之後，突然有個債主跑出來說這位遠房親戚欠了他 1 億元，現在要你這個繼承人還債，那可就衰呆了。

『遺產』這種東西，做軟體的人是最了解的，三不五時就需要與 legacy code 搏鬥。這些 legacy code 可能是別人贈送的，也可能是『昨日的你』送給『今日的你』的禮物，總之通常收到 legacy code 的人都不會太高興。這些 legacy code 怎麼看，怎麼不順眼，最好是能夠砍掉重練，才沒有包袱。

最近學弟們要開發一個新的系統，雖然可以在某個既有系統上繼續開發（擴充既有系統的功能），但是學弟選擇了『另起爐灶』，理由很多，但沒卻沒有一個理由可以說服 Teddy 的：

• 原有系統因為某些架構上的限制，導致資料分別存在檔案與資料庫中，無法集中。
• 原有系統的資料庫是使用另一個系統所設計的 schema（與另一個 AP 共用相同的 tables）。受限於這個 schema，有些功能不太容易實做。
• 原有系統所使用的 Javascript framework 檔案容量太大，約 700 多 K（Teddy 內心獨白：700 多 K 會算 size 太大？！）。

首先先來盤點一下這個既有系統的資產負債表，首先看一下資產：

• 已經有許多使用者在使用這個既有系統，而且反應不錯。
• 最近一年多來既有系統有持續改善使用者介面的操作（提高 usability）與修正了很多個 bug，目前穩定性算是不錯。
• 開發既有系統的時候有寫 unit tests （test coverage 有待調查）。
• 開發既有系統的時候有做持續整合。
• 開發既有系統的人雖然即將畢業，但是在離校之前有問題都還是可以立即詢問（就算離校之後也跑不了太遠...XD）。

至於負債部份大致上就是上面學弟所說的那三點。雖然有負債，但是要償還這些負債並非不可能的任務，也就是說資產減掉負債之後該既有系統的『淨值』還是正數，而且是正很多的正數（每股淨值大於 10 元...XD）。

***

學弟們目前還無法體會『軟體是長出來的 』之精神所在，Teddy 十分相信 Andy Hunt 與 Dave Thomas 所說的：『All programming is maintenance programming』，如果能把心態調整一下，轉換成思考『如何用軟體工程的方法來償還這些負債』，那麼這段還債的過程，對於軟體開發經驗的提昇將會有很大的幫助。

開發『真正給人用的軟體』是一種承諾，就好像養小狗，小貓一樣，總不能說小狗小時候很可愛，就很疼愛牠。等牠長大發現怎麼變得不可愛了，就讓牠去『流浪』。當年有首流行歌曲叫做『下一個男人也許會更好』，也許吧...但是如果連『這一個軟體都搞不太好』，那麼『下一個軟體會不會更好』就很難說了。

越來越有一種感慨，開發軟體的『心態』比技術與能力都還要來的重要。『心態正確』可以讓你做對事情，而技術與能力可以讓你把事情做對。如果兩者都具備，那就可以準備上華山論劍了。

***

友藏內心獨白：好好照顧既有系統也算是一種節能省碳的表現 。

滿天是金條

July 20 00:30~01:18

台語有一句俗話叫做『滿天是金條，賣殺（要抓）沒半條』，這句話在不同的場合有不同的解釋，其中一種解釋可以用來形容有些人說起話來頭頭是道，意見很多，但是實際上做起事來卻是沒有一樣做得出來（沒有任何一個意見是可行的...這句話用來形容『顧問』倒是挺貼切的）。例如，鄉民們的主管如果是那種『說得一口好程式』的人，就可以用這句話來形容該主管。

不過今天 Teddy 要講的是另外一件事。上上個禮拜六 Teddy 去天瓏買了兩本書，其中一本是 Software Build Systems 已經在幾天前介紹過了，另外一本是 Martin Fowler 寫得 Domain-Specific Languages （以下簡稱 MF DSL）。今天晚上（已經過了 12 點了，嚴格講起來應該說是昨天晚上）擠不出什麼料所以想說不要寫部落格來看一下這本書。話說當天買這本書時 Teddy 小小掙扎了一下，這本書已經出了一陣子了，照理講 Martin Fowler 的書只要一出版應該要立即買來收藏才對，但是基於三個原因這本書 Teddy 卻一直沒買：

• 之前看過一些 DSL 的資料，覺的對於開發軟體似乎沒有立即的需要。
• 學會 DSL 似乎要花不少的時間。
• 這本書有點厚。

那一天不知道那根經不對就把書買回家了，剛剛看了 30 幾頁的感想是：這本書還真是好看啊。副作用則是害 Teddy 睡不著....

看了 MF DSL 之後才 發現 證實（因為 Teddy 老早就懷疑了很久了，只是一直苦無證據...XD），其實 Teddy 在 N 年前開發的某個核心程式早就在『重度』使用 DSL 了，之前 Teddy 看的 DSL 的書太 formal 了，所以覺的離『立即可用』有一段距離。Martin Fowler 果然不是蓋的，所寫得每一本書都有那種 『bridge the gap』 的能力。

***

剛剛 Teddy 稍微算了一下家裡書架上的電腦相關書籍，大概有 1000 多本，不過 Teddy 真的有熟讀的可能不超過 300 本，其他很多是買回來看了幾頁就丟著（資質不夠，讀不下去...），或是當作參考書之用（寫 papers 或是 proposals 會用到）。此時腦袋中突然想到『滿天是金條，要抓沒半條』這句話...

本篇的重點，Teddy 想講的是，到目前為止，有兩個人寫的書，Teddy 全部都買了而且讀過之後會有一種『戰鬥力向上提昇一級』的感覺，這兩位就是：Kent Beck 與 Martin Fowler... 真希望他們有空多寫一點書啊。

***

友藏內心獨白：有些書，除了拿來當『分母』以外，似乎沒什麼作用。 

聞過則喜...誰說的？

July 17 15:21~16:06
19:28~20:19

最近罵人罵得太頻繁，但由於考慮到『人情世故』以及怕走在路上被『蓋布袋』，因此罵的方式很間接，覺的不太過癮。此時 Teddy 突然想起了一則親身經歷的小故事。

話說 2004 年九月 Teddy 到美國參加 PLoP 2004 （Pattern Languages of Programs）研討會，這是 Teddy 第一次出國參加研討會，雖然有 Kay 同行陪伴，但是 Teddy 心裡還是滿緊張的。這個 PLoP 研討會鄉民們可能不太清楚，一般的研討會，輪到你報告論文的時間，大概也就是 15 - 20 分鐘。報告完畢之後，以台灣人這麼會善用時間的特性，一定是利用機會到當地去探訪一下風土民情，順便做一下國民外交（以上翻成白話文就是：到處觀光）。但是 PLoP 研討會是採用所謂的 writers' workshop 形式舉辦，有以下幾個特點：

• 投稿 papers 的作者，會被分成數個約 4 - 6 人的小組，研討會就是以小組討論的形式進行。
• 所有作者在參加研討會之前，就會得知自己被分配到那一個小組，並知道小組中其它成員。
• 在出發參加研討會之前，要讀過自己那一個小組其他作者的論文（原因等一下就知道了）。
• 每次討論的 session，以 Teddy 當年的例子，為 75 分鐘。在這個 session 中，只討論某一位作者的 paper。
• 討論會的開始，由論文作者先念一小段自己論文裡面最喜歡的段落。之後作者就成為『牆上的蒼蠅』，退居幕後聽其他的人如何評價你的論文。在這期間原作者不可以講話。
• 此時輪到其他人上場，大家先一起發表自己覺的該論文寫得好的部份，然後在說出覺的論文中需要改進的部份。

當年和 Teddy 同組的除了 Teddy 以外還有四個人，其中三位（兩男一女）都是美國大學的教授，另外一位男士是英國人。這位英國人後來將他的論文整理之後出了一本厚死人不償命的書：xUnit Test Patterns: Refactoring Test Code。現在想起來還有點好笑，因為當時有一位美國人還覺這位英國人『有些英文句子寫的有待改進』。

***

接下來的才是重點，這三位教授中，其中有一位就是寫 GoF Design Patterns 的第三作者 Ralph Johnson，此人就算是稱不上『大師』，但也算是有名的大牌教授。這個故事就是發生在他的身上。

就在某次輪到要討論 Johnson 的論文時，我們這個小組突然多出了兩位圍觀的鄉民，在此以鄉民甲，鄉民乙稱之。鄉民甲看起來是西裔美國人，鄉民乙則是白人。在會議進行中，這位鄉民甲感覺起來就是來拍馬屁的，一直稱讚 Johnson 論文（但不知其動機為何）。重點在於這位鄉民乙，因為這位年輕人是來踢館的。鄉民乙舉出了幾點 Johnson 論文裡面的錯誤（Java 程式碼的語法錯誤以及一些設計上的 issues），當場氣忿弄的有點僵。好在其他兩位教授以及那位英國人幫忙出來打圓場，說是『程式碼放到 word 排版很容易出錯』就這樣交代過去。雖然鄉民乙還想要繼續追打下去，但是畢竟勢單力薄，最後也只能見好就收。

那個 session 結束之後，Teddy 和 Kay 看到 Johnson 急急忙忙的跑去打電話，應該是打電話去罵他的學生吧...呵呵呵...Teddy 猜這論文應該是他學生幫忙寫或是排版的...。
 

***

Teddy 很是佩服鄉民乙的行為，因為鄉民乙所舉出 Johnson 論文中的幾點錯誤，的確都是『事實』。就算『只是排版錯誤』，但對於學術論文而言，也是很丟臉的事情，不是小學生寫錯字回家罰寫三遍就可以交代過去的。這種事要是發生在台灣...錯，假設不成立，根本不可能發生，台灣地狹人稠，大家動不動就說『相遇得到（修都A丟）』，誰敢那麼白目去揭穿『國王新衣』的秘密。

古人說，聞過則喜，但時代不同了，鄉民們不要傻傻相信。現在台灣普遍的現象則是：

• 官大學問大：反正當官的只要用一句『這是經過通盤考量之後的決定』就可以把所有的專業判斷全部打死。『通盤考量』翻成白話文就是說『老子就是要這樣幹，抗議無效』，是不是這個意思？就是這個意思....。
• 速食主義：凡事求快，要用最低成本達到短期目的。所以，新聞不必講求事實，只要報導那一家店在打折，那裡又推出新口味的火鍋，誰家的狗會唱歌，誰家的小強跌斷了腿又自行長了出來。其他內容只要把每天報紙上所寫的念一遍，加上從網路『翻拍』畫面加上配音說明，這樣就差不多了。難道台灣的新聞系上課都在教這些？
• 共犯結構：請自行發揮...
• 有關係就沒關係，沒關係就有關係。
• 為反對而反對：反正只要是非我族類，不管做的好不好，對不對，先罵了再說。可憐的楊大砲，沒事寫什麼書，最後落得一堆人想去告你。大陸人曰：不到北京不知道官小，不到上海不知道錢少，不到海南島不知道自己身體不好，不到台灣不知道文革還在搞。最後這句還挺貼切的。

寫到這邊有點離題了，不過反正本部落格一向以離題著稱...XD。昨天看了部電影，叫做『我的名字叫可汗（My Name Is Khan）』，片中男主角的媽媽告訴他，世界上只有兩種人，做好事的好人，和做壞事的壞人。不要分什麼回教徒，印度教徒，基督教徒，或是白人，黑人，本省人，外省人，台灣人，中國人。說得很好，但是有一個根本的問題電影中沒交代『誰來決定誰是好人，誰是壞人？』黑道漂白的例子可是屢見不鮮，好人做壞事的也是時有所聞。

***

看到有人用奇怪的方式去教導 Scrum，本和 Teddy 無關，反正害到別人也不會害到 Teddy。但是回頭想一想，如果悶不吭聲，Teddy 也很可能在其他自己不熟的領域，被其他人害到。台灣人這種『息事寧人』，『多一事不如少一事』的心態，要改過來還真不容易。連 Teddy 也變得有點『俗啊』，不敢指名道姓的點出有問題的文章。

布袋戲有一句很有名的台詞『互向漏氣求進步』，和聞過則喜的意義差不多。在現今社會，能做到的又有幾人？

***

友藏內心獨白：年紀越大，膽子越小，此為正常現象，請安心度日。

熟讀 Design Patterns 之後

July 16 23:10 ~ July 17 00:21

有在看搞笑談軟工的鄉民們應該都知道 Teddy 上個禮拜六晚上在天瓏書局遇到了一個畢業四年的學弟，這位學弟目前的工作是 programmer，正打算轉換跑道，朝向 PM 之路邁進 。在學弟正式『棄手從口』開始 學壞 學會打嘴砲之前，他還是問了 Teddy 一個技術性的問題。

學弟：學長，工作這三年來我已經把  GoF 的 Design Patterns 弄得很熟了，但是在接一些案子的時候，總是覺的好像還是少了些什麼。

Teddy：你這樣問太抽象了，可否舉個例子。

學弟：例如，我目前接手的案子，經常需要配合不同的客戶，而改用底層不同的 libraries，久而久之這樣導致我的 AP 邏輯變得很亂。總覺的應該要在 AP 與 libraries 之間定義個 interface ，但是因為不同廠商提供的 libraries 介面都不一樣，真的要定 interface 一下子又不知道要如何定起。

Teddy 內心獨白：上面的敘述是 Teddy 自行揣測加以修飾過的，當場 Teddy 其實是沒聽懂學弟的問題...XD。不管了，時間有限，就當一回蒙古大夫吧。

Teddy：你不是有修過 software architecture（SA）嗎？

學弟：沒有耶，那一年剛好沒開。

這...算你倒楣.....嗯嗯...既然身在天瓏，食材如此豐富，Teddy 就好好利用一下，就地取材將學弟引導至放 software architecture 書籍的這一邊。原本 Teddy 是要介紹學弟看 Contributing to eclipse 這本書，耶，書架上怎麼沒有。此時熊熊想起，這本書已經絕版了，改用 B 計畫。

Teddy：Pattern-Oriented Software Architecture 這一系列的書你可以參考一下，對於你的問題應該會有幫助。這一系列出了好幾冊，可以先看第一冊就好了。

Teddy 利用學弟正在看書的機會，趁機 落跑 跟學弟告別，並祝他轉換跑道成功。

***

鏡頭回到 agile methods，為什麼搞 agile  的人會告訴你不要做 big up-front design？奇怪了，如果不做 big up-front design，不給他好好地『打好基礎』，導致架構不良，日後軟體開發不是會遇到很多問題嗎？（Teddy 內心獨白：不知到為什麼最近對於打好基礎這幾個子特別反感...誰能了解 Teddy 的痛苦啊...）

害怕軟體會因為架構不良而需要一直改來改去，所以要打好基礎。因為要打好基礎，無形之中便落入了 big up-front design。但是做了 big up-front design，到頭來等真正 coding 的時候又發現『理想與現實的落差居然是如此之大』，結果還是一直改來改去。很熟悉的劇情吧，因為太多軟體專案都是這樣進行滴。

那到底要如何能夠做到 agile 書上所說的那種境界呢？其實答案在書上也都有，簡單一句話就是 developers 的技術能力要夠好，再搭配一些仙丹妙藥一起服用，效果更佳。說具體一點，要達到不做 big up-front design 又可以讓 software architecture 不會在日後的軟體開發過程中長壞掉，至少需要練到以下幾招：

• 要能活用 GoF 的 Design Patterns：這本書裡面的招式，只要能真正了解並活用，就已經拿到解決上述問題的門票了。
• 多看 software architecture patterns：有時候要解決的問題比較大，光從 GoF 的 design patterns 要推導出解決方案會耗時過久而且對於比較沒有經驗的人很容易就會套用到走火入魔。所以，還是那句老話，能抄就抄。別人的架構，就是最好的架構。問題是，該如何知道有那些架構可以抄啊？平常花一點點時間，稍微了解一下 software architecture patterns 有那些，等自己遇到問題的時候，在看看有那些是可以拿來用的。不要說沒有，鄉民們的問題有 99% 的機會應該都可以找到立即可用，或是至少具有相當參考價值的 architecture patterns。如果真的找不到，那肯定是書看的太少了。少加點班，多看點書吧。
• 寫 test cases 和 refactoring：任何東西，蓋的在好，用料在如何的實在，日子一久還是會退去原來的光彩。在軟體界，靠著自動化測試案例與 refactoring 來幫忙『修復』軟體設計與架構，這一點想必鄉民們都知道了，就不多說了。

***

不管是資深工程師，或是剛出社會的菜鳥，一旦工作之後，相信大家可自由支配的時間都相當有限。在這麼有限的時間中，如果要投資時間學對於開發軟體有實質幫助的東西，還是把 design patterns，architecture patterns，software testing，refactoring 給學好 C/P 值會比較高一點。至於 UML....把 Martin Fowler 所寫得 UML Distilled 『稍微』瞄一下就 OK 了，不要搞到走火入魔。這算是 Teddy 的個人偏見，如果有 developer 的 UML 熟到不像話，Teddy 還真懷疑此人是否會寫程式。

UML 大內高手留言：程式寫得好，要飯要到老（此為設計對白...XD）。

***

友藏內心獨白：對於『打好基礎 + UML』不爽的文章也罵得太久一點了吧。

給我裝快一點

July 15 22:14~23:33

一個月前 Teddy 打算買人生第一部汽車，因為 Teddy 對車子完全不懂，所以花了許多時間在網路上爬文。由於 Teddy 口袋不深，所準備的預算大概只能買國產車。在這之前，Teddy 對於國產車的印象，一直停留在『裕隆』所生產的『飛羚101』的那個年代（新新人類內心獨白：這是什麼碗糕？），但是為什麼網路上把 Toyota, Nissan, Mitsubishi 等日系品牌的小車也都歸類在『國產車』這個分類？後來 Teddy 才搞懂，原來這些外國品牌的車，為了成本考量（省一點關稅），和國內的汽車廠商合作，將由國外設計的車輛，在台灣『組裝』，這樣就變成了國產車了。

原來如此，難怪 Teddy 有時候在網路上看到有鄉民們抱怨說買到 Toyota 的新車卻發現很多問題。奇怪了，由於 Teddy 之前讀了好幾本關於 Toyota Production System (TPS) 的書，印此留下了『Toyota 出品，觀眾有信心』的印象，為什麼會有鄉民們抱怨 Toyota 的新車組裝不好。原來是......應該說....原來『可能是』台灣的組裝水準沒有日本那麼好（路人甲：這句應該用肯定句吧。）。後來 Teddy 又陸陸續續發現有不少的鄉民們都在抱怨這些外國品牌的車輛『國產化』之後，品質變差了。

這件事給 Teddy 一個啟示，那就是『組裝很重要』。就算是整車的零件全部都是 Made in Japan（迷之音：壓縮機，日本生產的非常非常稀少...XD），但是只要組裝出問題，最後顧客拿到的還是一輛爛車。

***

那麼軟體呢？還記得 Teddy 之前介紹過的 "What is Software Design?" 這篇文章的作者Reeves 提到，code (程式碼) 本身才是『軟體設計』的產出物， 至於 compile, link 這些活動才是軟體生產（組裝）活動，成本趨近於零 （IDE 上面按個按鈕就 OK）。當然，如果軟體稍具規模的話，光靠 IDE 來產出軟體產品是不太夠的，因此軟體生產活動的責任就落到 CI (continuous integration) 或是 build systems 身上。想一想也挺有道理的，不管軟體個別模組或是元件品質有多好，要是『組裝』沒有搞好，最後拿到的還是一個爛東西。Teddy 10 幾年前就有切身之痛，軟體裝在客戶端，才發現包到一個舊版本的 dll 檔案，導致某個功能不能用。這跟拿到一台雨刷不會動，或是引擎蓋無法密合的『新車』，有什麼不同？

照理講，有規模的軟體開發公司，都有專門人員來負責組裝軟體。但 Teddy 相信絕大多數的鄉民們，應該跟 Teddy 一樣，只能 DIY。DIY 就 DIY 吧，誰叫咱們是窮苦人家的小孩呢...XD。

組裝軟體跟組裝車輛一樣，有三個重點：

• 要裝得快：人別一小時可以組裝 10 輛車，你只能裝 1 輛，那就遜掉了。
• 要裝得好（品質要好）：別人裝的車連續開 10 萬公里都沒問題，你裝的車開一開方向盤還會掉下來（Teddy 內心獨白：好一個卡通人生啊，車子開到方向盤掉下來才會有王子現身，這樣講也對啦...XD），遜掉中的遜掉。
• 要裝得省（費用要省）：人家裝一台車的工錢成本只要 5 千塊，你要花 5 萬，那就...太貴了。

上面三點聽起來好像是廢話，沒錯，但是這是有用的廢話。別小看這三句廢話，要全部做到還真是不簡單。 Teddy 之前提過的 『土炮跨平台自動化功能測試環境 』就是用來自動驗證軟體是否有『裝得好』同時考量到『裝得省』的一種作法。而『Ten-Minute Build 』則是探討如何『裝得快』。沒想到類似的觀念在幾天前 Teddy 介紹的 Software Build Systems: Principles and Experience 這本書裡面也有提到，難怪 Teddy 讀了這本書之後，有一種相見恨晚之感慨。算一算 Teddy 研究  CI 也有超過六年的時間了，papers 都寫了好幾篇，CI 系統也開發了好幾代，但就是沒辦法像『阿斗仔』寫出這麼好的書。不過要是存心想騙錢的話，還是可以寫出好幾本書。書名 Teddy 都想好了：

• 寫給程式設計師看的 CI。
• 寫給架構師看的 CI。
• 寫給專案經理看的 CI。 
• 寫給老闆看的 CI。 
• 寫給客戶看的 CI。
• ... 
• 寫給總統看的 CI。 
• 寫給死老百姓看的 CI。
• 寫給你媽媽看的 CI...XD。

（內行人內心獨白：在台灣寫書是賺不到什麼錢滴，但是用騙的就不一定啦...哇..哈哈哈哈....）。

嗯嗯....言歸正傳，今天 Teddy 稍微介紹一下 Software Build Systems: Principles and Experience 這本書第 19 章, p. 515 提到的加快 build 速度所需注意的四點：

• Measuring build system performance
• Eliminating unnecessary rebuilds
• Parallelism
• Reducing disk usage

這四點不用解釋光看標題就知道是什麼意思了，其實只要鄉民們有在花腦筋做 CI 都可以推導出來（路人甲：這樣根本不算有介紹到吧！）。

講完收工。

***

友藏內心獨白：關於組裝，還有一件不能說的秘密...嘿嘿嘿...。

Scrum 三年兩個月

July 14 21:07~22:15

算一算從開始帶第一個 Scrum team 到現在也已經過了三年兩個月了，在那之前，Teddy 雖然讀了一堆 agile methods 的書和 papers，對裡面的作法也十分認同，但是並沒有機會真正帶領一個 agile team。經過這三年兩個月，Teddy 有幾點感想。

首先，這幾年 Scrum 在台灣算是有一點小流行，而且由於 Scrum 框架本身很簡單，因此採用的門檻不算高。但是，如果光是學到 Scrum 的皮，而忽略 agile methods 的精神，那麼對於團隊而言可以獲益的地方就相對的比較有限。Teddy 聽某個採用 Scrum 的朋友說起他們實施 Scrum 的方式，一個 sprint 長達 6 周，而團隊實做 story 的方式，基本上還是由所謂的『架構師』設計系統架構，『分析師』負責系統分析，最後再把分析好的設計文件交給 該死的 programmers 去實做。不難想像，以這樣的分工方式，sprint 的長度顯然不可能太短。如果是一個剛開始採用 Scrum 的團隊先採用這種『過渡時期』的作法，倒也無可厚非。但是如果要儘量遵循 agile 的精神的話，日後還是要想辦法打破這種『你是架構師』，『他是分析師』，『我是 倒楣的 工程師』的這種分工方法才好。應該全部的人都是 倒楣的 工程師，要死大家一起死，這樣才有 投名狀 團隊精神啊...XD。

其次，請屏除什麼『打好 agile 專案地基』的這種想法。Agile methods 就是要『embrace change』，就是要 evolutionary design。『捧油』，誤人子弟所賺來的錢，花起來會心安嗎？敏捷開發，絕對，絕對不需要用 UML 或是其他類似的 formal notations 來上手。想學 Scrum 的鄉民們，Teddy 在這邊拜託各位，千萬不要去畫什麼 use case diagrams, 把寶貴的生命（時間）省下來。要看的話，還不如去看 Scrum and XP from the Trenches 就夠了。

再其次，做軟體，用的就是『人腦』。不管用什麼阿貓，阿狗的方法，團隊成員的素質還是最重要的。千萬不要想說，用便宜的價錢多找幾個人來開發軟體，反正人多好辦事啊。錯，應該是人多易誤事，三個和尚沒水喝才是。根據某本書的說法，好的 programmers 跟不好的 programmers，其生產力可以差 10 倍。Scrum 與 agile practices 不是萬靈藥，也不是什麼神秘的武功秘笈。想要知道關於軟體開發的知識，書上幾乎都有寫了。問題出在於『做事的人』有沒有辦法去落實這些招數。這一點 Teddy 多年來有很深刻的感受，為了讓自己晚上可以睡得安穩一點，還是要多花點時間和銀子，找到合適而且可以合作的人。

最後，對於台灣很多中小型軟體開發團隊而言，也許人力不夠，因此導致『一個人打全場』的窘境：Product Owner 要兼任 Scrum Master 甚至還要當 developer，做三份工卻只領一份薪水。亦或是團隊中沒有專屬的 testers / QA Team 一起配合。也有可能對於眾多的 agile practices （例如 unit test，continuous integration，refactoring，pair programming，shared code，等等等等等等...）不熟，或是一時無法落實。此時，請想起 Teddy 所說的『Scrum 之逆練九陰真經 』，但是也要切記不可搞成『同誰，九陰真經不是這樣子練滴 』。

***

這個 sprint 即將結束，明天就是 sprint demo 與 retrospective meeting 的日子，Teddy 在昨天就先把下個 sprint 所要做的 stories 先準備好。今天下午五點左右，同事要 Teddy 幫忙測試（驗收）某個功能。假設這個功能有 10 個可能的路徑，在 Teddy 測試之後發現同事只做了其中的 5 個路徑。和同事討論之後發現，原來另外 5 個路徑需要參考某個資料才可以『有效率』的完成（缺少該資料程式還是寫得出來，但是會效率不彰） 。了解這個狀況之後，Teddy 重新評估一下，認為提供這個資料的重要性提高了，因此就把提供該資料的 story 排入到下個 sprint 中，降低了另外一個 story 的重要性。

Teddy 可以買書，你可以買書，他可以買書，每個人都可以買書。有沒有『傻的願意相信』的精神，那就不一定了。

***

友藏內心獨白：救人啊，地基到底還要打幾集才會結束啊。

開發與測試：在或不在 sprint 中

July 13 21:13~22:16


幾天前 Teddy 不小心誤闖了 Scrum Community in Taiwan Facebook 社團的某個討論，其中有一小段討論提到這個議題：在 sprint 中會不會經常無法完成測試的工作？這樣講其實不太精確，何謂『測試工作』？是指 programmers 所做的測試還是 QA team 所做的測試（路人甲內心獨白：我們沒有 QA team...XD）。亦或是兩者皆有？

今天就來談一下這個問題，這邊講的『測試工作』包含 programmer test 和 QA test，但是相信在台灣，有許多小型的團隊是沒有專屬的 QA team 一起配合，所以這個問題又可以區分為沒有專屬 QA team 與有專屬 QA team 來討論。

先談談前者，若是團隊沒有專屬的 QA，則可以由 Product Owner 兼做驗收（功能）測試的工作。理想上，這樣的團隊如果能達到 continuous delivery（自動且頻繁地產出可執行的軟體產品），則只要 developers 一完成某個 story 甚至是該 story 裡面可供測試的 task, Product Owner (或是其他 developer) 就可以立即對這個 task 作驗收測試。當某個 story 所有的 task 都完成之後，通常還會有一個單獨的 testing task 來對整個 story 做測試。

由於 developers 在開發的時候會撰寫 unit tests，而每個 story 所包含的 tasks 在完成之後也都會被測試，因此當整個 story 完成時，所需要的測試時間相對就比較短，而發生的問題也會比較少一點。在此情況下，很少會遇到『測試要等到下個 sprint 才能做完』的情況。但是有時候還是可能發生 story 完成之後 sprint 已經快結束了，所剩時間有限（例如，sprint 結束的那個禮拜的禮拜四下午快下班才完成），因此在 sprint demo 時該 story 就可能被測試的不是很完整。在這種情況下，可以選擇在 retrospective meeting 之後利用下班前的時間再補考 補測一下。若有發現 bug 則列入下一個 sprint 中優先修正。

如果團隊對類似 Robot Framework 這種自動化功能測試的工具熟悉的話，那麼就可以將一些原本由人工手動執行的功能測試，逐漸用自動化功能測試案例來取代。最後還要加上一條原則，就是『每次只要有人發現 bug，就一定要寫一個測試案例（單元測試，整合測試或是功能測試皆可）來確保相同的問題如果以後還繼續發生，可以被測試案例給找出』

最後，就是每天晚上在軟體所支援的平台上，自動將這些測試案例全部跑一遍，如果隔天發現有問題，則立刻釐清問題並加以排除。排除的方法有可能是測試案例寫錯（不穩或是因為待測程式與待測資料改變而導致測試案例的內容需要修改），測試環境有問題，或是待測程式有 bugs。


鄉民們可能會說，這樣光靠 Product Owner 來手動作驗收測試不夠啊。是啊，但是想一想，一個沒有 QA team 的團隊，能夠做到這樣，算是仁至義盡，老闆和客戶也該偷笑了。

***

如果團隊有專屬的 QA team，則測試的方式有兩種。

• 今日事，今日畢：在同一個 sprint  中，QA team 要把 developers 所完成的 stories 全部都測試過。
• 今日事，明日畢：QA team 測試 developers 上一個 sprint 所完成的 stories。

這兩種方法各有利弊，第一種方法，QA team 和 developers 要協調的很好，當 developers 在開發功能的時候，QA team 就要設計 test cases。但是即使是這樣，也還是很有可能經常發生 story 完成之後，已經沒剩下多少時間給 QA team 做測試了。採用第二種方法，則 QA team  可以有一整個 sprint 的時間來做測試，『感覺起來』時間會比較充裕。但是有可能正在測試的功能 developers 也剛好正在修改，到頭來還是要重測一次。

無論採用那一種方法，有兩件事情是很重要的。

• QA engineers (or testers) 要有能力設計測試案例（測試腳本）：這一點聽起來像是廢話，但是 Teddy 相信有很多 testers 是不會自己去設計測試案例的，只是依據 developers 所提供的測試項目去做測試，基本上算是『真人版的 Robot Framework』。要能夠設計案例，testers 一定要跟參與開發的活動，知道每一個 story 真正要完成哪些功能，這樣設計出的測試案例 coverage 才會比較足夠。
• 能夠自動化的測試盡量想辦法自動化：測試案例永遠都寫不完，也不嫌多。但是，如果這些測試案例都要由『真人』（手動）來完成，那麼完整測試一次的時間會被拖得很長，如此一來就無法搭配 developers 的進度（簡單講就是要能夠自動 regression testing）。至於哪些沒辦法自動化的測試案例，那就三不五時動動手測試一下吧。

 ***

友藏內心獨白：買翻譯機要真人發音，做測試則要假人測試（自動化測試）。

還少一本書：Software Build Systems: Principles and Experience

July 12 21:05~22:12

上禮拜六晚上在南陽街附近吃完『本格派』的親子丼之後，順道去天瓏逛一下。去年到美國出差買回來的書都還沒看完，原本也沒打算要買新書，想說瞄一下看看天瓏最近有沒有進什麼新書。看著，看著，Teddy 的眼睛突然被某本書的書名『刺』了 一下。是何書如此大膽，居然敢行刺 Teddy，原來是...

Software Build Systems: Principles and Experience

***

Teddy 在『CI 之看來看去少了一點什麼  』提到 Continuous Integration 這本書寫得雖好，但是看來看去覺的少了一點什麼，少了什麼？就是少了『你打算要開發一個（中大型）軟體，要如何將該軟體放到 CI 系統上？』的答案。其實 Teddy 這樣說也並不公平，在 Continuous Integration 第 94 頁 Build System Components Separately 這一小節中其實有提到：

Sometimes integration builds take a long time to execute because of the time it takes to integrate the source code and other associated files. In this case, you can break apart the software into smaller subsystems (modules) and build each of the subsystems separately. 

算是對於上述問題有稍微『點到為止』指點了一個方向，但是關於要如何『實做』卻沒有提供答案。而今天 Teddy 要介紹的這本書，算是鉅細靡遺的將如何建構一個 build system 這件事從頭到尾清清楚楚的交代一遍。有些書，就算是從頭到尾讀上好幾遍，都無法給它按一個讚。有些書，看完前言就已經是讚讚讚讚讚.....『連讚不絕』啦。Software Build Systems 就是屬於後者。

這本書到底好在哪裡...簡單歸納以下幾點：

• 可以當 build systems 的教科書：這算是優點嗎？是滴，Teddy 覺的作者有點像是在寫『Journal papers』的精神來寫這本書，不但介紹了許多 build systems 領域的術語，並且用了許多『歸納』的方法來介紹 build systems domain knowledge。舉個例子，作者在第 xxviii 頁提到兩種建構大型軟體產品的方法，分別是 Monolithic builds 與 Component builds 。說真的，這兩種方法其實 Teddy 早就知道了，但是就是沒辦法像本書作者一樣可以明白的告訴你這兩種方法的名稱與作法。以上特點，讓 Teddy 可以把這本書當作寫 papers 的參考資料，真是太讚了...找你好久了....XD。
• 用很簡單的方法介紹 make file 的寫法：話說 Teddy 活到這把年紀，對於 C/C++ 的 make file 裡面一堆奇怪的符號總是搞不懂。本書裡面的例子，連 Teddy 都看得懂，相信各位鄉民們也一定看得懂。
• 介紹五種不同的 build tools：包含 MAKE, ANT, SCons, CMAKE, ECLIPSE (Teddy 內心獨白：這個也算？)。個別去了解這些 tools 是滿花時間的，有人幫你準備的好好地，又是一個讚。對 Teddy 這種需要開發跨平台軟體的人而言，能夠看到同時介紹 MAKE 與 ANT 算是滿實用的（Teddy 內心獨白：你不一定要會寫 build scripts，但是至少要看的懂...不會寫詩，至少也要會吟啊）。
• Advanced Topics 與 Scaling Up 更是精彩：本書最後兩個部份介紹 Dependencies, Building with Metadata, Software Packaging and Installation, Version Management, Build Machines, Tool Management, Reducing Complexity for End Users, Managing Build Size, Faster Builds。這些內容，對於深入了解 build systems 以及 CI 都是非常實用的資訊。尤其書中還有提到對於開發跨平台軟體需要注意的地方，這一點更是符合 Teddy 的口味啊，真是 好吃 好看。

介紹到這邊，書的內容還是要請有興趣的鄉民們自行挖掘。這本書寫得很好，還滿容易閱讀的。想買的鄉民們手腳要快，有人看到這一篇可能明天就衝去買了，晚到可是會搶不到滴。

***

友藏內心獨白：如果幫忙推薦書也有錢可以賺那該多好...XD。

PM 可以分成四大類

July 11 22:12~22:48

PM（project manager/product manager）可以分成四大類，那四大類？

• 第一大類：自己爽的要死，developers 罵的要死（約 80% ）
• 第二大類：自己累的要死，developers 罵的要死（約 19% ）
• 第三大類：自己累的要死，developers 爽的要死（小於 1% ）
• 第四大類：自己爽的要死，developers 爽的要死（趨近於 0%）

***

上禮拜六晚上 Teddy 去天瓏瞎逛，碰巧遇到一位畢業四年的學弟。這位學弟畢業服了 11 個月的替代役，退伍之後在XX康工作了一年多，後來跳槽到XX通，做的工作都是 coding。學弟告訴 Teddy，工作這三年多以來的感覺，和他以前在學校時的想法差很多。以前學弟覺的可以靠『技術』賺到錢，但是工作之後發現，紅利都被『高層』給拿走了，底下的工程師賺不到什麼錢（Teddy 內心獨白：這不是大家都知道的事嗎？！）最近學弟有一個機會，可以轉行當 PM，希望有朝一日也能晉升為『只拿紅利不做事的高層...XD』。

學弟說，他有一位之前在XX通的同事，跳槽到H踢西，想找他去當（小） PM。據說原本照理講學弟只有三年多的工作經驗，對H踢西而言還算太嫩，但聽說H踢西要找一位『會寫程式的 PM』（Teddy 內心獨白：難道H踢西的 PM都不會寫程式？），再加上有人推薦，所以機會還滿大的。


根據 Teddy 一開始的分析，由於大部分的專案，都屬於『PM 爽的要死，developers 罵（累）的要死』的這種型態，所以 PM 自然成為眾多 developers 往上爬的理想職位之一。Teddy 當天來不及告訴學弟的是：要當第一大類的 PM 是很簡單的，只要臉皮夠厚，嘴巴夠ㄐ一ㄢ，四聲，就可以了。要當第二大類的 PM 也不難，有心做事但是能力不夠，方法不對。至於第三類，不做也罷。最後，最高境界的第四大類，先練個二十年之後再來找 Teddy 吧。

結論，如果學弟去H踢西 ，則 99.9% 的機率應該是會『自己累的要死，developers 罵的要死』。請保重，謝謝有空再聯絡。

***

友藏內心獨白：當天忘了跟學弟推銷『搞笑談軟工』啦，殘念。

我真是猜不透你啊：種花篇

July 07 21:35~21:55

今天看到一則報導，『種花』表示到 2020 年的時候，要家家戶戶都有 1G 的網際網路連線可以用。但是，據網路上看到的消息，人家日本現在已經有 1G 的網路了（而且好像是雙向 1G），而韓國則是明年（2012）年就要提供 1G 的網路連線。蝦米，Teddy 有沒有看錯，2020 年 ?! 大尾 偉大的『種花』要到 2020 年『才要』提供 1G 的網路服務，落後別人這麼多還敢拿出來講。看到這裡，讓 Teddy  想到『種花』最近強打的 50 M....人家都已經在用，或是準備要用 1000 個『妹』了（哇，1000 個妹，家裡都坐不下了...XD），『種花』的 50 『妹』相形之下就弱掉了。什麼，你說要那麼快地速度幹麼？....你家住海邊啊，管那麼寬...XD

想一想 Teddy 還在用 8M / 512K 的 ADSL，不禁悲從中來。好吧，50 M 還是大於 8M，這麼簡單的算術問題相信大家都能了解。剛剛閒著沒事想說去申請一下『種花』的 50M/5M，結果卻是令 Teddy 感到吐血。

首先，Teddy 在網路上填寫申請資料，填到最後一步的時候，畫面下方居然出現以下四點備註：

1. 光世代若須附掛市內電話，則客戶名稱、裝機地址須與附掛之市內電話相同，如不相同，請先辦理一退一租、移機或另申請一線電話。
2. 有關光世代進一步資訊，請參考光世代服務說明。
3. 光世代網路品質為「Best effort」模式，不提供頻寬保證。
4. 請於網路申請成功後十個工作天內攜帶證件至各地營運處窗口辦理驗證及預約裝機時間，逾期未辦理，本公司將註銷該申請。

前三點 Teddy 都能接受，這第 4 點是怎樣？！都已經在網路申請了，還需要『攜帶證件至各地營運處窗口辦理驗證及預約裝機時間』。Teddy  都已經是『種花』ADSL 的客戶超過 10 年應該有了，還要『驗證』個什麼東東？還有，『預約裝機時間』不是打通電話來確認一下就好了嗎？誰有那個美國時間還跑去『各地營運處窗口』去辦理？！

算了，誰叫他是『種花』呢，不能以常人的眼光來看待，Teddy  認了。填完資料按下確定，請看下面畫面：

現在是怎樣，生意太好不想接單，還是流量太大灌爆系統，填個小小的申請單居然還能夠『系統程式錯誤』，還建議 Teddy 『立即撥打服務專線』（Teddy 內心獨白：0800 000 000 ...XD）。這真是應驗了 Teddy 之前所說的『電子化比不上一通電話 』。

結論，想要 50 妹，Teddy，沒這個命啊。

***

友藏內心獨白：不要只想著賺錢，到 2020 年，別人可能已經用 1T 的速度上網了。

CI 之看來看去少了一點什麼

July 04 21:35~22:55

前一陣子為了找資料花了點時間把 Continuous Integration: Improving Software Quality and Reducing Risk 這本書再讀過一遍，這本書 Teddy 讀過好幾次了，但總是沒有耐心把全部的內容都看完，這次當然也不例外...XD...不過這次有『很用力』的把 50% 以上的內容仔仔細細地重讀一次。以 Continuous Integration (CI) 這個領域來講，這本書算是寫得不錯了，該講的事情大概都有提到，但是不知為什麼，Teddy 讀起來總是覺的少了那麼一點什麼 。

如果鄉民們讀過 GoF 的 Design Patterns，『一路上』應該會有那種『不停地被打一拳』的感覺。這種感覺，雖然痛，但是卻痛的很值得，讓人覺的這是本有層次，有深度的書（史瑞克內心獨白：妖怪就像洋蔥一樣，是有層次滴）。而這本 CI 的書，雖然也提供了許多有用的 guidelines，但卻只是讓人有一種『知道了』的感覺，有點不痛不癢。到底少了什麼？

對，到底少了什麼？Teddy 原本也不知道，但是這次舊地重遊之後，Teddy 似乎發現了一絲線索。話說 Teddy 最近在想一個問題：

你打算要開發一個軟體，要如何將該軟體放到 CI 系統上？

路人甲：嘿嘿嘿... Teddy... 你不是『號稱』對 CI 很熟嗎？怎麼連這個問題都不知道？

是啊，如果鄉民們仔細去看一下 CI 相關的資料，大概可以發現，大部分談得都是：

• CI 的好處：這一點就不用在多做解釋了。
• CI 應該能做什麼：編譯，測試，程式碼分析，產生文件，產生安裝軟體，自動佈署等等。
• 工具：在 CI 系統上有哪些（自動化）工具可以使用。

有沒有提到『如何將一個軟體開發專案放到 CI 系統上面』？其實是有滴，不有提的很少，大體上就是，舉個例子，給你看一個 ant script（build script），然後要把你的軟體專案（通常對應到 SVN 或是 CVS 上面某個目錄）放到 CI 系統上面，等時間到了 CI 系統自然會去執行這個 build script 然後一切順利之下安裝程式就產生了。

***

不知道鄉民們都是如何使用 CI 系統？如果軟體不是很大，依據一般書上所寫得方式，一個軟體產品一個專案，一個 build script，這也 OK。但是假設鄉民們的軟體有，例如，1 百萬行的程式，其中包含 Java code + Javascripts + XML + 一些有的沒的檔案，那麼如果在 CI 系統上面就只有一個專案，則可能會有下面幾點問題：

• 這個專案的 build script 極可能變得超級複雜，不容易寫，也不容易維護。
• 不容易分工也不容易理解。假設這個專案包含了很多模組，現在鄉民們只是要修改其中一個很底層的程式。為了修個這個底層的程式，鄉民們可能要把整個專案（1 百萬行）的程式給 checkout 下來到自己本地端的 workspace 裡面。然後，弄清楚自己這一次要改的功能在那裡，可能又要花一點時間才能找到程式碼的位置。光是用想得就已經累了。
• 每次 build 一次專案很可能會跑很久。

***

另一種方法，Teddy 之前有介紹過，可參考這裡的文章。簡單的說，就是把這個 1 百萬行的軟體分成很多個不同的專案，然後將這些專案全部放到 CI 系統上面。每一個專案都有一個 build script，可以個別地被建構。專案和專案之間有相依性，在最上層的專案是一個『安裝程式專案 （Installation Project）』，負責用來產生安裝程式（最後交給客戶的軟體產品）。

分成很多專案的優點剛好可以解決上面 Teddy 所提到只有一個超級大專案的缺點。Teddy 之前已經介紹過幾種不同的專案類型，例如  Interface Project, Cross-Platform Project, Native Project, Single Shared Library Project, Installation Project, Patch Project，鄉民們可以參考一下這種作法（也許老早就有很多人也用類似的方法了）。

***

Teddy 之前還在研究 e-learning pattern languages 的時候，整理了一個 Separate Material Preparation from Integration pattern，大意是說，製作一個數位化多媒體教材的手續（流程），可以分成以下兩大部份：

• Material preparation: 準備基本的教學內容素材，例如，文字稿，圖片，影音資料等等。在這個階段考慮的是，如何用最方便，簡單又有效率的方法與工具來產生數位化教學內容素材。 
• Material integration: 把準備好的素材打包成一個課程，在這個階段考慮的是，用那一種教學流程來呈現這些基本的學內容素材，才容易被學生所了解。

為什麼會突然提到這個 pattern？套用 Teddy 之前介紹過的 CI patterns，其中 Installation Project 與 Patch Project 就好比 material integration 階段所要做的事情，而其他類型的專案（Interface Project, Cross-Platform Project, Native Project, Single Shared Library Project）則屬於 material preparation。希望下面這張圖可以幫忙說明這個概念：

***

也許鄉民們會說，阿把軟體系統分成很多專案不就是軟體架構裡面講的 module decomposition 的觀念嗎，這有什麼了不起的。或是說，這種區分專案的作法不是應該屬於 configuration management 的範疇嗎？CI 的書沒有提到也還好吧。也許吧，但就不知道是不是每一個學 CI 的鄉民們都能夠把 Continuous Integration: Improving Software Quality and Reducing Risk 這本書看完之後就可以『CI 一次就上手』。

***

友藏內心獨白：沒有什麼東西是一次就上手的。