軟體架構五大原則,確保你的項目100%成功

2020-12-13 51CTO

方案架構師是負責系統架構以及特定產品的技術標準(包括技術、平臺、基礎架構)的專家。他們為產品設定前景,他們的分析也是產品的定義、設計、交付和永久支持的成功關鍵。因此,構架師不僅需要了解業務需求,還需要了解符合企業技術總目標的邏輯性、可擴展性及成本效益。

架構師的重要技能之一就是能從許多不同的角度來看待架構,因為每一個單獨的角度可能不完全相關,但結合在一起就可以從總體的角度來看待產品。這些角度包括原則、標準、模式和反模式、經驗法則和經驗實踐,而這些對於決策方向確定和項目評估成功至關重要。

本文將一一介紹這些架構原則。

SOLID五原則

SOLID原則不僅適用於軟體開發,也適用於系統的架構。

單一功能原則

每個系統功能(例如服務/模塊/應用界面)應該只有一個職責,因此也只有一個變更的理由。儘可能地縮小職責範圍,用戶便會理解其功能,從而減少錯誤的發生。

開閉原則

這一原則認為,最好在不修改系統操作的情況下對其進行擴展。儘管提前預測需求的變化可能導致過於複雜的設計,但是能夠以現有組件的最小更改來適應新功能是應用程式長期使用的關鍵。

裡氏替換原則

在軟體開發中,這一原則意味著派生類必須可替換為它們的基類,但這一原則與勃蘭特·梅耶的「契約式設計」關於如何應用於分布式架構有著相似之處:兩個服務在進行多次有效溝通後,它們之間形成一種「契約」,其定義了兩者的輸入/輸出、結構和約束。因此:對於具有相同契約的兩個分布式組件,一個組件應該可以替換為具有相同契約的其他組件,而不會改變系統的正確性。

接口隔離原則

接口或契約必須儘可能的細化及特定於客戶,因此調用客戶端並不依賴於它們不使用的功能。這與單一責任原則相輔相成:通過分組接口,我們提倡通過按角色或責任分離的組成,將派生模塊與不需要的職責分開解耦。

依賴反轉原則

高級模塊不應該依賴於低級模塊,它們都應該依賴於抽象。同樣,抽象不應該依賴於細節,而細節應該依賴於抽象。因此,該原則引入了高層和下層軟體組件或層之間的接口抽象以消除雙方的依賴關係。


「最小」原則

在下文中,將根據這些原則的名稱將他們一起來介紹。

最小驚奇原則

最小驚奇原則(或最少意外原則)指的是,當首次發現某個解決方案或方法時該領域中知識淵博的人不會感到驚訝(受眾可能不同,例如最終用戶、程式設計師、測試人員等)。更實際地來說,該原則的目的是利用用戶已有的知識,在使用模塊時儘量減少他學習曲線,因此任何具有高不可預測性因素的事物都是用來重新設計的好選擇。

這一原則適用於架構的每個方面:從命名服務到用戶界面的可視化,再到域模型的設計。

有驚喜也有驚嚇……

最小省力原則

最小省力原則(也稱為齊夫定律)源於一項人類的基本行為:即每個人都傾向於選擇走儘可能不費力的道路。例如,如果一項設計遵循於特定的模式,那麼下一個開發人員將一次又一次地遵循這一相同的模式,除非有簡單得多的方法出現,這時開發人員才會改變這一模式。或者更進一步說,一旦他們找到一項任務的可接受結果,就不需要立即改進當前的解決方案。

最省力等同於最少的工作量。

因此,必須通過建立正確的架構來實現一個好的開端:即設定很高的期望值,並確保每個人都明白工作質量不能在項目周期中受到影響,並且即使未來發生變化,質量也要得到保證。

這個原則的偉大之處在於它的效益是可以推斷的:只要把正確的設計放在適當的位置,就可以創建一個架構框架,這將是下一個系統構建的基礎。換言之,就能夠為組織的軟體系統建立一個成功且不過時的模板。


最簡便的道路

經濟學中的原理

以上提到的兩個原則有一個共同的主題:即都充分利用了機會成本和推遲決策成本。

機會成本原則

人們每次做選擇時,做出的選擇都會與一定的價值有關。價值分兩部分:效益和成本。選擇的機會成本是放棄其後才得到的。為了做出一個好的經濟決策,我們希望選擇效益最大但成本最低的方案。

例如,擺在面前的有兩種選擇,一種是內部構建的系統,另一種是現成的供應商產品,如果選擇後者,那麼機會成本就是開發團隊可能會開發出的令人眼前一亮的新系統。

因此,架構所要做的就是權衡不同的選擇,做出明智的決定,為項目爭取最大的價值。例如,一個非常常見的分歧就是,是創建一個戰術上的解決方案,以便快速推向市場,還是創建一個更具戰略意義的解決方案,雖說現在成本更高一些,但未來成本會降至最低。

以下是一些可供考慮的因素:

  • 架構分析或評估的可用時間是多少?畢竟提出一個解決方案已經非常有挑戰性,更不用說好幾個了!
  • 未來1-3年的產品路線是什麼?還有什麼其他的項目?能看到任何協同效應嗎?
  • 目前可能解決的技術債務是什麼?
  • 反過來想:如果尋求一個戰術解決方案將會產生多少新的技術債務?
  • 哪些品質要素對企業中的系統最重要?以及它們可能將如何被提議的解決方案所影響?
  • 除了架構團隊,還有誰是影響決策的利益相關方?公司?你的老闆?技術設計部門?每一個利益相關方的核心目標是什麼?如何調解有衝突的需求?

最後責任時刻原則

這一原則(也稱為延遲成本)源於精益軟體開發,強調儘可能長時間地堅持採取重要行動和關鍵決策。這樣做是為了在最後一刻之前不漏掉重要的備選方案,即縮小選擇範圍,直到得到更全面的信息做出最佳選擇。

這個策略不是過早做出決定,而是推遲決定,直到不做決定的成本大於作出決定的的成本之前,保留重要且不可逆轉的決策。

而有一種緩解決策過晚風險的方法是建立概念驗證(POCs),來原型化備選方案,並向利益相關者證明他們的需求。


在項目的早期,應該儘可能少地做出有約束力的決定!

結語

架構原則可幫助我們評估整個項目中所做的決策,同時確保其不僅符合項目的總體目標,且符合企業的技術範圍。下圖集中展示了本文中所闡述的五項原則:


【編輯推薦】

【責任編輯:

華軒

TEL:(010)68476606】

點讚 0

相關焦點

  • 你是一名軟體架構師嗎?
    架構定義弄清了非功能需求後,下一步就要思考如何定義架構,解決需求方提出的問題。 我們可以說每個軟體系統都有架構,但不是每個軟體系統都有現成的架構。這才是關鍵點。軟體定義過程需要思考如何在給定的限制下滿足提出的需求,進而解決問題。架構定義過程是在項目的技術方面引入結構、規範、原則和領導力的過程。
  • 原來合格的軟體架構師是這樣!!!
    我們可以說每個軟體系統都有架構,但是,不是每個軟體系統都有定義出來的架構( defined architecture)。這才是關鍵點。軟體定義過程需要思考如何在給定的限制下滿足提出的需求,進而解決問題。架構定義過 程是在項目的技術方面引入結構、規範、原則和領導力的過程。
  • 如何保證軟體應用系統架構設計結果的可擴展性和可重用性(下篇)
    6、軟體應用系統中的各個功能模塊的職責應該單一面向對象設計的五大原則是提高軟體應用系統的可維護性和可重用性的基本指導原則,而在面向對象設計的五大原則中涉及「職責單一」方面的設計要求就有程序類的「單一職責原則」和「接口隔離原則」。
  • 如何從軟體開發人員成長為軟體架構師
    軟體架構師是一位軟體專家,負責對給定的數字產品做出有關系統設計,基礎結構和技術標準(包括語言,工具和平臺)的行政決策。軟體架構師設定願景並監督系統的構建。 此外,軟體架構師應該能夠共享技術遠景和技術指導,並根據軟體項目的要求進行計劃。
  • 《程式設計師必讀之軟體架構》作者Simon Brown:架構師與程式設計師的區別
    這就是為什麼《程式設計師必讀之軟體架構》一書中加入了有關C4模型的內容,這是一種從多個不同抽象層面理解軟體系統的方法。這個方法有助於你退後一步反觀大局。問:你對軟體架構的理解是否因為你的經歷和實踐而改變過?Simon Brown:是的。我對軟體架構的理解是根據我在諮詢公司工作時在各個項目中負責軟體架構的經驗形成的。
  • 設計的五大原則-SOLID
    1.背景最近在讀《架構整潔之道》這一本書,這本書的確寫得不錯,最近也沒有更新文章,一方面再忙工作,另一方面也再啃一些書。當然文章還是得更新,《架構整潔之道》裡面有些有意思的內容我會提取出來外加自己的思考。在這本書裡面的第三章介紹了設計原則,這部分我覺得對於大家的平時工作都比較有用。2.
  • 軟體項目實訓及課程設計指導——如何實現面向對象的系統架構設計
    軟體項目實訓及課程設計指導——如何實現面向對象的系統架構設計1、什麼是面向對象的軟體應用系統的架構設計從軟體應用系統的架構設計師的角度來看,所謂的軟體應用系統的系統架構就是一套構建軟體應用系統的整體結構的各種設計準則
  • 什麼是軟體架構?
    它可能對軟體在質量屬性、開發進度、成本產生影響,有些影響甚至無可挽回。一項重大決策可能會影響到很多人,甚至讓其他軟體系統不得不做出改變。無論如何,重要大在設計決策一旦出錯,後續個性將付出巨大的代價。    提升某項質量屬性意味著強調它在軟體系統中在作用。設計得當的架構能提供利益相關方需要在質量屬性,抑制或消除利益相關方不需要在質量屬性。架構也可以提升其他軟體特性。
  • 為你的設計選擇正確的軟體架構
    :你已經把一個想法仔細思考過一陣子,逐漸得出可行的結論,現在,你想要創建一個合適的項目,看是要更進一步探索這個想法或是將其產品化。但是,應該從哪種軟體架構入手呢?Espruino?Arduino?microPython?Segger embOS?MicriumuC/OS-II?以及在uC/OS-II和uC/OS-III之間又有什麼區別呢?究竟該採用初始成本較低的開源架構,還是選擇需要支付前期費用的商業解決方案,來加速你的設計過程呢?
  • 對一些架構設計原則的反思
    在架構設計的領域,⼈們總結出了很多原則。這些原則的⽤語⼤都很簡略,容易傳播。但是提出這些原則的⼈,往往不會告訴你,為什麼應該是這樣的原則。哪怕說了背景,過了⼀段時間,聽的⼈可能已經不知道原則提出⼈的初衷。⽽且這些原則,粗看起來是很有道理,可是在實踐中,卻往往不是這麼回事,那麼就淪為⼼靈雞湯了。在看這些原則的時候,每個⼈都要形成⾃⼰的判斷能⼒,不要⼈雲亦云才好。
  • 想要進階軟體架構師,這5本書才是最好的
    需要讀哪些書,或者有什麼資源,需要考什麼證書麼以及成為一個軟體架構師需要多少經驗等問題。本文就從軟體架構師的角度選擇了5本最好的並且是必讀的書籍因為架構是一個非常廣的主題,它和你如今所處的工作領域息息相關,因此這些書並不能涉及到軟體設計相關的方方面面,但是卻會為你提供構建一個安全和可維護軟體所需的基本工具和技術。
  • 軟體項目實訓及課程設計指導——系統設計中的系統架構設計示例
    軟體項目實訓及課程設計指導——軟體系統設計中的系統架構設計示例1、軟體系統概要設計中所涉及的主要設計內容和工作過程(1)在軟體應用系統項目的系統概要設計工作中,首先是要完成軟體系統的總體架構設計及系統的分層設計,然後再利用UML包視圖體現出軟體系統架構設計的最終結果
  • 軟體架構設計:軟體質量屬性、架構風格的案例
    在項目之初,公司的系統分析師對該集成開發環境的需求進行了調研和分析,具體描述如下:a.需要同時支持該廠商自行定義的應用程式語言的編輯、界面可視化設計、編譯、調試等模塊,這些模塊產生的模型或數據格式差異較大,集成環境應提供數據集成能力。集成開發環境還要支持以適配方式集成公司現有的應用模擬器工具。
  • 軟體項目實訓及課程設計指導——可擴展和可重用是架構設計的目標
    軟體項目實訓及課程設計指導——可擴展性和可重用性是面向對象架構設計的主要目標1、什麼是合理的軟體應用系統的系統架構設計軟體應用系統的設計人員經常會陷入一種困惑,面向對象系統架構設計結果的評價標準是什麼?
  • 成功的企業架構師所具備的七個特徵
    在首席信息官的領導下,企業架構師可以設計系統架構和制定技術發展計劃,以支持和推動企業未來幾年的發展戰略。 要找到一個合格的企業架構師並不容易,而將企業的命運交給一個沒有能力完成這項工作的人,這可能會在運營和財務上都造成巨大的災難。為確保你僱傭的企業架構師了解你組織的目標,同時具備構建彈性和靈活的系統架構所需的業務和技術知識,請密切關注以下特徵。
  • 科研項目管理軟體那麼多 宇凡軟體為啥突出重圍
    科研項目管理系統是最近幾年科研人員比較關注的一款軟體,科研人員在處理一系列的行政問題時,不了解流程而把事情變得複雜。南京宇凡軟體在此基礎上研發了一款針對科研項目管理的軟體,可以幫助科研機構和高校科研成果進行管理。
  • 如何保證軟體應用系統架構設計結果的可擴展性和可重用性(上篇)
    軟體項目實訓及課程設計指導——如何保證軟體應用系統架構設計結果的可擴展性和可重用性(上篇)1、良好的可重用性軟體系統架構設計結果的主要體現可重用性的軟體應用系統的系統架構設計結果主要體現在如下兩個方面——本項目的系統架構設計的結果是可重用的和在本項目的系統架構設計中重用成熟的系統架構設計方案
  • 20 年架構老兵:進階架構師要搞懂的 12 個實戰案例
    他將自己在實際項目的總結成了幾十講的內容,不僅會將理論系統性地講透徹,同時還提供大量接地氣的案例讓你有機會實戰,能夠知行合一地學習架構。這些內容濃縮在「架構實戰案例解析」專欄中,讓你能夠透過現象看本質,對架構的認知快速到位,而不是架構知識的搬運工。
  • 軟體項目實訓及課程設計指導——為什麼要應用和實現SOA架構設計
    軟體項目實訓及課程設計指導——為什麼要應用和實現面向服務的系統架構設計面向對象的架構設計能夠適應不斷變化的軟體系統的需求,而面向切面架構設計是對面向對象架構設計的進一步擴展和完善,但面向對象的架構設計和面向切面架構設計都是針對單一的軟體應用系統設計的方法。
  • 軟體項目實訓及課程設計指導——如何實現面向服務的系統架構設計
    軟體項目實訓及課程設計指導——如何實現面向服務的系統架構設計1、什麼是基於SOA的軟體系統架構(1)什麼是面向服務的軟體系統體系架構所謂的SOA(Service-Oriented Architecture,面向服務的軟體系統體系架構