基本介紹
- 中文名：偶然複雜度
- 外文名：Accidental complexity
- 學科：軟體工程
- 定義：軟體開發過程引入不必要的複雜度
- 原因：解決問題方法、規劃
- 有關術語：反面模式
定義,複雜度,軟體項目管理,反面模式,
定義
複雜度是軟體系統客觀存在的屬性，與軟體系統組成元素，種類，數量，狀態有關，同時元素之間互動，信息交換的頻度有關。這些是系統本身的複雜度，而系統的實現映射到計算機裡面，也會帶來偶然的複雜度。偶然複雜度是指隨著軟體開發過程中引入的偶然的、任意的、附屬的以及非必要的複雜度。偶然複雜度具有無序性、不確定性、非常規性、隨機等特點。降低偶然複雜度需要做好軟體架構設計和通過軟體項目管理，降低軟體開發的干擾。
複雜度
70年代，軟體系統已經變得極其複雜，無論是開發還是維護都是一項成本高昂的工作。人們意識到必須使軟體模組化，以便於開發、測試和維護。為此，成立於1976的McCabe&Associates公司開發出了McCabe Cyclomatic Complexity Metric（圈複雜度）技術對軟體進行結構測試。Metric以軟體複雜度測量的數目為基礎，能幫助工程師識別難於測試和維護的模組，圈複雜度已經成為評估軟體質量的一個重要標準。人們可以用圈複雜度對軟體的複雜度和質量進行衡量，來安排工程進度，在成本、進度和性能之間尋求平衡。
本質複雜度(Essential complexity)是指由於一問題的本質不適合簡單的求解方式，所有可行的求解方式都很複雜的情形。本質複雜度和偶然複雜度不同，後者的複雜度和問題本質無關，和選用求解的工具或方法有關。本質複雜度至少在1980年代中期已被使用，圖靈獎得主佛瑞德·布魯克斯當時已開始使用本質複雜度及其反義詞偶然複雜度。他也在1995年時在《人月神話》中的沒有銀彈一段中提出他的新論點。若本質複雜度和循環複雜度並用時，本質複雜度有不同的含意。此時的本質複雜度是指一程式持續的將有良好結構的流桯控制指令改為單一敘述後，最後得到的循環複雜度。像if-then-else及while loop等控制結構都視為良好結構，因此不會增加本質複雜度。未限制使用的goto、break及continue指令會增加本質複雜度。
軟體項目管理
軟體項目管理是為了使軟體開發項目能夠在預定的進度、成本、質量的目標基礎上完成軟體項目開發的工作。軟體項目管理是對軟體產品、開發人員、項目開發過程進行必要的分析和規範的管理的工程活動。軟體開發項目管理的基本目的是，讓軟體項目在整個軟體生命周期中（從需求分析、概要設計、詳細設計、編碼調試和測試驗收、維護的所有過程中）都能在項目管理者的可監控之下進行，以滿足預訂的成本、按照預訂的日程且保證質量的前提下，生產出滿足客戶需求的軟體並交付給客戶。而研究軟體項目管理的目的，是為了通過從已經成功或失敗的軟體開發項目的案例中，總結出軟體開發的通用原則和方法，用於以後的項目的管理工作。同時儘量避免前人產生的失誤，從而降低在新項目中問題出現的次數。軟體具有一定的特殊性，和其他工業產品不同，它是一種高邏輯的智力性產品，他是純知識產品，軟體項目開發的進度和質量不容易被估量和估計，生產效率也很難被預測和保證，再加上軟體開發系統的複雜性也增加了對軟體系統難以預見和難以控制的風險。軟體開發的過程也是需要進行複雜的邏輯思維，和以往的傳統工業產品相比較，軟體的設計過程是貫穿於全部的軟體開發過程，軟體開發主要是需要使用較高素質的人力資源，在物質資源的投入的需求較少；軟體開發的最終成果物一般僅僅是程式代碼和技術性檔案及說明和使用文檔。軟體項目管理的對象是成本、進度、質量和風險，軟體開發團隊成員在項目開發過程中的大力配合是軟體項目管理實施的基礎和保障。軟體項目管理的主要內容包括：人力資源的組織管理、軟體規模質量進度上的度量、項目風險管理、項目計畫與策劃、質量保證體系、過程能力評估和配置管理等方面。在項目管理中，可以通過以下措施降低偶然複雜度：
- 溝通協作，降低項目的干擾，從而減少複雜度。流程，使得軟體開發過程更有秩序，信息暢通，信息透明，加強信任，減少干擾。 這裡暫且不談，會在軟體的生命周期裡面談到。
- 敏捷工程實踐，提高對軟體的控制力。 比如TDD， 單元測試，重構，持續集成，持續部署， 自動化。通過反饋，來提高對於系統的感知和控制力。極限編程和ASE開發都會提高對於軟體的控制力。
反面模式
在軟體工程中，一個反面模式（anti-pattern或antipattern）指的是在實踐中明顯出現但又低效或是有待最佳化的設計模式，是用來解決問題的帶有共同性的不良方法。它們已經經過研究並分類，以防止日後重蹈覆轍，並能在研發尚未投產的系統時辨認出來。
Andrew Koenig在1995年造了anti-pattern這個詞[3]，靈感來自於GoF的《設計模式》一書。而這本書則在軟體領域引入了“設計模式”（design pattern）的概念[4]。三年後antipattern因《AntiPatterns》這本書而獲得普及，而它的使用也從軟體設計領域擴展到了日常的社會互動中。按《AntiPatterns》作者的說法，可以用至少兩個關鍵因素來把反面模式和不良習慣、錯誤的實踐或糟糕的想法區分開來：
- 行動、過程和結構中的一些重複出現的乍一看是有益的，但最終得不償失的模式
- 在實踐中證明且可重複的清晰記錄的重構方案
很多反面模式只相當於是錯誤、咆哮、不可解的問題、或是可能可以避免的糟糕的實踐，它們的名字通常都是一些用反話構成的詞語。有些時候陷阱（pitfalls）或黑色模式（dark patterns）這些不正式的說法會被用來指代各類反覆出現的糟糕的解決方法。因此，一些有爭議的候選的反面模式不會被正式承認。
