四 層次架構圖
曾見過一類程式設計師，他們第二次做類似專案時，還是按照以前的思維模式，把所有**重寫一遍，或者在前面的**上改改，就算第二個專案了。當產品越來越複雜後，實在無法再在原來的基礎上修改時，就不得不推翻重來一次。也許在原有基礎上修改是個捷徑，也很快，但我認為那其實是一種不負責任的做法，它可能會帶來軟體質量的不可靠和軟體生命週期的縮短，從而無形中增加了公司的開發成本。
我推崇的做法是，類似產品應該開發出乙個共同的平台出來，不同的產品只是表現形式不同而已，但主體框架基本相同。這樣可以有幾個好處：
1）提高了框架和**的重用性；
2）久經錘煉的架構是產品穩定的重要保障；
3）大大提高後續產品的開發周期；
4）公司會形成乙個技術積累。
我研究過幾個開源軟體的原始碼，發現
openoffice
的架構深讓我折服，在不同的公司，使用她這個層次架構，總讓我受益匪淺。
這是openoffice
的架構圖，多麼的清晰
(如果你不了解她，請搜尋一下，有前輩做過仔細的分析)。
這是我在乙個高鐵公司做綜合類監控產品時，提出的軟體設計層次架構，你們看看是否很合適？
如此一來，這個監控類的軟體就可以有個共同的平台了，只是有不同的應用而已。增加模組，擴充套件模組功能，都非常滴方便。當新成員加入時，你只用告訴他平台的流程，就會自然而然地熟悉了這個平台。
有的人可能會提出，這樣的平台在初期搭建的時候可能會非常龐大，週期很長。其實不然，只用你把各層職責和上下層的介面定義清楚，功能模組是可以逐步新增的，並不需要一口吃個胖子，所以它的搭建週期也並不長。再回到思想二字上來，你就會發現萬變不離其宗。經過我的實際驗證，這樣做並不難，並且非常快，擴充套件性非常好。
軟體架構設計
首先我們應該了解什麼是軟體架構設計？架構大體分為以下幾種 邏輯架構 模組劃分 介面定義 領域模型 開發架構 技術選型 檔案劃分 編譯關係 物理架構 硬體分布 軟體部署 方案優化 執行架構 技術選型 控制流劃分 同步關係 資料架構 技術選型 儲存格式 資料分布 程式設計師向架構師轉型的關鍵突破 學會系...
軟體架構設計
在嵌入式軟體開發的專案中，很少見到有專案架構師這一工作職稱，但是大型專案的總是會有架構師一說。1 為什麼嵌入式開發很少會出現架構師這一職責。嵌入式開發的專案，一般有兩種模式 一類是 完全由開發人員自己設計 排除庫函式 另一類是基於固有的作業系統進行開發。前者一般都是針對特定應用，所有 的規模不會很大...
軟體架構設計
本章考點主要集中在 基於構件的開發模型，架構風格，架構評估，架構與質量屬性，設計模式。縱觀軟體架構技術的發展過程，可以認為經歷了4個階段 無架構設計階段 以組合語言進行小規模應用程式開發為特徵 萌芽階段 出現了程式結構設計主題，以控制流圖和資料流圖構成軟體結構為特徵。初級階段 出現了從不同側面描述系...