過去對於軟體當中復用的思想有概念，但卻沒有太深刻的體會，有時候在**裡面多處呼叫了同乙個函式，就認為這個就是軟體的復用了。甚至和別人一聊起「物件導向」來，也會說到「抽象」，「繼承」，「封裝」，「多型」，「設計模式」，「資料結構與演算法」等等名詞，但卻真的沒有一種內心的深刻體驗，也很少想什麼時候應該用「抽象」或「介面「，「多型」都說是物件導向中特別重要的東西，它到底重要在**？「設計模式」都應該是架構師考慮的和我們有什麼關係？
「資料結構與演算法」都是玩過程化程式設計人玩的，對我們有何用？等等．．．．．．
再表述直白一點就是自己對「復用「的思想過去僅僅停留在**的複製貼上、演算法的復用、資料機構的復用階段，但卻從未真正理解了」物件導向「的復用，才是更高一層的復用。
為什麼我對「復用「的問題現在如此關心呢，我想這個問題先從價值觀方面來考慮是最有說服力的，說白了也就是乙個在工地上搬磚的工人和乙個工程設計師之間的區別．．．．．．這也是從個人發展方面考慮，另乙個從軟體的可維護性上看，乙個易於維護的系統不僅能給客戶節約成本同時也給軟體的開發商後期的維護減少很多不必要的麻煩，而軟體的可維護性和軟體的復用性卻是有很大關係的。
總之，我想說的就是：無論做任何事情，都是有一定規律可循的，就像為官的有為官之道，從商的有從商之道，而我們既然選擇了從事技術，我們就因該發現、遵從、繼承、發展我們這個行業的道，這個道可以理解為規則， 而從事物件導向程式設計，直接把這些規則（理論）變為現實的指導性工具就是「設計模式「 與 」資料結構與演算法「 這都是前人給我們留下的寶貴經驗和財富。
另外我還想說明一點，在開發過程中
快速開發工具
的確給我們帶來了模組化程式設計的方便、快捷、高效，但同時它也有可能限制了我們個人設計理念的充分發揮，說具體一點就是目前的**結構單一，感覺平實，沒有設計的立體感。我們的思維都被限制在乙個模組乙個模組開發的框框裡面，這樣就造成我們在開發一些較大的業務模組時，沒能從全域性、從更大的範圍來抽象的定義問題的本質，範了設計上的大忌
---使抽象依賴於具體的實現，說直白一些就是使「戰略依賴於戰術」，這顯然是有很大的問題的，也就是我們忽略了業內一直強調的「建模」問題，同時沒能統籌考慮、統一設計，更形不成一種真正或接近於業界標準的設計，使得我們整體的設計處於一種瓶頸之下，無法突破。
最後還有一句也是自己很長時間才總結出的一句話：「做任何事情，第一步是不怕你做不到就怕你想不到，第二步是不怕你想不到就怕你做不到」.
關於遞迴的一點感想
遞迴，方法重複呼叫其自身。對於遞迴，估計是一開始就沒有理解透，經常感覺對遞迴掌握的不夠透，理解的不夠深入。最近做的乙個 要求遍歷產品所對應的每一級目錄，並取得最大的目錄 一級目錄 及最小目錄 沒有子目錄了 當時就自己寫了乙個遞迴方法，居然還成功了，呵呵。其實我個人覺得遞迴就是給定乙個結束迴圈的條件，...
關於設計模式的一點想法
軟體開發的理想是開發出高內聚 低耦合的軟體，學習 掌握優秀的設計模式並在實際開發過程中合理地加以運用，可以開發出可讀性 可維護性和可測性強的程式，降低 的冗餘性。由此想到，我們在軟體開發過程中，經常過分關注於具體的實現細節，忽略了考慮軟體設計上是否合理 是否存在更加可取的設計模式，而有意識地思考設計...
關於多執行緒的一點感想
寫了這麼多年多執行緒程式,多執行緒到底是用來幹嘛的,可能這是個很白痴的問題,就我的親身經歷看開主要是因為一下兩點 1.提公升程式效率 2.使得程式可以非同步執行,乙個執行緒幹這個活,另乙個執行緒幹另乙個活 嚴格來說,感覺這還是為了提公升程式效率,因為cpu本身就是在不同執行緒之間切換的,兩個執行緒能...