在蘇拉颱風的侵襲之下, 全島幾乎都放了個颱風假. 在此難得的假期, 當然要好好地研究一下宏碁的認購權證工作中需要用到的知識與技能. 認真再花了 2 個小時, 總算把這本書讀完.
本書的作者是知名部落客 Teddy (陳建村), 他的筆風相當搞笑. 一般人認為硬梆梆的 “軟體工程", 被他寫得像極短篇那篇好玩. 不然這厚達 400 頁的工程書還真不知道要看多久? 以全書的架構而言, 大概可以分成幾各部分:
Part 1: 軟體工程的現況
這部分在於吐槽一般人對於軟體工程的輕視. 一開場就像看 BBS 八卦, 當然就比較願意往下翻書了. 老闆們可能認為加人, 加壓, 加班, 加薪 (?) 就可以搞出軟體. 不過對於軟體開發人員而言, 最重要的可能是環境: 足夠的軟硬體設備, 高品質的測試與開發人員, 標準開發流程, 自動化測試與持續改進的心態.
Part 2: 什麼是 Scrum?
Scrum 先前我概略介紹過了, 更有幸得到朋友的補充. 基本上 Scrum 是敏捷開發 (Agile Development) 方法的一種. 作者認為 Scrum + Lean + XP (eXtreme Programming) 才是正解. Scrum 基本上定義了如何定目標? 如何 review? 的基本架構. 按照台廠的慣例, 服用後副作用不至於太大.
而 XP 正如其名, 它完全顛覆系統廠或是 SOC 廠對於軟體開發的認知. N 年前 Mr. Right 讀了 XP 後, 跟我說要把大家的座位圍成一個圈圈, 我看了看方方正正的 cubic 後, 只能答應讓大家儘量坐在一起… (OS: 同一個 team 確實坐在一起, 只是每個人都有三面牆.)
XP 當然不是要大家圍成一圈那麼簡單, 這僅僅是 XP 五大價值中 “溝通" 的某種展現方式. 溝通不良是造成 bug 的主要原因之一, 打破個人的 cubic 後, 想要躲回自己的角落也就不可能了. 我們更進一步可以要求 pair programming, 讓兩個人同寫一份 code. 一個人寫, 另外一個人看著他寫; 然後再定期交換角色.
第二項價值叫做簡單. 工程師為了要應付進度的壓力, 往往會畫地自限, 告訴自己我在這種時程要求下, 就頂多只能做到這樣. 這種苦同行的人應該都吃過, 所以必然能夠諒解最快的 solution 不是最好的 solution. 不過只要有空, 工程師最好再回頭重構 (refactoring) 自己的代碼, 務必使它在功能不變的情況之下做到優化.
第三項價值是反饋. 反饋愈早, 錯誤愈少. 因此自動化測試的需求就應運而生. 當然, XP 的要求不只是如此, 它甚至希望客戶就坐在旁邊提供立即的反饋, 以及團隊成員迅速給予 review 意見. 為了早日見到設計有無偏差, 持續整合可以提供早期的診斷. 比方說 UI 先畫個框框就被 review, 總比每個 component 都畫好再 review 有用. 到了木已成舟的時候, 根本就改不動了.
第四和第五項價值是尊重與勇氣. XP 講求早提早發現, 儘快治療. 不可諱言, 早期的東西當然很遜, 因此要給予尊重. 我才寫 for 三個字後面的 pair programmer 就鬼叫為什麼不先 do 再 while, 我想誰都寫不下去了是吧! 所以一方面要尊重, 另外一方面要有勇氣. 看著同伴擺爛而照單全收, 那麼 XP 就沒有意義了.
至於 Lean 是甚麼碗糕呢? WIKI 有寫. 作者看中的是它的看板管理. 如果大家去過大陸的系統廠, 應該很容易看到這種看板.

[截圖自 http://www.infoq.com/cn/articles/hl-kanban-task-management/]
有了看板輔助之後, 我們就可以避免每個 sprint 都各顧各的的困擾. 因為 Scrum 的焦點在於 story 的完成, 有沒有達到目標. 但是缺少 Lean 看全部 (see the whole) 的宏觀. 到底多少工作已經完成, 那些還在 queue 裡面, 有沒有互卡的情況, 我們用 Lean 就可以補足 Scrum 的缺點.
Part 3: 精實生產, 減少不必要的浪費
這部分前幾天已經整理過了.
Part 4: 開發軟體一定要加班, 有沒有聽錯?
這部分可以視為作者對於加班的抱怨. 不過他自己已經升格做老闆了, 哈!
Part 5: 換顆腦袋 – 軟體工程的全新思維
此一單元內容比較雜亂, 很難歸納出一個中心思想. 我就引用其中引用洪蘭老師的一句話吧!
停留在港口的船是最安全的, 但那不是造船的目的.
Part 6: 軟體架構
基本上, 這裡引用 Eclipse 來說明什麼是好的軟體架構.
Part 7: 人機介面
在此一單元中介紹了 GOMS (goal, operator, method, and selection rule). 首先要明白設計此 UI 的目的 (goal) , 然後決定怎操作 (operators) 來達到此一目的. 而 method 是 operator 組成的, 重點在於達到目的可能有多個方法 (method). 最後 selection rule 則是提供選擇權給 user, 讓他決定要用哪一種方法. 就拿PC 的輸入操作來說好了, 可以選鍵盤組合, 可以換 hot key, 也可以用滑鼠點工具列.
Part 8: 測試與整合
策是真的是一門學問, 而自動化測試是一門更大的學問. 看來 nightly build 還是不夠的, 我們應該要有系統地導入單元測試的方法. 雖然整合測試比較容易做, 任何一個不懂細節的人都可以寫整合測試 – 像是影片快轉之類的. 但是要把單元驗證好, 非得要作者認同並親自下海才有可能做到. 因此這部分的困難度更高.
作者還提到 10 分鐘建構 (build) 的概念, 並且希望在 build 的過程中就把單元測試也順便做完. 我想這件事對於 SOC 基本上是不可能的. 因為我們採用太多的 open source, 代碼的數量也過於龐大. 如果要加一條測試規範, 我想假設 “沒改過的東西都是對的" – 例如 Android 那包 10GB 的東西, make 完還變成 24GB.
昨天富士通的同事興沖沖地拿一支夠大的大拇哥給我 copy Android, 還建議我壓好再 copy 比較快. 但是我看到裡面已經有幾個小檔案, 又是 FAT32 檔案系統, 單一壓縮檔還是放不進去. 那就整個目錄 copy 吧! 反正, 明天鐵定放假~~~