我讀 «敏捷開發法的逆襲»

在蘇拉颱風的侵襲之下, 全島幾乎都放了個颱風假. 在此難得的假期, 當然要好好地研究一下宏碁的認購權證工作中需要用到的知識與技能. 認真再花了 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 吧! 反正, 明天鐵定放假~~~ 

軟體開發中的七種浪費

Teddy 大的 "敏捷開發法的逆襲" 我還沒有看完, 不過裡面提到的七種浪費行為已經可以整理出來了. 所謂的 "七宗罪", 本來是針對豐田汽車生產過程中的品管. 但是拿來套用在軟體上確實也並無不可.

1. 半成品 (Partially Done Work)

很多功能我們做到一半, 說打通了嗎? 還沒有. 不過可以 demo 喔, 看著都會動, 要圖有圖, 要數據有數據. 這些半成品其實是不能量產的! 如果不能一口氣把半成品推向成品, 久了就會變成廢物. 後來不是規格改了, 就是人改了, 公司投進去的資本就在無形中被浪費掉.

2. 多餘功能 (Extra Feature)

基本上, 沒有主管的要求, 很少人會寫出多餘的功能. 具有要五毛給一塊性格的工程師非常罕見, 雖然他們有時候會被批評為想太多, 進度太慢. 但是比起想太少, bug 很多的人, 我還是比較喜歡前者.

如果說是多餘的或是無效率的代碼倒是很常見, 可以很精簡做完的一件事, 有些時候也會被很囉嗦的方法來達成. 像是我以前 trace GPS 的組合語言時, 就發現這邊的 sin(x) 代碼用泰勒展開式與查表法強化計算速度, 順便把泰勒展開式很接近的 atan(x) 也寫在同一函式節省 code size ; 那邊的 cos(x) 卻是用 sqrt(1-sinx(x)2) 暴力達成, 大吃 sin(x) 的豆腐. 可見不同的工程師自我要求也不相同, 主管的功能在這個地方也可以有所發揮.

[註] 講到豆腐, 我不得不推薦一下中華豆腐 (4205 的恆義), 它不錯.

3.  重複學習 (Relearning / Rework)

所謂的重複學習重點在於重複是個浪費, 但學習不是. 大家各寫各的 code, 為何會重複呢? Teddy 大比較著眼於測試的部分, 因為測試的人要學習如何測試. 如果把 test 做成自動化, 就可以減少測試人員學習的時間.

不過我感觸比較深的部分在於系統整合的階段. 如果我需要一個與使用者互動的功能, 上面包括 UI 的呈現, 中間牽涉 framework 的實施, 底層要把資訊 parsing 出來. 那麼誰要負責 study? 如果大家都去看 spec., 絕對是一種浪費. 若是指定某人去 study, 而他沒辦法把架構從上到下講清楚 (這也點有強人所難), 導致其他人必須在更短的時間內自行搞懂, 這也是重複學習. 雖然此時連一行 code 都還沒開始, 浪費在其中矣.

如何消除這種浪費呢? 我們想想今年的紐約尼克隊. 它需要一個能兼顧得分和助攻, 兩者都還不錯的後衛. 如果沒有這樣的人才, 教練只好要求得分主力偶而也幫忙助攻, …接著就會一團亂. 所以我覺得重點在於人才, 甚至是板凳深度.

4. 交接 (Handoff)

不用說, 交接一定是浪費. 大家都不希望有交接, 不管是主管或是工程師都一樣. 交接的接收人通常想完全沿用舊 code 不要去動它, 或是全部砍掉重練. 很少聽到接收人稱讚他收到的 code 完美無比, 通常將它評價為 "能用" 就很偷笑了. 畢竟就算是被接收人吐槽為很爛, 不能用, 主管也只好買單這種說法, 不然難道要找一個懂得欣賞的人來交接?

5. 工作切換 (Task Switching)

如果 assign 太多工作給同一個人, 對方幾乎都會抱怨的. 就算是努力做事不抱怨的人, 也很難在許多八竿子打不著的工作中迅速切換. 這就像是把許多工作同時丟給電腦, 最好的作業系統也只能保證優先級最高的工作先完成, 其他的…再說啦.

Scrum 的每日站立會議就用來確保大家所做的是都是最優先的.

6. 延遲 (Delay)

延遲的浪費在於導致下游的工作無法展開. 後手的人不得不撥一點心思來 polling 上游的狀況, 並且導致他/她的下游也跟著延遲.

7. 缺陷 (Defect / Bug)

有嚴重缺陷的成品或是半成品都會對下游造成不遜於延遲的傷害. 一個有問題的 commit 導致全 team 的人都編不出新版, 這個代價真是不小. 更不用說 bug 流落到客戶那邊後, 甚至可能造成退貨的危機. 據說某名牌 IC 設計公司的產品就是因為連續開機一萬小時後會自動關機而導致全部退貨. 追究其原因, 也不過就是設計者的觀念瑕疵而已 – 把測試休眠的時間參數寫成一萬小時, 反正客戶也不可能用那麼久不關機, code 就留著以後還可以回收 – 後來真的整個產品都回收了.

我個人也遇到過一個好笑的 bug. 當年做翻譯機的時候, 我自認已經交接完了, 大陸的同事忽然慌慌張張地打電話給我, 說這個 bug 他們解不了, 一定要我去現場看一下. 據說我們的翻譯機很怕遇到快譯通和女生, 只要是女生去試用或是和快譯通放在一起 demo 就會當機, 但是和它牌的同時 demo 倒是沒事.

我過去看了 code 之後, 發現 silence detection 的 zero crossing 寫在 share memory, 但用完後沒有清掉. Co-processer 以為這是 main chip 的 command code, 一執行當然就瘋掉了. 至於為何最怕快譯通呢? 原來快譯通為了聲音好聽, 特別提高輸出的 pitch. Pitch 高, zero crossing 就大到和 command code 剛好值一樣, 才會發生這個 bug. 這兩個故事告訴我們, QA 要找女生. 測試用的 code 一定要用 define 包起來, 這樣就不會導致把測試 code 變成量產版本的問題.

我讀 «我靠基金 38歲退休之基金逆轉勝實戰報告»

前幾天開車的時候, 聽到電台在訪問賤芭樂 (王仲麟先生). 雖然我記得在 57 號夢想街也看過他上節目 (或是由來賓談論他?), 不同於在電視上呈現的 “解盤人" 形象, 在電台上他 “聽" 起來滿謙虛的. 所以當老婆想要在 PC home 買書的時候, 我就順便多買了這本賤芭樂的新書.

本書的前作 “我靠基金 38歲退休" 聽起來確實有點囂張, 王仲麟說那是書商的說法. 他即使 38 歲不上班, 但也並非就此閒雲野鶴, 還是有很多事情要做. 我看了芭樂園這個網站之後, 確定專業投資人其實也是很忙的. 出名之後難免有人來求教, 免費幫路人回答問題也不是輕鬆的事情.

由於作者王先生已經把新書簡介放到 Youtube 了, 所以我也省了很多事, 毋須做太多介紹~~~

然而, 大家若有緣讀到本書, 應該會感覺到它很像是工具書. 作者把各種基金套牢的情況分類寫成不同章節, 然後從四種對策中給予建議 – 停損, 續抱 (停扣), 攤平, 或是擴大加碼. 有時是單選, 有時是複選. 而選擇的原理也很簡單, 那就是依據基金本身的三種屬性 – 大漲大跌麻辣味 (A 級), 小漲小跌家常味 (B 級), 抗漲抗跌你哪位 (C 級). 簡單地說, 凡是大漲大跌的基金, 那就多半建議續抱; 如果抗漲抗跌, 反正漲不多, 有獲利就可以出場了; 沒獲利也不太建議續扣.

我們在大二的時候學過一門數位電路設計, 其中有個單元叫做卡諾圖 (Karnaugh map). 卡諾圖專門把分門別類整理成更簡單的邏輯. 既然我今天醒得早 (其實是醒了睡不著), 乾脆就來歸納一下. 1 表示那招可用, 0 表示不能用, X 表示 don’t care. 四個連續數字表示上面講到的四種對策.

  單筆小賺 單筆小虧 定期小賺 定期小虧
A 套左腰 1011  1011  0011 0011 
A 套頂點  xxxx 1011  xxxx  0011 
A 套右腰  1011 1011  0011  0011 
B 套左腰  1010 1010  1010  1010 
B 套頂點  xxxx 1010  xxxx  1010 
B 套右腰  1010 1010  1010  1010 
C 套左腰  1010 1010  1000  1100 
C 套頂點  xxxx 1010  xxxx  1100 
C 套右腰  1010 1010  1000  1100 

根據陳龍英教授教的, 同類的可以合併, 以簡化設計. 因為不論套在哪裡? 每一級的解法都可看成一樣, 所以我們首先得到:

  單筆小賺 單筆小虧 定期小賺 定期小虧
A 級 1011 1011 0011 0011
B 級 1010 1010 1010 1010
C 級 1010 1010 1000 1100

再來可以看到, 單筆不管小賺或是小虧, 策略的數字一樣. 定期部分, 依據賺或是虧, 作法有點不同. B 級不管怎麼操作, 賺或是虧, 做法都和 C 級單筆相同. 那麼我們可以得到簡化的設計如下.

  單筆 定期
A 級 1011 0011
B 級 1010  
C 級   1000/1100

 A 級和 C 級在定期的部分幾乎是互補 (0011 vs 1100), 除了  C 級小賺後不選第二策略之外. 基本上作者很不建議 “裝死" 的第二策略, 看來看去幾乎都是 0. 然而, 裝死應該是虧損時最普遍的人性啦!

這個第二策略在定期定額是 “暫時停扣, 未來到低點再復扣". 和單筆的第二策略 “暫時擺著, 逢高出場", 雖然數字代碼一樣, 但實際上有點不同. 主要是已經投入的都不動, 也不加碼(續扣), 等到更好的時機出場或是復扣.

所有買單筆的解套策略也都很類似, 除了買到  A 級的人不選第 4 策略之外. 第四策略是逢低擴大投資. 因為 A 級大漲大跌, 要是摸不到底就糟了. 故此點也不難理解.

以上就是我的整理. 至於怎麼知道自己是套在左腰還是右腰? 我想看過作者的前一兩部作品後就可以知道. 昨天我也想過這招能用在股票上嗎? 我想如果公司不會倒, 那麼的確也適用. 只是單一公司的風險很大, 遠不如基金可以分散風險.

漲跌互見的金融商品

剛剛打開理專寄的資料, 發現在一片不景氣之中, 有些產業非常地慘, 但另外一些公司竟然表現還不錯. 衝著這種奇怪的現象, 決定花幾分鐘整理一下.

首先是 ETF 的部分, 我把價格在 52 週的價格位置以百分比計算. 如果 0% 表示創一年新低, 100% 表示創一年新高, 50% 就表示在過去 52 週裡面, 現在的價格正好是中點.

排名  低檔商品 百分比
1. 全球綠能 0.95
2. 以色列基金 1.06
3. 全球媒礦 1.97
4. 全球替代能源 2.49
5. 全球金礦業 2.6

從最淒慘的商品來看, 大家非常不看好未來的景氣, 不想買入資源. 相對地, 以下的幾個商品竟然在高點.

排名 低檔商品 百分比
1. 美國 3-7 年公債 99.31
2. 美國 7-10 年公債 98.68
3 美國投資級債券 98.26
4. 美國 20 年以上公債 98.22
5. 美國 10-20 年公債 98.15
6. 新興市場債 97.29

換言之, 債券的價錢被大家買高了; 現在去買債券有一定的風險. 風險不在於領不到利息, 而是淨值的下跌. 唯一不值錢的債券是美國的短債, 價格百分比是 53.73%, 這是美國政府扭曲操作的結果. 在歐元區的兩年期公債照樣搶破頭, 債券的殖利率已經是負值了  (2012/7/23, 殖利率 -0.04%).

再看到美股本身也很有趣, 它的差異性也令人吃驚. 首先, 礦產沒人要, 也沒有人要買汽車, 非蘋電腦 – 因為蘋果本身在 86.19% 的高水準.

排名 低檔股票 百分比
1. Barrick 金礦公司  0.45
2. 動態研究公司  1.11
3 惠普 (HP) 1.52
4. 美國鋁業 1.55
5. 福特汽車 1.52

大家喜歡吃藥和買日常用品, 不景氣日子還是要過~~~

排名 高檔股票 百分比
1. 輝瑞 96.27
2. 威名百貨 (Wal-mart) 93.6
3 eBay 93.35
4. 默克藥廠 92.6
5. 好市多 92.22

以上供大家參考.

幾種免費防毒軟體的缺點

講到防毒軟體, 應該每個人都用過, 現在連手機版的防毒軟體都出來了. 我用過付費的軟體, 包括趨勢 和 Norton. 另外一半的時間則是用免費的軟體.

我有一陣子買過卡巴斯基. 因為我是大塚軟體的股東, 所以支持卡巴斯基也是應該的. 但是卡巴斯基設定頗為複雜, 掃毒也比較慢, 後來我不再用卡巴斯基, 順便把大塚也賣了. 

Norton 基本上還不錯, 不過一旦過期之後, 就不斷地跳出視窗來威脅客戶, 似乎不用它的軟體, 電腦安全就不保了. 由於 Norton 很難反安裝, 我也拿它沒轍. 只能說是愈看愈生氣, 乾脆把Norton 列入拒絕往來戶! 好在後來安裝某個新防毒軟體時, 它說 Norton 和它相衝, 幫我把 Norton 除掉了.

金山雖然是免費軟體, 但掃毒能力不錯. 缺點之一是容易誤報病毒, 往往報出一些不是病毒的東西. 第二個缺點算是重大缺點. 它竟然把 Adobe Reader 給殺了! 感覺蘋果公司有投資金山的樣子, 怎麼跟 Adobe reader V10 有那麼大的仇恨? 所以我只好把金山毒霸給卸載啦!

[補充] 金山會要求把 "金山導航" 設為瀏覽器首頁, 一不小心同意了的話, 下次想改回來都會被當成 "惡意竄改首頁" 而改不成.

接著因為在 PCHOME  買了不少東西, 所以也得到熊貓 (Panda) Antivirus 的三個月試用序號. 這個軟體的缺點是禁止我的部落格被讀取. 呃…在我搞懂怎麼設定之前, 我也把它卸載了.  不過請大家記住那個試用序號只能安裝一次. 卸載之後就失效了. 

另外有個小雨傘 ( Avira) 防毒軟體. 我記得這個免費版軟體的缺點是不太防木馬網站. 此外它和 Windows 的 defender 相衝. 雖然 defender 很差, 不過別的軟體都沒有特別提到要去關 defender, 難道他們的技術是一樣的?

[補充] Avira 很愛打快顯廣告, 有時沒事就出來一篇阻礙視線. 不過拿人手短, 也就算了.

趨勢的 PC-cillin 雖然以前有聽過一些缺點, 但是我真正不喜歡的是有一年它促銷時, 順發店員說不用設定, 買兩年送三年. 等到兩年到了, 它就不讓我用啦! 雖然不知道該怪趨勢還是順發, 總之我也不再用趨勢的產品了.

大陸的瑞星我也用過, 不用錢, 看起來好像功能強大. 但是電腦怪怪的時候, 它好像沒有真的抓出什麼東西來讓我安心一下. 而且它的家族發展愈來愈大, 慢慢看不懂安裝哪些叫做剛好? 久了也就不想用了.

最後附帶一提, 兩套防毒軟體共存是可行的. 除了少數軟體不相容之外, 大部分都證實能夠相容.