 《轉載》Reuse the Component (上) |       |
我記得小時候要寫數學作業時，如果遇到那種大家都解不出來的問題
時，通常會有一個高手會先把解法解出來，剩下的人再依樣畫葫蘆，
照著抄一遍。只要高手沒有寫錯，不會是每個人都錯同樣的地方，老
師通常不會發現。只是有些時候，有些人抄的時候，把過程給寫錯了
，卻可以算出正確的答案，就有可能會被老師逮到。
很多人把相同的觀念用到了軟體開發上，特別是在物件導向開發盛行
之後，很多人通常會希望在開發軟體時，應該有人先開發出一些可以
共用的物件，然後讓大家可以在不同的場合，不同的時機裡重複使用
(reuse)，經過這樣子產生的綜效，就可以減少重複的工作，並且加
速開發的流程，提高整個團隊的生產力。
這通常給程式開發人員一個很好的藉口，當他的進度落後時，他只要
把reuse放在口上，大部分的專案經理都會願意投資一些小小的時間
與資源，在進行這樣的工作上，特別是這樣有機會讓日後的生產力有
倍數的成長。
在某次整個開發團隊的status review meeting中，我們聽到這樣的
對話。
布魯斯(帶著質疑的表情)：強森，我從你的status report中可以看到
，你目前的進度正在落後。你這個禮拜正
在忙什麼？
強森(有點興奮) ：我這個禮拜正忙著設計跟開發一個可以共用的
component，所以花了不少時間。我想如果一切
順利的話，大概再兩個禮拜就可以完工。所以
整個進度大概目前會比目前的plan晚三個禮拜。
可是如果這個component寫的好的話，我們就可
以馬上發揮它的威力。如果每個人都用我新寫好
的這個comonent的話，我預估可以省下我們一
半的開發時間。我想如果沒有出大問題的話，應
該可以讓大家提早兩個月完成
布魯斯 ：Good job。(面對其他的人) 我常常說，要work
smart，不要work hard。你們要好好跟強森學習。
艾力克斯，你的進度怎麼樣？…
一個月後的status review meeting....
布魯斯(帶著沒有耐心的表情)：強森，你的那個共用的component現在進度怎
麼樣了？你不是說，兩個禮拜就寫完了嗎？
現在都已經一個月了。
強森 ：我目前遇到幾個比較tricky的bug，所以花了不
少時間在找問題，現在還差一些小地方還沒做好
。我想應該再給我一個禮拜應該就沒有問題了。
我想應該還是可以讓我們提早一個月完成
implementation。
布魯斯 ：要注意時間喔，還有quality。Quality是最重要的。
Implementation delay了一個月時的status meeting...
布魯斯(帶著沒有耐心的表情)：強森，湯米跟艾力克斯還有潔西卡，都是call
你所寫的那個共用的component，可是每個人都
遇到不一樣的問題。你寫的這個component到底
還有多少bug？到底什麼時候才會穩定下來？
強森 ：我想可能是上次debug時，帶來的side effect。我
想再給我一個禮拜的時間，應該就可以穩定下來了。
不過我想對於日後的專案應該可以有相當大的幫助。
布魯斯 ：不是早告訴過你要注意Quality了嗎？(對著整個team)
Quality是最重要的。我們做什麼事情，都要確保它
的quality…
Implementation delay了三個月之後，強森離開了公司。留下一個勉強可以
運作的component。在日後的project裡，這個寫好的component從來都沒有
被reuse過…
當然這裡可以從對話中，發現一個有趣的現象：
- 一般的程式開發人員，非常喜歡使用If then else的描述。而管理人員，
通常只會聽到他想聽的部分。
我用這句話來做比喻：『如果太陽從西邊出來的話，天上就會掉下來很多很
多的錢，讓我一輩子也花不完。』
對一個程式設計師來說，這是一個完全make sense的statement。因為程式設
計師通常都擁有良好的邏輯觀念：『若A則B，如果A的值是false，B的這個
block當然就run不到』。可是對於老闆來說，他只聽得到『天上會掉下來很
多很多的錢，讓我一輩子也花不完。…』
所以當強森說：『我想如果一切順利的話，大概再兩個禮拜就可以完工。』
指的其實是：『如果你運氣好，再給我一個月就會寫好了。這個component
多有用啊。絕對值得花一個月的時間開發。可是如果你知道要花那麼久，你
一定不會support這件事。沒關係，預估本來就會有誤差。』要特別注意到
的是，連他內心的想法，都包含了if then else的架構：
If (你運氣好) then {再給我一個月就會寫好了。};
component = 非常有用;
非常有用 = 絕對值得花一個月的時間開發；
If (你知道要花那麼久) then {你一定不會support這件事};
嗯，這就是軟體工程師跟一般人最大的不同。
然而對於布魯斯來說，他只聽到：『花兩個禮拜，就有一個可以讓整個team
提早兩個月完工的秘密武器，以後還可以reuse，我們以後就會有超高的生產
效率，可以把對手遠遠拋在後面…這簡直就像是擁有自己的印鈔機一樣嘛。
就算這個傢伙慢了兩個月，我還是可以從日後整體加速的時間補回來啊。我
要不要跟吉娜報告這個好消息？因為我卓越的領導，才會有這麼高的生產力
，表現這麼優秀，今年一定可以領一百張股票…』嗯，這就是老闆跟一般人
最大的不同。
根據非正式的調查(作者註：可以參考我跟靈犬萊西的訪談紀錄為證)，reuse
通常沒有帶來如同預期的生產力改變。在某些特殊的案例中，太強調要reuse
還造成了schedule的嚴重落後。我嘗試著歸納出下列原因：
*自以為厲害的程式設計師只想用他自己開發的component。
*開發軟體最花時間的部分，並不是在於寫程式本身。
*低估學習使用component所需要花的時間。
*錯誤的component設計理念，以至於reuse這些component反倒會降低生產力。
*低估開發component的困難程度以及測試component的困難程度。
*開發出來的軟體，回應速度太慢，需要進行大幅度的改寫。
以下我會針對這些原因，進行更詳細的說明。
***自以為厲害的程式設計師只想用他自己開發的component***
對很多號稱是程式設計師高手的人來說，開發自己的component，比起使用
別人的component，要來得有成就感多了。使用別人的component，固然可
以增加批評的樂趣，可是對於這些人來說，帶來的不適可遠大於帶來的便
利。最主要的原因在於：
-使用別人的component，就像把別人用過的保險套洗一洗，再拿出來用一樣
，雖然看起來外表沒什麼問題，可是，噁！誰知道裡面藏什麼髒東西？
女性讀者如果沒有用過保險套的經驗，可以想像把別人用過的衛生紙曬乾再
來reuse…很噁心對不對？覺得很髒對不對？使用別人寫好的component，大
部分時候，差不多就是這樣的感覺。
對於這些人來說，別人開發的component總是有不夠完美的地方，即使外在的
介面定義的清清楚楚，使用各式各樣的數據進行測試看起來沒有問題，裡面還
是可能會暗藏玄機。想想看在試算表的程式裡面，居然可以玩模擬飛行遊戲？
…別人寫的東西，你如果拿不到原始碼，你永遠不知道到底藏了多少後門跟bug
在裡面…還是自己來吧。
然而當你寫出自己的component，那故事就完全不一樣了。大部分的人都希
望自己寫的東西可以造成轟動，讓自己做好的這個小螺絲釘，可以使用在各
式各樣不同的場合。這很像是看著自己養大的孩子長大成人一樣。即使它不
成材，你還是認為它可以承擔重要的責任，每次看到有人在用它，就會忍不
住內心竊喜。當然，總有人不識貨，會低估我們所撰寫程式的一般性與超高
的彈性。遇到這種狀況，當然得要指責這種不具團隊合作精神的行為。除此
之外，建立一套一定要使用你開發物件的標準，在把這個文件列入你們公司
的ISO文件中，就可以強迫使用這個component。對了，如果有誰看到我所寫
的薪資計算模組，請幫我告訴它，我很想念它。我還是覺得它是最棒的。
因為文人總是相輕，所以要說服其他人使用你所開發出來的component，就
得要花相當大的力氣。所以很多時候，所謂的reuse，其實都只有自己在reuse
自己寫過的component。
使用別人的component，是否可以提昇生產力，其實還跟下一個問題有關：
***開發軟體最花時間的部分，並不是在於寫程式本身。***
共同開發軟體，其實像是把一堆來自歐美非各個大陸，不同國家的人，共同
聚集起來，用文言文來寫新詩一樣困難。最困難的地方，在於要能夠彼此溝
通，清楚了解到底要開發什麼，還有要怎麼開發這個東西。觀念的溝通，是
最花時間的。寫程式本身其實並不是最花時間的部分。即使你看著良好的設
計文件，你還是需要消化別人的想法，仔細地思考，再轉化成你自己的想法
，最後才會變成程式。而這個過程，並不是任何共用的component可以加速的。
所以對於生產力的提昇，其實是在一個人已經清楚地知道他要負責撰寫什麼
樣的程式以後，並且也了解component要怎麼使用以後，才會帶來這樣的效
益。如果component的引進，可以讓溝通觀念的速度加快，只有在這個時候
，才會帶來生產力的提昇。不過有關生產力的提昇，事實上還是有極限的。
布魯斯：你們不是擁有共用的component嗎？所以生產力不是已經提昇了50%嗎？
你們不是對它越來越熟悉嗎？應該可以越做越快啊。上次寫了三個月的
程式，現在應該只要三天就可以寫完了吧，咦，不是嗎？
況且除了溝通以外，我們不可以低估找東西所需要的時間。你需要一個component
，可是這個component到底在那裡呢？有誰寫過類似的東西呢？如果你運氣不
好，可能你會花三天的時間去找一個你一個下午就寫好的東西。很多人都會
選擇自己動手寫，而非找共用的component。所以越簡單的小程式，就會有越
多人想寫寫看。況且寫寫小東西，本來就是程式設計師在學習一項新把戲時，
最常做的事情。所以輕量級的component，數量可能最多。累積起來也花掉最
多開發的時間。
還好一家公司通常都會有幾個超人，可以迅速幫你找到你要的資訊。類似搜
尋引擎的程式，可能可以幫你一點忙，可是這些程式運作的前提是，必須要
有人整理過這些資訊。而這個假設的不成立，通常也說明了為什麼要推共用
的component會相當困難。因為要使用的人，不知道你這裡有好康的東西。
當你找到了這個component，你也了解在你完成你的工作時，會需要用到這個
component時，這時候所面臨的問題，就被提高到了另一個層次...
(待續)
|
2003-10-15, 16:02
