關於構建自己的知識體系架構的一點個人思考

killer發表於2007-10-08
架構
我們都知道，一個好的架構對於企業應用軟體來說是非常重要的，靈活的架構可以快速應對多變的業務需求。很多軟體只要業務需求的一點小變，就得修改很多地方，牽一髮而動全身，導致程式設計師疲於應付這樣的需求變化，經常抱怨客戶的需求變化太快了，甚至說客戶的需求太變態了。其實，換一個角度想，如果自己是客戶的話自己也肯定會提出各種各樣的需求，因為市場在變嘛，需求是軟體的龍頭，肯定是要變的。既然需求是變化的，那就只能向軟體本身挖掘空間了，所以才慢慢地發現了軟體架構（注意，本文所說的軟體架構都是指企業應用軟體的技術架構而不包括應用架構）的重要性，這幾年架構這個概念相當火，架構師也成了職場的香噴噴了。但是要搭建一個靈活的可擴充套件可維護的架構可以說是非常難的，別說應對百分百的需求變化，就是能應對百分之七八十的需求變化的架構就非常不錯了。那麼，是什麼原因使得搭建一個良好的軟體架構會那麼難呢？設計一個架構對我們設計人員有什麼樣的要求呢？需要什麼知識呢？其實，仔細想一想，業務需求多變是對軟體提出的一個挑戰，而由此產生的多變的軟體複雜問題何嘗又不是對我們的知識的一個挑戰呢？軟體架構的問題就是我們的知識的業務需求，設計不出良好的軟體架構的深層次原因就在於我們的知識太凌亂，不成架構，不成體系，和軟體沒有良好的架構就不能應對業務需求的變化是一個道理。下面我就把構件自己的知識體系架構的一點想法和思考寫出來與大家交流。

研究問題要把它放到動態的運動過程中去把握它，瞭解它的發展歷程，由表及裡，去偽存真，這樣才能抓住它的本質規律。前面說了知識架構和軟體架構類似，而且是裡與表的關係，那麼我們還是採取由表及裡的方法，先了解一下軟體架構。

首先還是瞭解一下軟體架構的動態運動過程，軟體架構從低階到高階經歷了這麼幾個形態：一，基礎工具類庫形態，在這一形態，我們發現程式設計的時候有很多相同的功能可以提取出來，比如字串的處理，日期轉換，數字處理以及一些介面的控制元件和處理等，把這些功能封裝成類，在各個單元程式裡面都可以呼叫它，提高功能複用。二，邏輯層框架形態，在這一形態，我們發現在前一形態的基礎上有很多程式的邏輯呼叫順序也是相同的，並且對前一形態的基礎工具類進行了邏輯層次劃分如表示層，業務層，持久層等，對這些邏輯呼叫進行抽取，形成模板，這就是邏輯層框架，從設計模式角度講，這一層整個就是一模板方法模式的應用。三，架構形態，在這個形態我們發現程式的邏輯層之間的呼叫邏輯也是相同的，所以進一步進行抽取，形成整個企業應用軟體的模板。四，業務平臺形態，前面三個形態可以說都是軟體技術上的形態，沒有業務邏輯的提取，業務平臺形態就是在架構形態的基礎上對相同的業務實體和相關邏輯進行提取，供上層應用系統直接呼叫，大大提高應用系統的生產效率。五，完全業務領域模型驅動形態，這一形態的應用系統可以說都不用程式設計師的參與了，系統直接由業務領域模型驅動，由系統分析人員對業務領域建模後得到業務領域模型，再由業務平臺環境直接編譯或解釋執行。這一形態在目前來說只能是理想形態了，與現在的現實相去甚遠，但我相信這是方向，我們是可以接近這個目標的。而且現在領域建模的理論和相關技術工具都在不斷地成熟和完善。目前，大多數軟體公司和個人都還只是停留在第一形態，達到第二形態的有自己的框架的比較少，達到第三形態的也大多是用第三方的開源邏輯框架的一個簡單的拼裝和支撐，能達到第四形態的更是鳳毛麟角了，達到第五形態的現在肯定還沒有。雖然前面說的軟體架構從低階到高階經歷了這個幾個形態，但是這幾個形態不是嚴格地從時間順序發展而來的，而是先有能夠執行的軟體，然後慢慢地衍生出架構，框架，類庫來的，是不斷地沉澱出來的，只是在類庫沉澱的基礎上也逐漸地完善出框架，在框架沉澱的基礎上也逐漸地完善架構。這些過程在時間上可以說是並行的。

如果把企業應用軟體比做一棵樹的話，那麼架構就是樹幹，框架就是樹枝，類庫就是枝節，具體的類就是樹葉，直接面向使用者的應用系統就是這棵樹的果實。讀到這裡，大家可能也發現了，這棵樹還缺少了一個最重要的部分，那就是樹根。這棵樹的樹根就是我要說的知識體系架構。物有本末，事有始終，知其先後，則近道矣！凡事糾出了根才算是抓住了本，扎住根，然後再強幹弱枝，從源溯流地去學習、研究，則一切盡在掌握！下面就正式說說知識體系架構。

知識體系架構本身也呈現出樹的特徵，從這個角度說，企業應用軟體也可以說是知識體系架構的一棵子樹，或者說是它的一個樹枝。我們搞計算機軟體的，對於樹的概念應該不會陌生，資料結構裡面也學過樹的概念。我們這裡所說的樹的概念可以說是植物世界裡的樹和計算機世界裡的樹的一個結合，具有雙重特徵。

知識體系架構樹的樹根毫無疑問是哲學，包括世界觀，價值觀，人生觀，方法論，在我們做企業應用軟體這方面，方法論尤其重要，我在另外的帖子裡面也寫過方法的重要性，主要是要培養辯證的方法論，科學的思維方法，這裡就不多說了。

由樹根延伸出來的樹幹那就是基礎學科，樹幹再衍生出樹枝，有自然學科，社會學科，人文藝術學科等。自然學科這個樹枝又可以衍生出物理學，化學，數學，生物學等等分枝。社會學科又可以衍生出政治學，歷史學，經濟學等分枝。人文藝術學科又可以衍生出文學，音樂，繪畫等分枝。分枝可以再生分枝，無窮盡也。就像植物樹一樣，樹枝可以交叉，知識體系架構樹的樹枝也可以交叉，企業應用軟體可以說是由物理學衍生出電子學，再分出計算機學科，再分出軟體學科，並交叉人文藝術學，企業管理學，經濟學等分枝而衍生出來的一枝分枝。知道了這個前提，我們再來看看企業應用軟體這個分枝的子樹結構。

那麼，企業應用軟體的樹幹是什麼呢？還是把它放到動態的運動過程即軟體的生命週期中去研究它吧，那麼這個樹幹就是軟體的生命週期運動。由這棵樹幹衍生出需求分析，設計，開發，測試，維護等分枝。需求分析又可以衍生出需求分析，需求管理等。設計又可以衍生出架構設計，模組設計，詳細設計等。開發又可以衍生出程式語言，指令碼語言，資料庫語言，開發過程等，而c++、java等只是程式語言這個枝節上的兩片樹葉。測試可以衍生出單元測試，模組測試，功能測試等。維護可以衍生出重構等。這樣的一棵樹其實用語言不太好表達，用圖形的方式更直觀，一目瞭然。我覺得我們每一個人都應該能畫出一顆自己的知識架構樹。這樣才能真正做到胸有成竹。學習新技術，新知識的時候首先要能迅速把它定位到自己的知識架構樹的恰當位置上，然後才是深入地鑽研它。所有的具體的技術，技巧都只不過是這棵架構樹的一片樹葉，只有從上往下看，才能知道它在整體中佔的分量，才能真正看清楚它的角色，避免迷失在樹葉裡面而一葉障目不見泰山。而且，有一句古話說得好，落葉歸根，樹葉熟了要落掉歸根，具體的技術研究過了以後也要回過頭來返哺一下樹根，那就是我們的哲學，方法論。只有這樣我們的大本大源才能源遠流長，經久不衰。

世人只知道種植植物樹，自己心中的這個知識樹又有幾個人苦心地種植和栽培呢？要記得經常給這棵樹剪剪枝，澆澆水！用一輩子的時間種植一棵樹並精心呵護，這棵樹必將長成參天大樹，雨天可以遮風擋雨，夏天可以乘涼！

上面說的知識架構樹並沒有具體的說，因為我覺得在每個人的心中這棵樹都是不同的，就像世上沒有相同的兩片樹葉一樣。我在這裡只是提出這個問題而已，目的是與大家交流，共同提高，相互學習。

[該貼被killer於2007年10月08日 22:42修改過]

相關文章