軟體的複雜度的産生原因及控制原則

• 軟體複雜度産生的原因
• • 溝通問題
  • 管理困難
  • 編寫規範
  • 軟體規模
  • 軟體結構（技術）
• 控制複雜度的原則
• • KISS(Keep it Simple Stupid)原則
  • 保持結構的清晰與一緻
  • 擁抱變化
  • • 可進化
    • 可擴充
    • 可定制

軟體複雜度産生的原因

溝通問題

• 使用者對某些需求隻存在一個概念，對具體要實作成一個什麼樣子沒有想法。另外使用者與開發者思維的不一緻，使用者也很難将他的意思很清晰的傳達給開發者。
• 因為溝通不暢、客戶需求不清晰等多種因素會帶來需求變更和修改。如果不能很好地控制這種變更，可能會因為多次修改導緻業務邏輯糾纏不清，系統也開始變得不可維護。

管理困難

• 通常團隊人員完成的功能也是按照子產品化或層次進行劃分，每個人完成的子產品都是系統的一個相對較小的部分，對整個系統是無法做到完全了解。
• 團隊内部成員無法做到互相了解，團隊越大需要團隊成員花費越多的時間來維護需求一緻性。
• 人越多溝通越複雜，越難協調，多地協同更為困難。
• 歸根到底，管理的困難是源于維護軟體的一緻性和完整性。

編寫規範

• 在開發早期階段，可能制定了一系列的設計及開發規則，但是由于開發者不是由一個人構成，那麼對設計及實作上各有不同，出現了靈活性的展現。但正是這種靈活性的展現，可能會導緻後期的很多問題。
• 缺乏統一編碼風格，也沒有統一的概念能夠将不同的部分組織在一起，導緻程式錯綜複雜和不可維護。

軟體規模

• 軟體的需求決定了系統的規模。當需求呈現線性增長趨勢時，為了實作這些功能，軟體規模也會線性增長。由于需求不可能做到完全獨立，導緻出現互相影響互相依賴的關系，修改一處就會牽一發而動全身。

軟體結構（技術）

• 在很多情況下，我們需要滿足安全、高性能、高并發、高可用性的需求，就需要在系統中引入防火牆、通路控制、緩存、并行處理、CDN、異步消息以及支援分區的可伸縮結構。如果我們需要支援對海量資料的高效分析，就要考慮海量資料該如何分布存儲并有效地利用各個節點的記憶體與CPU資源運算。
• 一方面增加了系統架構的複雜性及更多資源滿足安全、高性能、高并發、高可用性的需求，另一方面也因為架構複雜化及引入了更多的資源，使得系統的高可用面臨挑戰，并增加了維護資料一緻性的難度。

控制複雜度的原則

KISS(Keep it Simple Stupid)原則

1）單一職責：每個程式隻做一件事情，通過添加新特性而非修改舊系統去應對新需求

2）統一接口：每個程式的輸入輸出都是統一格式，A程式的輸出可以直接作為B程式的輸入，以支援程式之間的自由組合

保持結構的清晰與一緻

• 整潔架構：無需依賴于任何基礎設施就可以對它進行測試，隻需通過邊界對象發送和接收對應的資料結構即可

  – 遵循“關注點分離”架構原則（思想）

  – 識别整個架構不同視角以及不同抽象層次的關注點，并為這些關注點劃分不同層次的邊界，進而使得整個架構變得更為清晰，以減少不必要的耦合。

  – 合理地進行職責配置設定，良好的封裝與抽象，并在限制的指導下為架建構立一緻的風格

• 穩定依賴原則：整潔架構遵循穩定依賴原則，不對變化或易于變化的事物形成依賴

擁抱變化

• 開發過程中，應盡可能做到靈活與快速疊代，以此來抵消變化帶來的影響；
• 在架構設計層面，需要分析哪些架構品質屬性與變化有關，盡量做到可進化，可擴充，可定制。

可進化

• 實作：劃分設計單元的邊界
• 目的：确定每個設計單元應該履行的職責以及需要與其他設計單元協作的接口。
• 原因：每個設計單元都有自己的邊界，邊界内的實作細節不會影響到外部的其他設計單元，我們就可以非常容易地替換單元内部的實作細節，保證了它們的可進化性。

可擴充

• 要點：識别軟體系統中的變化點。
• 變化點：業務規則、算法政策、外部服務、硬體支援、指令請求、協定标準、資料格式、業務流程、系統配置、界面表現。
• 核心： 封裝、隐藏細節、隔離變化、降低耦合

可定制

• 引入中繼資料支援系統的可定制。
• 插件模式：提供統一的插件接口，使得使用者可以在系統之外按照指定接口編寫插件來擴充定制化的功能。