這條有點兒爭議，本人有些時候非常不喜歡沒有前瞻性設計的程序設計，不過經過幾年的編程，調試工作，思想有些轉變。 以前經常遇到這樣的例子：上層應用程序還沒怎麼完善呢，突然一天底層的接口全改了，原來做的全沒用了，原來費九牛二虎之力搞的程序現在一個方法搞定了！原因在於編寫代碼的時候最重要的是實現目前要求的功能，至於以後的情況誰知道呢？很多時候程序員對於未來最終用戶的需求的預測基本都歸於失敗，最典型的就是比爾蓋茨的維納斯計劃了，還有他許多預測都歸於失敗，具體可以看看：http://www.xiansheng.com/2010/renwu/0420_BiEr_GaiCi_8.shtml
話說回來，連這樣的大牛都經常預測失敗，更不用說我們這些人了，基本就是井底之蛙，擴展也是在自己的井裏，等外邊的洪水一來，一切還是重新開始。
我在學習C++設計的時候，很多人都說設計模式很重要，可是現實是根本沒多少模式用得上，很多就像GRE的生僻單詞，學過就忘了，用得多的還是那幾個，而且道理淺析的如禿子頭上的蝨子，非要搞個模式理論出來就是折騰！所以現在人家老外也不怎麼流行用這個了，我們更應該適時摒棄這些東西。OSI模型牛不牛？還是沒有做過TCP/IP嘛！理論完美有些時候反而失去了現實的市場。
現在流行什麼迭代開發，敏捷編程，爲什麼呢？因爲需求變化很快，傳統的開發模式再厲害也不行，有可能你辛辛苦苦做兩年發現根本沒有市場了，最典型的就是模擬攝像機，模擬的錄像機，我們中國剛做出來，大家都vcd了，然後dvd了，估計數碼相機也一樣，現在都流行單返了。消費類電子更是各領風騷一兩年啊，前年臺積電，去年聯發科，今年就變成宏達電了，誰知道明年是哪一家呢？
再說了程序的可括展性必須建立在對未來需求的準確把握上，說實話真的很難，否則不會有那麼多公司死掉了，做3G的凱明，做IPTV的UT斯達康，例子太多了，IT圈到處都是。程序員很多時候根本不知道最終用戶的使用情況，或者不清楚普通大衆用戶的現實體驗，所以對未來的趨勢預測都歸於失敗，很多時候都是南轅北轍，結果你的程序做得可擴展性越好，反而實際的損失越大，機會成本啊！而且大而全的，大而空的設計既難理解也難維護，很多時候大家會想：這個接口幹什麼的呢？沒實現怎麼還放在那兒？擴展用來幹什麼呢？我們得承認一個事實：沒有兩個人的想法是一樣的，所以你的想法有時候很難被別人理解或者接受，程序員都有些傲氣，可以理解。所以我們的編程要求最重要也是最基本的就是命名，包括文件名，接口的名字，函數變量的名字都是不怕長就怕別人不明白，我覺得很有好處。
所以我的建議就是：寫代碼的時候先實現基本功能，可要可不要的寧可不要，以後真的需要再加，東西越多出現bug的可能就越大，而且維護成本也越高。千萬別爲擴展功能千辛萬苦設計了一大堆，實現了一大堆，結果根本就不是人家想要的，或者偏差很大，到時候就真的蛋疼了。