也談軟體工程！

csdn中看到不錯的貼子
http://blog.csdn.net/panaimin/archive/2006/07/12/907957.aspx?Pending=true
裡面討論到了軟體工程方面的東東，感覺蠻有意思，於是自己也回了貼，談談自己的看法。

貼中原文：
“關於軟體工程，我並不看重。我更相信人對代碼的控制能力，正常人對於正常複雜程度的代碼，控制幾十萬行代碼應該是可以的；如果軟體總體上有很好的結構設計，模組之間有穩定、合理的介面，那麼，僅僅依靠人的腦袋，加上良好的編程習慣，即使面對大型的軟體，應該也能控制。”
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

不太理解PAN老師寫的這段話！
“如果軟體總體。。有好的結構設計，，ＸＸ穩定，，”
最大的前提是這些都做的比較好的情況下，再加上後面講到的人的控制，才可能成就一個好的項目。那麼我想問的是，好的架構，設計，合理穩定的模組介面那裡來呢？若沒猜錯，應該是來自好的分析設計，包括架構的，業務的等等，對不對？好的分析設計怎麼來呢？應該來自架構師，分析師吧！架構，分析師不可能在做完一個項目又一個項目之後不去思考總結吧？在架構，分析師通過對一個個項目的分析設計後，一定想找到一個統一的標準或模板以便在下面項目中能夠利用以住項目經驗，更好的為以後項目開發服務，說的大一些是否應該就是讓軟體的開發更像我們建立房屋，建立橋樑一樣更工程化一些呢？

反過來講，我也相信人腦袋創造，控制等能力，但對于越來越複雜的商務邏輯，就要求軟體應該像其它行業學習，正常化，工程化。因為人的腦力在單個時間內的思考是有限的，這就需要我們有一套工程化的東西理論來指導我們工作。可能有人會說：不用工程化，理論化這些東西也能解決啊，用我的經驗唄，沒錯，非常正確，經驗非常重要，但如果從另一個層次來理解經驗會是什麼呢？若把多人的經驗稍加改造，定成標準，寫入書本，是不是就是我們說的工程化了呢(當然，前提是這些解決之道的能夠值得化書本記錄下來,傳給後人，以備參考)？

因為我個人認為，軟體工程就是一些經驗的總結。解決問題或事情方面，應該沒有所謂的銀彈或大牛，若有，那麼我寧可相信是：在解決某問題時，他會拋出n個解決方案，然後權衡各方面的利弊得出1個較為正確的
方案，經大家的驗證，這的確是行之有效解決方案，於是尊為大牛！

這樣看來，軟體工程，在一定情況下，一定語境中，合適的去用，是有必要的。試想，三峽大壩也不是個人拍腦袋或是個人的經驗就能解決嗎？
當然這些都是見仁見智的事情。

寫的有些亂，希望未曲解PAN老師的意思，純屬一家之言，歡迎斧正！
另找到一篇類似但寫的較好的文章：
http://www.zhangxun.com/tmpl_book.aspx?sname=cc2e