最近發生了一些事情….其實這樣的開頭根本是廢話, 因為天天都在發生事情, 沒有停過.
我經手過的很多系統, 網站, 甚至包含小程式, 大多數都會經過兩三次的重寫, 重新檢視需求, 重新規劃等等. 事實上對於一個不斷擴增及持續成長的東西來講, 這種「砍掉重練」的過程總是很必要, 而且躲都躲不掉.
我持續在讀重構：改善既有程式的設計 (二版)這本書. 雖然這本書比較著重在一些方法論, 但是其實透過一些case study可以提供一點有意思的思考.
因為人的思考總有其極限, 太過發散的想像與設計也會帶來發散的專案時程跟經費, 所以免不了一定會有一個像歌手demo帶的雛型產生, 這樣的雛型可能只是為了某些idea的呈現, 或是某些features的實驗等等. 當這樣的東西被接受, 被使用, 被成長時, 立刻要面對很多問題, 例如flexible, performance, availability, scaling 甚至是cost curve等等問題, 所以無可避免要經過一些修改, 而這些修改到了極限後再去修修補補其實無濟於事, 就像一台喜美改到極限也不會跑贏法拉利, 終究要面對問題從底部開始打掉重來.
日本mixi網站的Presentations就是一個非常好的技術範例與case study, 他們面臨快速成長帶來的龐大壓力, 限有的技術又不足以負擔之下, 只能逐步逐步的修正整個架構來降低cost curve, 但是這些修正其實有龐大代價的, 先不談背後需要多少技術人員跟多深的背景知識, 光是這種「穿著衣服換衣服」的痛苦過渡期, 應該讓這些員工減損不少陽壽.
好在這是一個很「善良」的時代, Plurk與Facebook這兩大當紅的社群很善意的釋出了一些他們現用的技術（Plurk的Lightcloud跟Facebook Develipers）, 而這些技術只要好好被使用, 好好的被了解每一個設計背後需要排除的問題及帶來的新問題, 就能大大減少「砍掉重練」的次數, 提高員工們的壽命….
雜七雜八說這麼多, 我想說的重點是: 身為經營者或決策者, 有時候不要把「重寫」看得這麼大這麼痛苦, 假如你實現一個新的idea花掉了一年, 那個用同樣的開發團隊做一次Refactoring其實不會等量的消耗掉一年, 因為這一年內除了持續開發之外, 耗費掉了很多溝通流程, 設計界面, 討論一些fork與取捨的時間, 甚至包含局部設計變更所消耗的重複時間, 因此假如開發團隊的腦袋夠清醒而且很精確的知道目前問題在哪裡, 整個Refactoring可能只需要1/2甚至更少的時間. 但是不管這會耗用多少時間, 永遠都是痛, 畢竟這段時間幾乎是沒有產能的, 只能期待新的一份生出來時能夠有美好的一切, 這就是必要之惡啊.
而能適度減少這些痛苦的時間與痛苦的次數, 依靠的是有經驗的SA, 以及有良好背景知識與態度的開發人員. 剛好這就是台灣資訊產業缺乏的, 大多數新血投注在新且炫的技術(我常稱之為奇技淫巧), 對經驗不屑一顧; 而主事者看見開發人員累積足夠經驗後便急著把人從技術職拔擢至管理職, 或者是把經驗豐富的SA當成一般開發人員, 不願意給予對應的待遇與尊重, 造成開發人員只要累積了經驗便想立刻轉向管理職以得到更多報酬或地位. 這些綜合的因素讓台灣這個資訊之島一直沒有辦法誕生一個可以真正跨越國界的網站, 真正行銷到世界的系統.
我們的電子業有曹興誠張忠謀兩大先知, 製造業有著郭台銘施振榮林百里等等霸主, 我們的網路服務業呢? 我們的軟體開發業呢?