傻的願意相信

March 12 16:33~18:02

Teddy 當年還在唸書的時候當過兩年研究所 OOAD （物件導向分析語設計）課程的助教，其中一項最主要的工作就是 review 學生的作業。老師一共用過兩本教科書，分別是 Craig Larman 所寫得 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process （好長的書名）以及 Michael Blaha 和 James Rumbaugh 所寫的 Object-Oriented Modeling and Design with UML。每年的作業都很相似，基本上讓學生自己選一個題目（自行決定 1 人 1 組或是 2-3 人1 組），題目也可以自己決定（找不到題目的人可以跟老師索取參考題目），內容大小以能夠在一學期完成 2 - 4 個 use cases 為限。雖然這門課叫做 OOAD，可是每一位修課的學生不是只有寫寫 use cases，畫畫 UML diagrams 而已，而是包含 coding 和 testing，最後把系統做出來（套用『吃掉你自己的狗食』這個原理，自己的設計自己實做出來才會知道自己設計的有多爛...XD），所以修這門課還滿花時間的。

由於題目是學生自己挑的，因此助教在改作業時就有點辛苦了，因為：

• 要先弄懂學生所挑題目的那個 domain 
• 要看學生寫的不清不楚的 use cases 然後還要告訴他們為什麼這樣寫不好
• Conceptual model 和 design model 也要幫忙看

作業改到後來感覺好像是助教在幫學生做題目...XD...基本上就只有 coding 和 testing 的細節比較沒關注到，其他關於需求分析與系統設計的內容 Teddy 在自己能力範圍內算是盡心盡力幫忙 review 了。有時候還會讓學生們覺的這個學長（就是 Teddy）太『雞蛋裡挑骨頭了吧』，設計本來不就是『這樣也可能，那樣也行』嗎，反正最後我程式寫得出來，軟體可以跑就好了，學長你幹麼管那麼多？

說實話當年 Teddy 內心覺的這些『刁民』真是不知好歹，能找到 Teddy 來幫你們 review  算是你們上輩子燒好香，居然還敢有『悖逆之心』，不好好給我回去重寫作業還在這裡做垂死的掙扎，希望 Teddy 被你們說服....（Teddy 內心獨白：等你們練成了絕地武士的催眠功夫再說吧）

其實基本上這門課的作業其實滿簡單的：

• 寫出 problem statement 並畫出 context diagram
• 畫出 use case diagram 並寫出 use cases
• 畫出系統架構圖
• 畫出 Conceptual diagram showing concepts with association and
  attributes
• 畫出 System sequence diagram 並寫出 contracts
• 畫出 Design class diagram with associations
• 說明一個設計中最重要的 class
• 列出 test cases 並說明其中一個最重要的 test method
• 程式畫面

分四次把上面所列的這些東西在最後學期結束時都學會了，也就及格了。很多學生其實不太能夠適應，或者是說『不相信這一套方法可以 work』，總是有些『自認聰明』的人，覺的自己對於開發軟體『很有經驗』，不必拘泥於書上所講得方法。但是也就是因為如此，這些人很有可能修完課之後，還是對於所謂『OOAD 』方法不了解。

 ***

對於『OOAD 』方法不了解有什麼大不了的，還不是活得好好地。沒錯，說實話 Teddy 現在開發軟體也沒有按照書本中所描述的步驟一步一步慢慢來，但是由於 Teddy 曾經用力花時間去了解這套方法，因此當遇到自己不熟悉的領域，無法靠『直覺』來設計系統的時候，這些在 OOAD 課程所學到的方法就變成一種『參考模式』，用來解決不熟悉問題的參考模式。

Teddy 的指導教授在課堂上常常告訴學生要『傻的願意相信』書上教的方法，自己要先『願意相信』這是可以 work 的方法，嘗試照著去做，而不要在學會之前就先急著去否定這些方法。聽起來好像很簡單，但是要咱們『聰明的台灣人』傻傻的一步一步按照規矩辦事，說真的還真是不太容易。

回到 Teddy 上一篇的主題 『Ten-Minute Build 』，如果今天 Teddy 跑去跟別人講，你的專案要達到 Ten-Minute Build 的要求喔，Teddy 可能會被當作瘋子，因為根本沒人相信。對方可能會說，哎喲，這都是『書本上的說法啦』，你們不懂業界的實況，所以.........

不知道為什麼，Teddy 對於某些人所講的話就特別相信，Kent Beck 就是其中一位，因此當 Teddy 遇到『build 時間太長』這個問題時，就到書上看看 Kent Beck 怎麼說，嗯，他說『Ten-Minute Build 』，Teddy 就先『姑且信之』，於是 Teddy 開始思考一連串所謂的『流程改善』，包括了：

• 更新 build server。
• 挑選現有可快速執行的 test cases。
• 讓 test cases 執行的更快。
• 想辦法找出此次異動的程式，並只執行受影響的 test cases。
• .......（其他）

總之這個『Ten-Minute Build 』就是努力的目標就對了，如果繼續抱持著『不相信』的心態，那麼就只會一直維持現狀。基本上 Teddy 所知道的軟體工程知識應該不會比任何一個資工科系畢業的研究生要多太多，很多都是修完軟體工程這門課之後就有的常識，但是 Teddy 『傻的願意相信』的決心可能比很多鄉民要來的強，也許就是這一點小小的信仰驅動著 Teddy 把『理論』慢慢變成『食物 實務』。

 ***

鄉民們可能三不五時會聽到什麼 agile methods，scrum，continuous integration，pair programming，automatic acceptance testing，incremental design，shared code 等等一堆有的沒的名詞，如果真的把它們當成『名詞』，那就真的與你無緣。如果把這些當成『動詞』，也許多多少少能『撈到一些好處』。

想當年 Teddy 聽到 GOMS （請參考 歪批 GOMS (1) ）這個作法，第一時間也是覺的『這麼扯的方法怎麼可能用在真實世界的軟體專案？』，但是一旦花點時間去了解之後，身邊又多了一把『小扁鑽』可以使用，偶爾拿出來應付一些特殊場合還是不錯用滴。

 ***

友藏內心獨白：這可能就是日本地震後隆起的柏油路居然比台灣的道路還要平坦的原因...XD...每次想到路平專案 Teddy 就想笑...苦笑...