【MVC，MVC2，WEB設計編程的分層】

　　請閱讀文章 http://forum。javaeye。com/viewtopic。php?t=11712&postdays=0&postorder=asc&start=0


　　【可擴展不等于功能強大，不要夸大其辭】

　　現(xiàn)在的系統(tǒng)，因為接口或者其他方法的使用，都具有很大的擴展性。但是擴展性不等于功能強大。
　　存在一個接口，用戶可以實現(xiàn)自己的接口，確實非常方便。但是如果你的系統(tǒng)本身只實現(xiàn)了一個接口或者根本沒有實現(xiàn)，那么對用戶來說就談不上方便。
　　
　　例如WebWork的validators，本身是一個接口，但是實際上本身實現(xiàn)的具體類很少，而且功能很差，這個時候如果你說WebWork的校驗器很厲害，那么就可能不太恰當了。當然擴展Webwork的Validator還是非常方便的。
　　
　　當然，可擴展性還是需要的，但是不要吹噓，在這個浮躁的年代，讓我們多干點實事。 :)


　　【20/80原則】
　　
　　在工作中，我經常想到20/80原則，也就是"巴雷多原則"。例如我們可以看到:


　　時間：我們20%的時間會產生成果的80%
　　
　　產品：產品的20%帶來利潤的80%
　　
　　閱讀：20%的書篇幅包括了內容的80%
　　
　　工作：20%的工作給我們80%的滿意
　　
　　演講：20%的演講產生影響的80%
　　
　　領導：20%的人作出80%的決定

　　從上面可以看出，很多時候它都很有說服力。

　　在這里我想提到幾點，但是和上面的可能出發(fā)點有所不同:
　　
　　1、程序的80%都是在處理特殊情況，所以我們一定要對特殊情況重視，不要因為是特殊情況，就不很重視。80%的客戶對特殊情況都很重視。
　　文檔對特殊情況也要詳細描述，因為開發(fā)人員80%的時候在查找這些東西，而對那些經常用到的用法卻很少查閱文檔。
　　
　　2、優(yōu)化問題:80%的瓶頸都出在20%的代碼上，所以在優(yōu)化代碼的時候不需要優(yōu)化所有代碼，只需要優(yōu)化20%的關鍵代碼就夠了。當然追求完美的人我們就不多說了。
　　記得有一條優(yōu)化的原則是"不要優(yōu)化!不要優(yōu)化"，是非常有道理的。
　　
　　3、如果你20%的事情做砸了，往往會導致80%的事情都砸了，或者是導致別人認為你把事情幾乎都做砸了。
　　如果你對一些事情發(fā)表了一些很不嚴謹?shù)目捶ǎ�那么別人會認為你在別的事情上也很不嚴謹。
　　依此類推，代碼質量，文檔完整性等等，都會讓人產生類似的推理。
　　
　　(當然一個代碼寫的很亂的人，往往文檔也很亂。)