Tuesday, February 14, 2012

Love it, and Hug it.


iWoz Computer Geek to Cult Icon :
How I invented the personal computer,co-founded Apple, and had fun doing it
    1. 在HP工作時期,利用下班時間做出了Apple-I
      • 不要吵自已沒有時間做自已熱情的研發,
      • 若是真沒有時間
        • 做跟自已熱情相符的合作
        • 不要去會把員工每一分的精力吃乾抹淨且無時無刻不能讓自已盡情快樂發揮的公司,
        • "Boring Money" Or "Life for Fun" ,Choose One?
    2. 引自書中內容
      • 如果你熱愛目前的發明工作,而且也願意竭盡所能,那成功指日可待
      • 你在夜晚獨工作的分分秒秒,你花在反覆思考你的發明的時時刻,最後都會變的非常值得. 我(Steve Wozniak)敢保證,你終究會覺得很值得
    3. 即使是IT發明奇才如iWoz 也深明一次只跨一步的必要耐性
      • 要走的快,絕對不是省去步驟,妄想一步一登天
      • 要走的快 ,是要依靠長時努力打下的基本功, 讓自已健步如飛

加油! 有夢就去追。 沒有時間悲傷

Sunday, February 12, 2012

按合約設計 DBC (No.21 Design By Contract)



















Design By Contract.
一種思維,caller callee間,協同合作的技術方法。
最近遇到了合作的module傳來不明參數的問題,令我好奇 這件事情是該誰來第一手檢查?
1. Caller? Callee?
2. 底層傳給上層/上層call底層?
而這節給出了一條指引的看法。 先說其立場是: "Caller".  Why?

一。什麼是DBC?
照合約來設計:  A.我的責任權益。B.對方的責任權益。C.任何一方沒守約定的後果。
"溝通,你要做什麼 我要做什麼,誰沒做到就把誰扁到地上。"
組成:
          文檔(合約): 可以是任何型式(comment/html/pdf/ascii/tatoo...etc),但一定要有,且要是那種有人看的。且是之後文件的重要參考依據。
          Precondition: 使用Callee前,需成立的條件。若不成立: 則callee不該被調用。(重申:此為 Caller的責任)
          Postcondition: Callee 保證會做的事情, 完成後的狀態。(Postcondition這件事,暗示其會有結束:不會有infinity loop.)
         Class invariant: 由Caller來看,其為總是為 TRUE的條件。即使在Callee執行過程中有會有變化,但返回時注意 需為 TRUE。(Class開放功能時,小心勿無上限的對其相關數據,開放public write.)

二。實務上的討論
整件事情,是由討論而來訂下的條約。而且會隨著時間有做出彈性修正的可能。
現實情境:
常看到的是往往是在callee會有先檢查相關引數的code…因為常常死在callee家,其是第一個案發現場,而caller 隨著回報的問題,發下來的command不對,格式不符...etc。時間的經過,而caller又自已在進callee前再檢查了一次。
最後版本release…了 也沒說要拿掉某一方,因此同樣的事情,很奇妙的在exec順序緊接的情況下,重覆做了…一樣的動作。而且還有二份很像的code.....

這是不是哪裡不太對勁呢?
debgu時也許有必要…但不能一開始就做對嗎?  
目標是把事情做對而不在究責!  雙方都有責任!
1。在那裡先檢查? 開始前caller確認自已傳的沒錯-caller本身要知道自已最後做了什麼事,Precondition check -否則就是在靠巧合寫code。能動就好 看起來好像沒事。
2。預期結束時 callee會做當時談好的事。 Postcondition check! 否則callee也要知道自已在幹麻 做出了什麼事。 知道 是不夠的! 檢查它。
3。 整件事做完,什麼事情是不會變的。 可借由pre/post condition時作 or 另埋伏點。
結論:
可以看出 合約文檔是重點! ,照著合約傳(caller)  照著合約做該做的事(callee), 照著合約遵守不該動的事(class invariant)。

三。
值得一提的是:
Feedback 是重點。要有合約 就需要討論。 需要修正,需feedback,需要Iteration。


在內部開發協同合作方面,記得DBC精神 有助於讓雙方進行多層次的週詳討論,搜集feedback。及合作模式順暢。避免之後的bug增長率。


像API設計, 就可能不太適合採納太多合約的精神,因為往往是內部自已訂完就給外部的人(廣大的客戶…)使用。
java的文件雖很完備,但api及其 wrapper ,還是有很多的容錯機制及檢查。
1。是系統穩定度考量
2。是使用者 並沒有參加什麼開發的過程。 最後攤出來的是一堆寫好的東西。使用者尚未融入情境脫離初學者成為pro級之前,不能令其覺得不好使用。使用者經驗不佳。
這可能談的有點離題了 。API設計本身就是件很大層面的探討。

四。相關資源
GNU NANA  (這我有學,想討論的人可以揪我。)
Eiffel language
Java IContract

五。後話

合約只是種思維,學到之後,就幫自已的火藥庫增加一項武器。
打怪不一定都要拿這發出來打。
軟體工程如此多面向,若是有套放諸四海皆準的模式。
早就有銀彈了。大家過著幸福美滿的日子