讀書心得備存一

重貼一些救回來的讀書心得。
宛如飛翔的後記
由Joel的.NET文章談起
SDT Validation White Paper

宛如飛翔的後記 2006/02/06
終於把這十冊書看完了，到後面幾本太瑣碎的細節已不細看。第十冊的最後兩章分別敘述西鄉隆盛以及對頭兼好友的大久保利通的結束，看完不勝唏噓。不過看完後記思緒又被帶到不同的方向：

「日本的統治機構應該叫做政府還是稱為『官』在語感上才會比較接近本質呢。這十五、六年來，我一點一滴的一直在思考這個問題。當它在我心頭占領的面積愈來愈大時，我萌生了要寫<宛如飛翔>這部書的念頭。」

接下去敘述太政官(算是維新後的政府嗎？)的源由與背景。

「大久保利通就是這些『官』的代表。他對自己這些官員成立時所遭遇的困難睜一隻眼閉一隻眼，把這個絕對的權力當作文明開化的巨大推動體，以我們是劃時代的推動者來鼓舞官員，並將整件事扣上正義的大帽子，以提高官僚們的士氣，企圖讓他們忘記對鄉黨的虧欠感。」

最後的結論：「更進一步來說，大正民主時代的政黨也好，戰後的政黨也罷，與其說是徹底的社會保謢者，毋寧說有一種以『官』的寄生集體形式存在著的性癖。這和明治十年之前形成的太政官國家的原始模式有著一定的關連......這些基礎，早在明治十年之前就已經成形了。」
=== 本文結束 ===

由Joel的.NET文章談起 2006/02/25
Joel on Software書裡有三篇關於.NET的文章，由於某些緣故把它們擺在一起，放在給顧問公司的電子報中介紹：

• 微軟瘋了：
  這是2000年.NET剛出來時寫的文章，內容激動且已過時。當時作者把.NET視作比泡沫軟體還低級的宣傳把戲，我是不懂.NET的，所以同不同意就看讀者自己了。


• 我們的.NET策略：
  時間是2002年，作者開始接受.NET並考慮轉移到這個平台。我覺得需要注意的是作者對轉移動作的考量：
  

  『我對.NET還沒有懂到能寫出好的程式碼。在任何開發環境中，要做某件事時通常都會有很多方法，而我們連第一種方法都還沒學會，更別提第二種方法了。所以我們寫出的.NET程式碼品質還沒有好的能當產品推出...第二個問題：肥大的20 MB CLR (runtime)...』



• 先生可以賞我一個連結程式嗎：
  時間來到2004年，顯然作者已經接受.NET但是不太能忍受單一個巨大的CLR作法。

其實挑.NET的文章出來是有特別意義的。有些人可能已經知道，三處的開發環境已經轉移到C#和.NET了，該部門剛出的線上遊戲就是用.NET開發的。會做這樣的決定有其原因，比如時程緊迫、工具生產力提升等等。不過我在這裡並不是要質疑或是讚揚這個決策，而是有其他想法。
技術人員在選擇平台時有兩種傾向，一種傾向維持原有的平台，而另一種傾向使用(通常)功能更強的新平台。一般而言，人員愈資深，在原平台投資愈久，愈會傾向不改變，因為改變代表風險。
誰知道新平台的華麗外衣下有多少隱藏的致命問題呢，人家才不會告訴你呢。我在前一家公司做數位相機七年用過六個平台，只有在把頭洗下去拼命做好幾個月之後，狀況緊急如火如荼時才發現可怕的問題。另外如Joel所說的，他當時自認用.NET還寫不出能作為商品的高品質程式。這表示選擇新平台有讓產品品質無法到達最佳的風險。

相對而言，通常會選擇新平台的多是對原平台投資不多的人員，在兩邊都不熟又沒有包袱的狀況下，當然選擇功能較強的新平台。何況學習最新最好事物的天性本來就潛藏在技術人員的心靈之中。另外破壞性的創新往往也是由這些冒險選擇新環境的人所發起的。

我不認為這兩種選擇有所謂對錯，它們分別都是不同條件下所能有的最佳策略。維持原平台能降低短期風險，但是不變是不可能長久的，所以雖然一邊抓著原平台不放，卻要時時注意觀察新的出路，萬一被時勢所逼也有後路可走，不致倉惶失措。投入新平台可能抓住機會但也帶來風險，而我最在意的是你有沒有考慮並控管風險呢？
=== 本文結束 ===

SDT Validation White Paper 2006/03/21
一套叫Unified TestPro的產品. 號稱第三代整合測試設計與自動化. 搞不清楚哪裡拿到的一個pdf檔, 現在google不到了.

第一代自動化: 非程式人員的測試者
記錄動作/重播動作, 產生腳本檔. 腳本不易維護, 受測程式更改後腳本通常就失效, 必須重新錄製

第二代自動化: 每個測試都是一隻程式
放棄記錄/重播的作法, 直接寫腳本程式並在設計時加入可維護性,錯誤偵測及回復邏輯等等.
測試人員必須擁有相當的軟體開發技能. 另外對GUI應用有效, 但不易擴充至線上,嵌入式,電信,批次等系統. 另外無法有效分離測試設計與測試腳本. 還有就是10000個測試就要寫10000個程式.

第三代自動化: 終於有效的自動化
在這一級的自動化學到3個重要課題.
1. 將測試設計視作與測試自動化獨立而整合的活動, 這樣才能將有技術的人指派到各個活動. 測試設計需要應用領域的知識與測試設計技巧, 但不需要程式能力. 這樣自動化時的人力就火不需要那麼多.
2. 不要再實作測試期間即時設計測試
3. 記錄/重播工具的真正威力在於操控視窗及物件的能力

第3代記錄/重播的應用關鍵在於測試碼的特性與數量,,特別是測試碼和測試案例間的關係. 前兩代的關係是一對一, 每個案例都有一個腳本, 所以腳本數很多難以維護. 第三代自動化用不同的方式讓單一的腳本可以處理各種測試案例.

或許現今測試自動化最重要的問題是: 測試社群要如何運用記錄/重播工具中強大的api處理引擎? 由測試觀點來看, 我們不禁要問測試案例應該在哪裡建立?

如果由下而上從測試工具的觀點來看, 似乎每個測試案例都應該獨立寫碼. 如果由上而下從測試者的觀點來看, 顯然測試案例應該以更高層的抽象來設計. 應該讓測試設計者由設計觀點寫成, 由不熟悉技術及實作細節的人審查. 最適合的工具不是原本的錄放工具, 而是試算表. 所以用試算表寫測試案例, 由錄/放工具來解譯執行

Unified TestPro包含測試規劃,設計,建立,執行,管理等層次,由不同角色用不同工具執行, 產生各種輸出.

沒力了, 寫到這裡就好.
=== 本文結束 ===