有駕照不會開車

May 31 20:18~23:30

Teddy 是一個頭腦簡單，四肢不發達的人。距離感，方向感，還有手腳的反應很差，從小到大唯一學會的交通工具，就是騎腳踏車，而且還只能在河濱公園騎，不能騎到大馬路上，否則是很危險滴（路人危險，Teddy 也危險）。前一陣子在某人一再的逼迫之下，Teddy 不得已只好以近  XX 歲的『高齡』在五月初繳了 1 萬元去報名了駕訓班（其實是 1萬1千，因為上了一次課之後多交了 1 千塊參加了所謂的『路考保證班』...XD），昨天是筆試的日子，今天是路考，終於在 5 月的最後一天考上最簡單的自排車駕照。

到駕訓班上課之前一直聽說很多人考取駕照之後還是不會開車（不敢開車上路），Teddy 就覺得很納悶，不是都考到駕照了嗎，怎麼會不敢開車上路？等到 Teddy 親自去上課之後才發現，切，這那是學開車啊，簡直是『李棠華特技團』訓練班嘛（老一輩的人才懂...XD）！開車搞得好像以前上電子實習課的時候，在麵包板上面接電路一樣，『按圖施工，保證成功』。

每輛教練車都用立可白或與磁鐵在某些位置做上『記號』，請容許 Teddy 把整個過程做個抽象化的描述（做軟體的人就是喜歡 abstraction...XD）：在駕訓班學開車就是要學會如何利用這些『記號』與場地中的『固定參考點（可能是標竿，安全島，地上的黃線交叉點...）』的相對位置達到某種關係（某個角度）的時候，把『方向盤往左或是往右轉若干圈』。就這樣，敢問把車子真正開到路上的時候，到哪裡去找這些『參考點』，所以，按照這種訓練方式拿到駕照會開車應該算是天才了。

Teddy 也曾經想要試著按照自己的意思憑直覺隨便亂開，但是只要一沒開好被教練看到，就會 X@!#!@$... 總之教練只管你有沒有拿到牌，不太在意你會不會開車。

Teddy 在練車的時候，練著練著腦中突然浮現當年去資X會上 CMMI 課程時的光景（學費貴死人...還好是善心人士買單...XD）。在上 CMMI 課程之前，Teddy 自認為算是滿懂軟體開發這檔子事，上完課之後，Teddy 突然覺的不知道要如何開發軟體了，如果鄉民們知道『邯鄲學步』這句成語，那麼就可以體會 Teddy 當時的心情。

***

類似『A name without quality （拿到某某牌卻不會辦事）』的例子實在是太多了，拿最近最熱門的『塑化劑』來講，不是有某位議員的太太，買了某 ISO 認證的健康食品，以為有 ISO 認證就有保障，實在是大錯特錯啊。ISO 認證這檔子事本身已經搞成一種『產業』了，至於品質提昇多少，就不容 Teddy 在此多做介紹了。

話說回來，台灣人真是太厲害了，只要有人敢『發牌』或『發照』，咱們台灣人就可以想出一套超級有效率又保證成功的方法來讓『有心人』可以拿到這些牌，照（真是皇天不負 苦 有心人啊...XD）。更強的是，在很多情況下 輔導的人  教你的人就是負責評鑑你的人。這樣的模式，要拿不到這些牌，照的人才算是異類阿（大概比在台灣考不上大學還要難...XD）。

***

話說 Teddy 拿到駕照之後還要再準備花一筆錢去找教練教『如何開車上路』，這種『兩階段學開車』的方式，還真是『台灣經濟奇蹟幕後的無名英雄』啊，真是忍不住想給它一個『讚』。

Teddy 曾經問過某位幫人家導入 CMMI 的顧問一個很直接的問題：

Teddy：我聽過若干 programmers 說，導入 CMMI 都在做文件，做假資料，都是老闆想要拿牌，對軟體開發沒有很大的幫助。請問以您的經驗，導入 CMMI 真的對於開發軟體有幫助嗎 ？

CMMI 顧問：也不能說完全沒有幫助，畢竟經過導入的過程，每家公司還是都學到了一些東西。

顧問不虧是顧問，回答的真好。

***

場景換到駕訓班。

Teddy：我聽過很多人說，到駕訓班學開車，拿到駕照之後還是不敢上路。請問以您的經驗，到駕訓班學開車真的有幫助嗎 ？

教練：也不能說完全沒有幫助，畢竟經過練車的過程，每個學員還是都學到了一些東西。

是啊，反正只要弄清楚，到駕訓班學開車的目的是『拿到駕照』，不是學會開車，這樣就 OK 了（這句話聽起來怎麼怪怪滴...XD）。鄉民們有看到最近電視上狂播的那個『沒有』的廣告嗎？

又『沒有』人叫你去學...XD

***

友藏內心獨白：有些事，還是趁年輕去做比較好。

Checked or unchecked exceptions (1)

May 30 20:46~22:12

Java 語言將 exceptions 分成兩種：checked exceptions and unchecked exceptions（備註：unchecked exceptions 又稱為 runtime exceptions）。 鄉民們可能會對這兩個分類的命名覺的有點奇怪，為什麼要叫做 checked, unchecked？簡單的說， checked or unchecked 是從 Java compiler 的角度來看 exceptions，如果你有一個 method M 長成下面這個樣子：

public void M() {

  throw mew MyException();

}

從上面這段 source code 中，鄉民們可以看到 M() 會丟出 MyException 這個例外，如果 MyException 是屬於 checked exceptions 這個分類，那麼 Java compiler 會很雞婆的幫鄉民們『檢查』下面這件事：

如果 M() 沒有去『捕捉』MyException，那麼 MyException 就一定要被『宣告』在 M() 的 signature 中。

以上就是所謂的 handle-or-declare rule，如果 MyException 是一個 checked exception，上面這的程式要改成下面這樣子才可以被 Java compiler 成功編譯。

// 符合 handle 的要求
public void M() {

 try {

      throw mew MyException();

 }
  catch (MyException e) {

     // do something
  }

}

或


// 符合 declare 的要求
public void M() throws MyException{

  throw mew MyException();

}
 
在程式中如果有人丟出 checked exceptions 這種分類的例外，Java compiler 會去檢查 handle-or-declare rule 有沒有被遵守，如果沒有，就視為『語法錯誤』，程式是無法編譯成功的。對於 unchecked exceptions 這種分類的例外，Java compiler 是不會鳥他的，隨便鄉民們愛怎麼丟，就怎麼丟。

***

現在問題來了，Java 吃飽沒事幹為什麼要把 exceptions 分成這兩種類型，然後又要求 Java compiler 去『檢查』當鄉民們使用 checked exceptions 時有沒有『乖乖的遵守交通規則』？講到這邊又是一言難盡，請參考這本書 Effective Java, 2nd, Chapter 9: Exceptions. Teddy 把這一章的內容列出來給鄉民們參考一下，答案就在 Item 58 之中：

• Item 57: Use exceptions only for exceptional conditions.
• Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors.
• Item 59: Avoid unnecessary use of checked exceptions.
• Favor the use of standard exceptions.
• Throw exceptions appropriate to the abstraction.
• Document all exceptions thrown by each method.
• Include failure-capture information in detail messages.
• Strive for failure atomicity.
• Don't ignore exception.

Java 是第一個採用 checked exceptions 而且被廣泛使用的程式語言（以前都只有 unchecked exceptions），Java 的設計者認為，unchecked exceptions 很容易被 programmers 給忽略，導致例外沒有被處理而降低的系統的強健度（robustness）。所以就在 Java 語言中提出了 checked exceptions 這種分類並且讓 compiler 幫  programmers 去檢查，如果程式中發生  checked exceptions 的話，那麼一定要提高警覺，要給這個 checked exceptions『關愛的眼神』，千萬不要不理它啊（最基本的門檻就是程式碼要符合 handle-or-declare rule）。

此外，Java 設計者還給 checked 和  unchecked exceptions 附加了不同的『語意』，也就是上面 item 58 所說的：

• Checked exceptions for recoverable conditions.
• Runtime (unchecked) exceptions for programming errors.

上面這兩點非常重要，在 Java 程式中做例外處理，不是只會寫程式就好了，還要和 Java 設計者『心心相印』。Java 的設計者認為，checked exceptions 本質上代表著一種『可以被修復的例外狀況』，因此，當鄉民們遇到 checked exceptions，『理當』去 handle 它，為什麼？因為既然 checked exceptions 代表『recoverable conditions』，那麼就想辦法去 recover 啊（東西壞掉總不能不修理就直接丟掉換新的吧...XD）。

Unchecked exceptions 則表示 programming errors，翻成白話文就是說如果鄉民們遇到一個 unchecked exceptions 則表示程式中有 bug。那麼 unchecked exceptions 要如何『處理（handle）』呢？

把上面這個問題換成這個問句答案就很清楚了：程式有 bugs  要如何處理？答案很簡單啊，有  bugs 就改程式把 bugs 修掉啊。對，所以，unchecked exceptions 『理論上不應該在程式中去 handle 它』，因為它代表 bugs，所以當 unchecked exceptions 發生時只要在 main method 中 catch 並且 report 給 end-users or programmers 便可。
 

***

Checked or unchecked exceptions 的故事還很長，雖然 Java 的設計者希望鄉民們能夠瞭他們的想法，但是也有很多人是不買帳的。理想歸理想，實際上寫程式的時候會遇到以下問題：

• 雖說 checked exceptions for recoverable conditions，但是為什麼偏偏當程式中遇到一個 checked exception 的時候鄉民們卻打死也不知道要如何去 recover 任何東東？舉個最常見的 checked exception， IOException，為例，處理檔案，stream，socket 都會『附贈』IOException，收到這份大禮之後該怎麼辦？沒人知道。
• 既然 checked exceptions 要符合 handle-or-declare rule，但是鄉民們既不知道如何 handle，也不明白如何 declare。Exceptions 這麼多，怎麼處理？那就亂處理啊！所以程式中經常可以看到 catch and ignore （exceptions 被捕捉且被忽略）或是 blindly declare （盲目地將所有發生的 checked exceptions 都宣告在 method 上面繼續往外丟）。
• Checked exceptions 要宣告在 method 的 signature 上，所以如果一個  method 會丟出去的 checked exceptions 數目或是 type 改變了，那個這個 method 的 signature 也變了，就等於 interface 也變了。改變介面這件事可不是好玩滴...
• 有些鄉民們『不遵教化』，打死都不想用 checked exceptions。問題是這些鄉民們又沒事寫出很多很好用的 open source 軟體，那麼當我們使用這些軟體的時候，就開始『神經錯亂』了。原本 Java 告訴大家，unchecked exceptions 代表 bugs，不用去 handle，但是不甩這一套的人只用 unchecked exceptions，也就是說這些人也用 unchecked exceptions 來代表 recoverable conditions 與 programming errors。那那那.......『民安手措其手足』？

Checked or unchecked exceptions 第一集講完，預知結果請看下回分曉。

 ***

友藏內心獨白：留言說例外處理很難搞的這位『匿名 』人士，你沒看 Teddy 的這篇 paper 喔：Exception Handling Refactorings: Directed by Goals and Driven by Bug Fixing 。

Exception Handling 必看 paper (1)

May 27 20:48~21:46

五月很忙，沒什麼時間搞笑，今天來介紹一篇 exception handling 的 paper，如果鄉民們想要深入研究或是了解 exception handling 的理論背景以便設計出好的例外處理程式，或是想要在不懂的人面前唬爛一番（就好像 Teddy 接下來要做的事情一樣...XD ），那麼這篇是值得一看的 paper。

相信只要是有在寫程式的鄉民們都會認同：例外處理是一件很困難的事情。為什麼？

• 學校沒教：有誰在學校有學過如何設計出好的例外處理程式？大概就是在程式設計課程（例如 C++ 或 Java）的時候稍微提一下 exception 的概念，教一下 try, catch, finally, throw, throws 這幾個 keywords 的意義。如果還有時間的話，頂多再介紹一下 checked exception 與 unchecked exception 的差別。
• 工作學不到：上班之後，光是忙著寫『正常功能』都來不及了，那還有時間去關注例外處理的問題？
• 書上也沒寫：更慘的是，對於『有理想，有 報復 抱負』的鄉民們，就算是想要買本書來自修一下，也很難找到一本像樣的書介紹如何做例外處理設計。

就連跟著 Teddy 學了快兩年的學弟，到現在快畢業了也還是處於一知半解的狀況（路人甲內心獨白：是 Teddy 不會教吧！）。嗯嗯...想當年 Teddy 也是花了好一番功夫才學得這方面的一點皮毛，就利用這一系列的文章把當年看過幾篇關於 exception handling 方面的超優良 papers 介紹給鄉民『聞香』一下。今天先介紹『年資』最老的這一篇。
 
Exception Handling: Issues and a Proposed Notation, by John B. Goodenough, CACM, vol. 18, no. 12, Dec. 1975, pp. 683-696.

哇賽，這篇 30 幾年前的 paper 會不會過時了啊，還需要看嗎？雖然時間有點久遠，但是看完之後對於 exception 的定義以及 exception handling 的基礎概念會有很深入的了解。更棒的是，這篇 paper 可以在『這裡』下載，不必去訂閱什麼電子期刊才看的到。這一點對於已經出社會的鄉民們算是滿方便的（在台灣應該很少有公司會去訂 IEEE 或是 ACM 的電子期刊吧...）。

這篇 paper 有很多重點，在這邊講一個關於 『exception 用途 』的重點。什麼叫做『exception 用途』？就是說，在程式中我們會把 exception 拿來幹嗎。這問題不是很好笑嗎，exception 就是拿來代表『例外狀況』啊？No..No..No.. 並不全然如此，而且這樣的解釋有點『英翻中』的感覺，並沒有真正說明 exception 在程式語言中的用途。Exception 的用途可以分成三大類（別忘了，這些做研究的人最喜歡分類了...XD），failure, result classification 與 monitoring。

Failure：
某個 method 或 function 無法達到其規格中所定義需要提供給客戶端（caller）的服務時，所丟出的例外。也就是說，如果一個 exception 代表著 failure 的含意，那麼就表示丟出這個 exception 的『人（method）』無法達成其被賦予的任務（講成白話文就是『小的辦事不力』...XD）。絕大多數的 exception 都是用來表示 failure，例如 Java 中的 IOException 與 NullPointerException。
 
Result classification：
用來表示 the type of result being produced。意思是說，這樣的 exception 其實不是代表『錯誤發生』，而是類似『狀態變數』一樣，用來表示傳回值的種類（如何解讀這個傳回值的意義）。在原文中對於這一點著墨不多，以下為 Teddy 自行揣測的例子，如有錯誤請來函更正...XD。例如 Java 語言的 EOFException，依據 Java 文件的說明是用來表示『an end of file or end of stream has been reached unexpectedly during input』。當遇到 EOFException 的時候就表示檔案已經讀完了，剛剛讀出來的資料都是正確的，並不需要做什麼『例外處理』。此時只要把開啟的檔案關閉便可。

Monitoring：
用來通知 caller 某種狀態發生了，直接看原文的說明比較快。

The invoker wants to be notified when some condition occurs. This is not because the condition indicates a failure or the type of result being produced. Rather it is because he simply wants to keep track of the computation's progress, or the operation may need additional information at certain points and it is too expensive to calculate this information every time the operation is invoked, sicne the conditions under which it is needed occur only rarely.

好，看不懂，沒關係，舉的例子。Java 的 InterruptedException 就是一種屬於 monitoring 這一類，看一下 Java 文件關於 InterruptedException 的說明：

Thrown when a thread is waiting, sleeping, or otherwise paused for a long time and another thread interrupts it using the interrupt method in class Thread.

InterruptedException 是要讓 caller (new 出該 thread 的人) 當該 thread 被『中斷』的時候能夠收到通知。為什麼要收到『thread 被中斷的通知』？因為如果某個 thread 睡了很久沒有醒過來（例如執行 wait, join 或是 sleep），但是你的主程式要準備結束了（或是想把沉睡的 小五郎 thread 喚醒請他走人），可是問題是你在主程式所 create 出來的 thread 還在睡覺啊，要如何喚醒他？此時可以呼叫 thread 的 interrupt method 來喚醒他，這樣，例如原本呼叫該 thread.sleep 的那個人就會收到一個 InterruptedException 。

Monitoring 這一類的使用方法在現在的程式語言中也很少了，當收到一個這種類型的 exception 時，caller 通常會選擇 terminate （離開閃人）或是 resume（繼續執行）。至於到底是要 terminate 或是 resume 就要看當時的狀況來決定。

***

講了這麼多，到底講對講錯 Teddy 都快搞迷糊了...XD。總之，基本上可以把 result classification 和 monitoring 的用法都視為是一種『notification』，所以 exception 的用法就可以簡化為 failure 與 notification 兩種。重點來了，一般所謂的 exception handling，指的是只有當 exception 是被當作  failure 的用法時，才需要考慮要如何來處理這個例外狀況。 如果 exception 是被當成 notification，由於實際上『並沒有錯誤發生』，所以沒有什麼錯誤要處理的。通常當 exception 是當作 notification （例如 EOFException 與 InterruptedException）使用的時候，都有固定的回應方法，此時只要用這些固定的方式來寫程式就好了。

好消息是，當作 notification 使用的情況並不多，Teddy 已經告訴鄉民們兩個 Java 的例子（EOFException 與 InterruptedException）。想當年 Teddy 還不懂這樣的觀念的時候，對於如何處理 InterruptedException 一直覺得很迷惑：明啊明是一個『例外』，但是卻什麼也沒處理，只要離開 thread 就好了。只要知道 InterruptedException 其實是把 exception 來拿當作 notification 使用這樣就不會覺的奇怪了。

壞消息是，絕絕絕大多數的 exception 都是當作 failure，既然是 failure，就表示有人辦事不力。既然有人辦事不力，就要 懲處 想辦法補救。至於如何補救，該由誰來補救，要怎樣才不會越補越大洞，這又是另一門學問了。講不完，有空再說。

***

友藏內心獨白：老 paper 也有春天...XD

還少一本書：Contributing to eclipse: Principles, Patterns, and Plug-ins

May 19 22:29~23:33

瞎忙了好幾的月，有好一陣子都沒時間靜下來好好讀本書，在可預見的下半年大概也好不到哪理去。沒讀新書就少了寫部落格的『料』，只好繼續把以前的『存款』拿出來花。找了一本以前唸書的時候所讀過的書，拿出來『微波 冷飯熱炒』一下也還不錯吃啦。

今天要炒的是 Contributing to eclipse: Principles, Patterns, and Plug-ins 這一本。有長期注意 Teddy 行蹤的鄉民們應該看過 Teddy 提到這本書好幾次了，前一陣子 Teddy 去參加 Scrum 經驗分享活動，也特別向圍觀的鄉民們推薦這一本書。尤其是想要成為 architect 的鄉民們，此書更是不可遺漏的秘笈。

雖然是 2003 年出版的『舊書』，但是這本書內容之豐富，絕對算是經典之作。先看一下作者是誰，哇賽... Erich Gamma and Kent Beck ... 兩位都是大師，就算看不懂內容，就衝著這兩位的名氣都應該要買一本回家供著。Teddy 敢大聲的說，要不是當年開發 Eclipse plug-ins 的經驗，再加上看過這本書，Teddy 的 architecture design 能力大概要少掉  1/3 ~ 1/2。

如果鄉民們恰巧有寫過 Eclipse plug-ins 的經驗，就應該可以體會到 Eclipse 設計偉大之處。幾乎所有的人都公認『整合』是一件很困難的事情，而 Eclipse 厲害之處，就是能夠把三教九流的 人 軟體全部給他整合到 Eclipse 平台之中。這樣的設計，趕快把他給偷...學過來，自用送禮兩相宜。日後無論是開發什麼軟體，都一輩子受用無窮。

講了這麼多廢話，到底這本書在講些什麼？以下是 Teddy 認為 Eclipse 幾個最基本也最重要的概念：

• Plug-ins, extension, and extension point.
• Menu and Action.
• Marker and Marker Resolution.
• Builder and Nature.
• View and Editor.
• Workspace and Resource
• Java Core

為什麼這些概念重要... 嗯... 這樣說好了，一般的應用程式都會有 GUI，學會了 Eclipse 的 Menu, Action, View, Editor 觀念，日後開發應用程式（無論是 desktop or web 應用程式 ）都有一定的幫助。

所有的應用程式都會有 model 這一層，學會 View 和 Editor，也就了解到 MVC 的概念，透過 data provider 提供資料給 UI 這一層來顯示。Marker 就好像『狗皮膏藥』一樣，讓你自己開發的 plug-ins 可以依據某些規則在 UI 上標記記號，用以提醒某種狀況。例如，在 Java Editor 中發生語法錯誤時貼一個小標籤在 Java Editor 左方。而 Marker Resolution 就是用來幫助使用者（自動或半自動）排除這些狀況的作法。

Builder 機制讓使用者（程式設計師）可以自行開發並外掛『處理資料的程式』。例如，你發明了一個超棒的演算法，可以找出 Java source code 的那一行會發生 bug，哪麼你就可以自己寫一個 Builder，掛到 Eclipse 裡面，當使用者存檔的時候，讓 Eclipse 自動呼叫你所寫的 Builder 去分析與處理 Java source code。如果你的 Builder 有支援 Marker 的功能，就可以自動貼一個 marker 在可能出問題的那一行上面。至於 Nature 的功能是用來幫專案貼上某種標籤，如此 Eclipse 才會知道，當不同的專案被開啟的時候，要呼叫哪些 Builders。例如，如果你的專案具有 Java 的 Nature，Eclipse 就不會去呼叫 CDT。

更棒的是，Eclipse 不只是設計來支援 Java 程式開發，只要針對不同的 Resource 建構自己的 AST (Abstract Syntax Tree)，就可以在 Eclipse 上提供一個類似 Java 的開發環境。根據 Teddy 所知，有些 IC 設計公司，除了提供自己的 IC （硬體）之外，也在 Eclipse 上開發自己的 compiler ，editor 與 debugger，讓客戶可以有一個好用的整合環境來開發特殊的程式。

***

寫到這裡可能會有鄉民說，我們公司又不是要賣開發工具，學 Eclipse 有什麼用？其實 Eclipse 架構可以讓開發者做很多事，不是只能用來開發『開發工具』（這句有點饒口）。有興趣的人可以去看一下 Eclipse RCP (Rich Client Platform)。

最後提醒一下，建議先學好 design patterns 之後再來看這本書，不然可能會不太容易懂。最好能邊看邊些一些簡單的 Eclipse Plug-ins 來當作練習，以收事半功倍之效。

***

友藏內心獨白：學弟們，你們說學長講得對不對啊？

沒藥醫

May 17 22:35~23:30

Teddy 的第一份工作是在一家只有 10 來人的純軟體小公司開發軟體，由於 Teddy 原本是念電子的，因此剛出社會對於軟體工程的知識所知有限，所以當時遇到的軟體開發問題，主要分成三大類：

• 需求問題：如何從顧客身上『撿到』可用的需求，用何種格式撰寫需求，如何訂定需求的優先順序，如何將需求順利的轉變成軟體。
• 技術問題：JDBC 要怎麼用，Java Applet 要怎麼寫，Web applications 要如何開發，要如何用 javascript 寫動態與互動式網頁，要如何透過 web cam擷取影像，exceptions 要如何處理，design patterns 要如何套用，軟體架構要怎麼設計等等隨便都可以再列個幾百個項目。
• 流程與專案管理問題：當軟體開發團隊逐漸成型之後，如何讓團隊運行順暢的共同開發軟體就變成一個重要且必須面對的課題，否則軟體開發只會事倍功半。

在這邊 Teddy 要考考鄉民們，以上三個問題，那一個最重要？

都很重要...廢話...嗯嗯...如果從 programmers 的角度來看，可能會認為技術問題最重要，因為技術問題沒有解決軟體就做不出來。從 PM （專案經理）的角度來看，可能會認為流程與專案管理最重要，因為不管用哪種技術去實做，反正東西給我生出來就對了。

等一下... 那...難道需求不重要？或是換個方式問，誰會覺的需求最重要？

答案很簡單，當然是客戶，因為『理論上』他們是最後要使用軟體的人（有些軟體做出來之後其實沒有人用...所以，只能說『理論上』客戶是最後會使用軟體的人）。如果做出來的不是他們要的，那麼時間與金錢就浪費了。
 

***

問題來了，如果你是開發公司的『產品』，還沒有真正的客戶，那麼在公司『高層』的豐富想像力之下，某種『極端』卻又『很常見』的問題就會發生，那就是軟體需求最後變成包山包海，亂七八糟的大怪獸，東西做好也賣不出去，大家白忙一場。

N 年後的今天，自我感覺良好的 Teddy 軟體工程的功力已經變得很強了。以 Scrum 為例，在 Scrum 的框架之下，技術，流程，與專案管理的問題都還有的救。但是，Teddy 要告訴鄉民們一個大家老早都知道的事實：需求出問題就真的是沒藥醫。

會想到開發類似『咖啡豆漿機』或是『雲端殺豬系統』的人，其聰明才智絕非常人能比，且其位高權重，不是『聖上』就是『親王』，『三朝元老』，『軍機大臣』等級的人，那一個你得罪的起？如果誰不長眼拆穿了『國王的新衣』，那麼下場可是......祝恐怖......。

如果有人想問：『在 Scrum 中如何解決需求並非客戶真正所需的問題？』 答案很簡單：

• 換掉 product owner ...... 背後的黑手....可能是『聖上』，『親王』，『三朝元老』，『軍機大臣』。
• 換工作。

第二點可能會比較快...不過，誰能保證『下一個老闆一定   會更好』（這一句要用唱的）。

***

友藏內心獨白：拜託，就算軟體架構設計的好，也不是這樣讓你拿來隨便亂加需求滴。

改行寫網路小說算了 (3)

May 16 20:16~20:56
 
話說『卡歪美食公司』準備推出了一款新的巧克力蛋糕，取名為『甜可麗』。在某次公司會議中...

老闆：這個『甜可麗』是公司近年來最重要的產品，為了確保客戶會喜歡，在推出之前要先找幾個客戶來 試用 試吃一下。

行銷主管：皇上聖明，奴才立刻去辦。

***

兩個月後，行銷主管寫了封 email：

各位同仁,

以下是客戶們試吃『甜可麗』之後的 feedbacks：

• 好想來杯咖啡。
• 好想吃鹹的。
• 吃完蛋糕之後應該要刷牙。
• 我想你們的『甜可麗』不適合我們，因為『甜可麗』的原料沒有採用台灣本土生產的小麥。
• 吃『甜可麗』的時候很容易掉屑屑，不小心會弄髒衣服。

***

兩個月零 1 天後...

老闆：上次開會讓你們找客戶試吃『甜可麗』，結果怎麼樣啊？

行銷主管：啟奏聖上，經過我們大規模的調查後發現：

• 吃完『甜可麗』之後有 49.999% 的人會想要來杯咖啡，所以『甜可麗』要 增加咖啡的功能.....嗯嗯... 應該搭配咖啡一起賣，可以提高營業額。
• 有 68.888% 的人在吃完『甜可麗』之後會想吃鹹的，所以如果我們能夠增加產品內容，順便賣茶葉蛋的話，應該會不錯...這個量很大喔。
•  26.66% 的人吃完『甜可麗』之後會立刻刷牙，我們可以批一些牙膏，牙刷來賣，或是在現場提供『牙刷出租服務』，讓顧客吃完之後可以立即享受五星級的刷牙服務。好吃又健康，讚的啦！
• 有 0.000001% 顧客建議我們採用台灣本土生產的小麥來製作『甜可麗』，如可方可證明我們是一家『愛台灣』的本土企業。因此為了提昇『甜可麗』的銷售量與公司的企業形象，我們應該成立『卡歪精緻農業公司』，立即著手將台灣休耕的農地拿來種植小麥。
• 最後一點，大家都知道吃蛋糕的時候一不小心很容易弄髒衣服，為了提供客戶一個 total solution，我們可以和乾洗業者合作，凡是因為吃『甜可麗』弄髒衣服而需要送洗者，都可以免費獲得一張打 5 折的乾洗折價券。

老闆：嗯，聽起來很不錯。所奏照准。這件事行銷主管辦得不錯，賞黃馬褂一件，另外加封太子太保閒銜，上書房行走。

行銷主管：謝萬歲。

老闆：退朝。

***

九品芝麻官：調查了老半天，到底『甜可麗』好不好吃還是沒人知道？

***

友藏內心獨白：國王的新衣還真的有人可以看的見耶，佩服，佩服。