——兼談軟體引擎的概念
前一久，跟朋友聊天，他強烈要求我寫一些關於軟體架構方面的文章，這幾天總算有點時間來完成此事，算是給朋友交差吧。
首先宣告，我不是軟體架構方面的科班出身，也不是這方面的專家，只能算是這個方面的草根。這篇文章只是10多年來我在c/c++程式設計中摸爬滾打之後的一點經驗之談，謹代表個人觀點，或為各位困惑人士提供點小小的參考。如有不同意見的歡迎來拍轉。
對於軟體架構，我認為這是乙個貫穿軟體巨集觀到微觀結構的乙個整體式的結構概念。甚至還可以說我們寫**的原初目的就是為實現乙個架構。依照這種認識，下面我就按照從巨集觀到微觀的乙個順序談談每一層次中軟體架構的特點和需要關注解決的一些問題。
首先從最巨集觀的角度講，一般需要決定乙個軟體大的架構問題，此時往往還需要了解或制定硬體的架構。這一層主要就是要確定你的整個軟體是soa架構，b/s架構、c/s架構，或者是單機版的問題，有時甚至需要指定為混合架構。此時就需要同時制定出相應的硬體架構，或只提出硬體架構的需求，或了解已有的硬體架構，再來更正架構的選擇。
在上面這一層大的架構設定後，接下來就需要制定詳細的架構細則了，但這步仍然被認為是巨集觀的。soa架構目前比較火，我對他的理解就是把b/s應用分布化，最大限度的重用現有的b/s應用。在這個層次，比如你設定了b/s架構後你就需要制定你是多層的，還是3層的之類的比較具體一些的架構問題了。當然c/s應用也可以指定多層架構，甚至c/s應用也可以支援soa，但通常有些人也習慣把client到dbms的應用成為c/s應用，這個問題值得商榷，我不太贊同這樣的架構被稱作c/s，但稱之為單機應用也不妥，所以我乾脆稱之為資料庫應用架構，暫時歸入c/s一類吧。其實真正的c/s結構中，在服務端還需要有軟體的，比如目前比較火的各種網路遊戲，才是真正意義上的c/s應用。對於單機應用，到這時可以直接指定是基於模組化，還是純粹物件導向之類的問題了。
在確定了b/s或c/s應用多少層的問題之後，就是細化層中模組或抽象功能的階段了，我認為這是從巨集觀架構到微觀架構問題的分水嶺。這步就是根據具體的業務需要，設定每層需要的模組了，有時還需要制定詳細的模組間介面或呼叫方式了。
到這時我覺得軟體引擎的概念也該登場了，比如我們常見的指令碼引擎，圖形引擎，遊戲引擎之類的。一說引擎，很多人都頭暈，天天聽就是沒有乙個準確的概念，我認為所謂的軟體引擎就是具備一定特定功能的可程式設計的軟體模組。在這個概念中兩點值得注意：1、就是具備一定特定功能，比如指令碼引擎，它的功能就是執行指令碼；2、就是一定是可程式設計的，比如遊戲引擎，很多遊戲引擎都是支援指令碼方式的程式設計，你只要寫寫相應的指令碼，畫畫，或做做3d模型，一部遊戲也許就可以完成了。（這個地方的遊戲引擎例子中，可以廣義的認為畫或製作3d模型也是對引擎的程式設計。）
這種引擎化的東西其優點是非常顯而易見的：首先它暴露一組可以程式設計的指令碼化介面，可以應付各種因業務變化而引起的介面變化，相應的只需改寫引擎間相互呼叫的指令碼即可。其次他使得模組級的重用變為了可能（相應的類實現了物件級的重用），比如很多遊戲都有可能出自同一款遊戲引擎。
目前有很多的第三方免費的指令碼引擎可以被使用，著名的有lua、python、tcl等。在windows平台上還有windows script引擎可供整合，它支援vcscript和jscript。這些指令碼引擎可以被無縫整合在我們自己的軟體模組中，從而使我們自己的軟體模組也「引擎化」。而且這些指令碼引擎還有很多第三方支援元件和模組，它們中的大多數也都可以免費使用。但是這些免費指令碼引擎的乙個通病就是不支援unicode，本身是ansi的，如果你的軟體是unicode化的，那麼整合這些指令碼引擎就不得不進行頻繁的字符集轉換。我曾經想改寫乙個純粹的unicode版lua引擎出來，但是最終我放棄了這個想法，我發現這比教老外說中文還要困難。
從另乙個角度來理解軟體引擎的話，就是可程式設計的介面（指令碼），成為了各個軟體模組間最好的粘合劑。使模組間的介面更加靈活並具有智慧型性（因為指令碼就是人類智慧型的結晶體）。有時候甚至指令碼都成為了使用者和軟體間的介面。比如知名的autocad軟體，就有一套自定義格式的圖形命令指令碼，高階使用者可以直接通過輸入命令指令碼的方式完成圖形的繪製，同時這種輸入方式的精確度和輸入速度是滑鼠操作方式望塵莫及的。
這種引擎化的軟體架構我認為是目前最先進最流行最強大的一種模組級的軟體架構。如果軟體專案比較大並且模組比較複雜時可以考慮使用這種「引擎化」的軟體架構，最大限度的提高軟體的靈活性和適應性，變被動為主動。必要時甚至可以自定義一套程式設計指令碼語言出來。
在模組這一層次之下，或更細化的一級我認為就該設計模式登場了，也許各種設計模式的鐵桿粉絲該朝我扔磚頭了，把他們奉為經典的設計模式歸為軟體架構的範疇，他們肯定是不怎麼樂意的。但是不要急，大家都是受過高等教育的，咱們慢慢講理（什麼你是初中程式設計師？還懂設計模式？你簡直是天才，這篇文章不適合你，你還是趕緊去當比爾.蓋茨吧！）。如果仔細分析下各種軟體設計模式，就不難發現，其實裡面就是各種物件的結構以及物件間結構的經典範例。它規定了物件導向設計的一些經典結構，因此我就將他歸為軟體架構的範疇，因為軟體架構本身就是研究軟體各個層次中結構問題的。
在往下細分的話，就是各種軟體類如何設計和組織的結構問題了，這方面沒有什麼經典的架構可供參考，但是有很多原則是被提倡的，比如不要使用多繼承、保證成員變數的封裝性，一切訪問通過函式等。當然這些原則並不都是通用的，此時一些經驗也許比原則更有用。而我在這一層是不遵從任何原則的，一起都是從實際需要出發，並參考一些設計模式的原則來實現我的類。好用才是硬道理！
再往下細分就到了最後一層，就是具體的函式演算法如何組織和實現的結構問題了，演算法不用說很多的演算法書籍在講解演算法的同時也給出了很好的演算法組織結構。而函式的結構就是通過那個被戲稱做原始人在山洞的石壁上完成的流程圖規定的了。當然很多程式設計師都情願直接去寫**也不願意完成這種原始人的工作，從這個角度講程式設計師是嚴重的退化了，不是嗎？
到此我對軟體架構的整體理解，以及各個層次要注意的一些架構方面的問題就描述完了，當然這還不是全部的軟體架構，這只是軟體架構的乙個入門，也許入門都不算，只是乙個簡介。還有很多的架構問題擺在我的面前，而我卻沒有重視，如果上天給我個機會，讓我重來一次的話，……（此處省去若干字。）
我所知道的EC Preface
我所知道的ec preface knowledge sharing is the best reusej 所以打算寫一篇 我所知道的ec 系列。取名為 我所知道的ec 是緣於網路上有一篇講述system bios的好文章叫做 我所知道的 bios 另外該系列文章是小弟的一家之言，希望各位前輩多多指教...
我所知道的EC PowerSequence
我所知道的ec powersequence what s power sequence power sequence 是指hw device 上電的順序 它的大致順序如下 1 always 2 sus on 3 dimm on 4 run on 5 vr on 這 基本上是 nb工作需要的所有pow...
我所知道的（1）
我所知道的之序言 最近總有朋友詢問我的事情，問得多了，也就回憶的多了，興奮的時候，就想乾脆整理成文字吧，也算對自己自06年以來給做諮詢的乙個總結。從06年以來我給的3個事業群做過了cmmi的諮詢，2次2級，3次3級，累計現場諮詢天數超過150天吧，所以日積月累，對有所了解。為了避免不必要的麻煩，我認...