軟件熵解釋：原因、影響和補救措施
已發表: 2022-03-11本文面向對軟件熵是什麼、對他們工作的實際影響以及促成其增長的潛在因素感到好奇的軟件開發人員或項目經理。
主要目標是建立對軟件熵的認識，因為它是所有形式的軟件開發中的一個因素。 此外，我們探索了一種可以為軟件熵分配具體值的方法。 只有通過量化軟件熵並觀察其在連續發布中的增長，我們才能真正了解它對我們當前目標和未來計劃構成的風險。
什麼是軟件熵？
軟件熵得名於現實世界中熵的主要特徵：它是一種衡量混沌狀態的指標，它要么保持不變，要么隨時間增加。 換句話說，它是衡量軟件系統在改變它時內置的固有不穩定性的指標。
不幸的是，軟件熵很少得到應有的重視。
在從開發團隊中拉出某人、過早開始開發週期或實施“快速修復”（事實上，這是最有可能增長的時刻）時，都沒有考慮到這一點。
軟件開發是一門藝術和一門行業，其核心構建塊定義不明確。 建造者使用水泥和釘子，而軟件開發人員則使用邏輯斷言和一組假設。 這些不能拿在手裡檢查，也不能按八分之一英寸來訂購。 儘管不經意的觀察者可能很想將軟件開發與構建進行比較，但除了一些表面上的相似之處之外，這樣做會適得其反。
儘管存在這些困難，我們仍然可以製定指導方針，使我們能夠了解軟件熵的來源，衡量它對我們的目標構成的風險程度，以及（如果有必要）可以採取哪些措施來限制它的增長。
建議的軟件熵定義如下：
其中
開發迭代的概念是我們理解軟件熵不可或缺的一部分。 這些是從系統的一種行為到另一種行為的活動循環。 我們在軟件迭代期間為自己設定的目標稱為其範圍。 在軟件開發中，此類週期涉及修改或擴展軟件的底層代碼。
對代碼的所有修改都發生在開發迭代中，即使執行它們的人不這麼認為。 也就是說，那些以使用“快速而骯髒”的方法構建系統而自豪的小型組織——很少或根本沒有收集需求或分析——仍然使用開發迭代來實現他們的目標。 他們根本沒有計劃。 同樣，即使修改後的系統的行為在某種程度上偏離了我們的意圖，它仍然是通過開發迭代來實現的。
事實上，發生這種情況的風險正是我們對軟件熵的認識想要解釋的，而我們測量它的願望是為了限制它。 那麼，實際上，我們可以如下定義軟件熵。
任何給定的系統都有一組有限的已知未決問題 I 0 。 在下一次開發迭代結束時，將有一組有限的已知未決問題 I 1 。 系統的固有熵指定了我們對 I 1的期望可能與其實際值有多大的差異，以及該差異在隨後的迭代中可能會增長多少。
軟件熵的影響
我們對軟件熵影響的實際經驗取決於我們如何與相關係統交互。
用戶擁有軟件的靜態視圖； 他們關心它現在的行為，而不關心系統的內部結構。 通過執行預定義的操作，用戶假設軟件將以相應的預定義行為進行響應。 然而，用戶最不准備推斷他們正在使用的軟件中的熵水平。
軟件熵與變化的概念相關聯，在靜態系統中沒有任何意義。 如果沒有改變系統的意圖，我們就不能談論它的熵。 同樣，一個尚不存在的系統（即下一次迭代實際上是其存在的第一次）沒有熵。
從用戶的角度來看，軟件可能被認為是“有缺陷的”，但如果在隨後的迭代中，軟件開發人員和管理人員按計劃實現了他們的目標，我們必須得出結論，系統中的熵實際上非常低！ 因此，用戶的經驗幾乎不能告訴我們關於軟件熵的任何信息：
軟件開發人員對軟件有一個流暢的看法。 他們關心一個系統當前如何運作，只有在它必須改變的情況下，他們關心它如何工作以製定適當的策略的細節。
經理可能對軟件有最複雜的看法，包括靜態和流動的。 他們必須在短期的緊急情況與進一步延伸到未來的商業計劃的需求之間取得平衡。
這兩個角色的人都有期望。 每當這些期望被破壞時，軟件熵就會顯現出來。 也就是說，軟件開發人員和管理人員盡最大努力評估風險並為他們制定計劃，但是——不包括外部干擾——如果他們的期望仍然令人失望，只有這樣我們才能談論軟件熵。 它是一隻看不見的手，它破壞了不在範圍內的組件交互，導致生產服務器莫名其妙地崩潰，並扣留了及時且具有成本效益的修補程序。
許多具有高熵的系統依賴於特定的個人，特別是如果開發團隊中有初級成員。 這個人擁有這樣的知識，如果沒有他的“寶貴”投入，其他人就無法完成他們的任務。 它無法在標準 UML 圖表或技術規範中捕獲，因為它由異常、預感和提示的混合體組成。 這種知識不依賴於邏輯一致的框架，因此很難（如果不是不可能的話）轉移給其他任何人。
讓我們假設，通過極大的決心和努力，這樣一個組織能夠扭轉局面並穩定其 IT 部門。 情況似乎有所改善，因為當軟件開發陷入停頓時，任何進展都是令人鼓舞的。 然而，在現實中，與在熵仍然很低的情況下觸手可及的崇高目標相比，所達到的期望很低，取得的成就也很乏味。
當軟件熵壓倒一個項目時，項目就會凍結。
不能有更多的開發迭代。 幸運的是，這種情況不會一蹴而就。 向懸崖邊緣緩慢而陡峭的行進是每個系統都會經歷的事情。 無論第一個版本的組織和效率如何，在連續的開發迭代中，它的熵——以及因此出現意外出錯的風險——都會增加，除非採取特定步驟來防止它。
軟件熵不能減少。 就像現實世界中的熵一樣，它只會增長或保持不變。 起初，它的影響可以忽略不計。 當它們開始出現時，症狀很輕微，可以被掩蓋或忽略。 但是，如果一個組織只是在軟件熵成為項目中的主要風險時才試圖對抗它，那麼它會遺憾地發現它的努力是徒勞的。 因此，當軟件熵的程度較低且不利影響最小時，對軟件熵的認識是最有用的。
這並不意味著每個組織都應該投入資源來限制其產品中熵的增長。 今天開發的許多軟件——尤其是面向消費者的軟件——的預期壽命相對較短，可能只有幾年。 在這種情況下，它的利益相關者不需要考慮軟件熵的影響，因為在整個系統被丟棄之前它很少會成為一個嚴重的障礙。 然而，考慮軟件熵的影響的理由不那麼明顯。
考慮運行互聯網路由基礎設施或將資金從一個銀行賬戶轉移到另一個銀行賬戶的軟件。 在任何給定時間，生產中都有該軟件的一個或多個版本，並且可以以相當高的準確性記錄它們的集體行為。
系統的風險承受能力是衡量從一次開發迭代到下一次開發迭代我們可以輕鬆允許的意外行為的數量和類型。 對於剛剛提到的系統類型，風險承受能力遠低於路由電話的軟件。 反過來，該軟件的風險承受能力低於驅動許多商業網站購物車的軟件。
風險容忍度和軟件熵是相關的，因為軟件熵必須最小，以確保在下一次開發迭代期間我們將保持在系統的風險容忍度內。
軟件熵的來源
軟件熵源於缺乏知識。 它源於我們的共同假設與現有系統的實際行為之間的差異。 這一事實解釋了為什麼軟件熵僅在修改現有系統的情況下才有意義； 這是唯一一次我們的缺乏理解會產生任何實際影響。 軟件熵在一個系統中找到了最肥沃的土壤，其細節無法被一個人理解，而是分散在開發團隊中。 時間也是一個強大的知識擦除器。
代碼是一系列邏輯斷言的表達。 當軟件的行為（以及它的代碼）不符合它打算表達的邏輯時，我們可以說它的固有熵。 這種情況可以通過三種方式出現：邏輯是眾所周知的並且與其表達有分歧，對代碼要表達的邏輯有多種理解，或者邏輯不為人所知。
第一種情況——邏輯是眾所周知的，但與當前的表達方式不同——是最容易解決的，但也是最不常見的。 只有由兩個參與者（一個開發人員和一個負責業務計劃的人）維護的非常小的系統才屬於這一類。
第二種情況——邏輯不為人知——很少見。 出於所有意圖和目的，開發迭代甚至無法開始。 如果在某個時候所有利益相關者都同意，那麼他們很可能會面臨第一種情況。
人類的思維解釋它的經驗，有效地過濾和修改它們，試圖將它們融入個人框架。 在缺乏有效的開發習慣（基於自由交流思想、相互尊重和明確的期望）的情況下，對於系統當前如何運作的解釋可能與團隊成員一樣多。 團隊對當前開發迭代的目標本身可能存在爭議。
許多開發人員通過加強自己對他們的需求以及系統“應該”如何組織的獨特理解來保護自己免受這種情況的影響。 另一方面，經理和其他利益相關者可能會在不知不覺中尋求改變其他團隊成員的假設，這是一種錯誤的嘗試，以使他們自己的生活更輕鬆。
我們現在已經找到了最常見的軟件熵來源：對系統要表達的邏輯有多種不完整的解釋。 由於這種邏輯只有一種表現形式，因此這種情況從定義上講是有問題的。
這種缺乏知識是如何產生的？ 無能是一種方式。 正如我們已經看到的那樣，對下一次開發迭代的目標缺乏共識是另一回事。 但還有其他因素需要考慮。 一個組織可能聲稱採用一種開發方法，但隨後隨意放棄了它的部分或全部方面。 然後，軟件開發人員的任務是完成模糊的任務，通常可以解釋。 實施改變其開發方法的組織特別容易受到這種現象的影響，儘管它們絕不是唯一的。 管理層不知道或無法解決的個人衝突也可能導致期望和結果之間的危險分歧。
我們失去關於產品的技術知識還有第二種更重要的方式：轉移。 即使對於最精通的作家來說，在紙上捕捉技術知識也是一項挑戰。 原因是轉錄什麼與如何轉錄同樣重要。 如果沒有適當的紀律，技術作家可能會記錄太多信息。 或者，他們可能會做出導致他們忽略要點的假設。 生成後，技術文檔必須仔細更新，這對於許多幾乎在文檔一寫完就忘記跟踪的組織來說是一個困難的提議。 由於這些困難，技術知識很少單獨以文檔形式傳遞，而且還以配對或其他形式的密切、人與人之間的互動形式傳遞。
每當積極的參與者離開開發團隊時，軟件熵就會突飛猛進。 他們隨身攜帶了大量寶貴的專業知識。 複製這種專有技術是不可能的，並且接近它需要相當大的努力。 然而，只要有足夠的注意力和資源，就可以保留足夠的知識，從而可以最小化系統熵的增長。
熵還有其他來源，但這些來源相對較小。 例如，軟件腐爛是系統意外受到環境變化影響的過程。 我們可以想到它所依賴的第三方軟件（例如庫），但軟件腐爛還有其他更隱蔽的原因，通常是由於系統所基於的假設發生了變化。 例如，如果系統在設計時對內存的可用性進行了某些假設，那麼如果可用內存減少，它可能會在意想不到的時刻開始出現故障。
如何計算熵：為 C、S 和 I 賦值
I 是軟件系統中未解決的行為問題的數量，包括缺少承諾的功能。 這是一個已知數量，通常在 JIRA 等系統中進行跟踪。 I 的值直接來源於它。
C 是感知概率，即當範圍內的工作單元已經實施時，下一次迭代中實際未解決問題的數量 I1 將大於現在的估計。 該值位於域 0 <= C <= 1 中。
有人可能會爭辯說，概率 C 正是軟件熵旨在衡量的。 但是，該值與我們對軟件熵的測量之間存在根本差異。 某些事情會出錯的感知概率正是：它不是一個真正的價值。 然而，參與項目的人的感受是關於項目穩定性的寶貴信息來源，這一點很有用。
範圍 S 考慮了建議更改的幅度，並且必須以與 I 相同的單位表示。更大的 S 值會降低熵，因為我們正在增加建議更改的範圍。 雖然這聽起來可能違反直覺，但我們必須記住，熵是衡量系統發展如何可能無法滿足我們期望的量度。 僅僅說熵是引入問題的機會的量度是不夠的。 我們自然會嘗試和預測風險，並在我們的計劃中考慮它們（因此在我們對 I1 的估計中，它可能會增加超過0 ）。 顯然，我們對承擔較大的變更範圍越有信心，可以說系統中的熵就越少——除非那些計劃變更和/或執行變更的人不稱職。 然而，這種可能性可能反映在
請注意，我們不需要嘗試指定 I 1的實際值與其期望值之間的差異大小。 如果我們在製定計劃時假設我們的計劃是正確的，那麼假設我們可以預測結果不符合我們期望的程度也是不合理的； 我們只能指定它不會的感知機會 C。 然而，實際值 I 1與其期望值的差異程度是以導出值
理論上，I 有可能是負值。 然而，在實踐中，這種情況永遠不會發生； 我們通常不會意外地解決問題。
C 是一個主觀值。 它存在於開發迭代參與者的腦海中，可以通過輪詢他們並平均結果來推斷。 應該以積極的方式提出這個問題。 例如： “在 0 到 10 的範圍內，10 最有可能，您如何估計團隊在這次開發迭代中實現其所有目標的機會？”
請注意，問題是針對整個團隊的目標而不是子集提出的。 響應為 10 表示 C 值為 0，而響應為 7 表示值為 0.3。 在較大的團隊中，每個響應可能會根據相關因素進行加權，例如個人參與項目的時間以及他們實際花費了多少時間。 然而，能力不應成為衡量答复的一個因素。 不久之後，即使是團隊中的初級成員也會感覺到它在實現目標方面的有效性。 足夠大的團隊可能希望在平均剩餘部分之前丟棄報告的最高值和最低值。
詢問專業人士他們的團隊失敗的可能性有多大是一個敏感且具有挑釁性的提議。 然而，這正是任何希望量化熵的組織需要提出的問題。 為了確保誠實的回答，參與者應該匿名給出他們對 C 的估計，而不用擔心受到影響，即使他們報告的值非常高。
S 必須在與
請注意，我們不將修補程序或其他未計劃的生產版本視為定義開發迭代的範圍，也不應從
這種方法的困難在於，必須先進行一段時間的發現和分析，然後才能將錯誤分解為故事。 因此，I 的真實值只能在延遲後定義。 此外，對 C 的輪詢自然會在每個 sprint 開始時發生。 因此，獲得的結果必須再次在整個發布的跨度上進行平均。 儘管存在這些困難，但任何採用敏捷方法方面的團隊都可能發現故事是量化 S（因此也是
今天還有其他開發方法在使用。 無論採用何種方法，測量軟件熵的原則都是一樣的：軟件熵應該在發佈到生產之間進行測量，S 和 I 應該在相同的“工作單元”中測量，C 的估計應該從直接參與者那裡獲取。一種不具威脅性且最好是匿名的方式。
減少 E 的增長
一個系統的知識一旦丟失，就永遠無法恢復。 因此，不能減少軟件熵。 我們所能做的就是抑制它的增長。
在軟件開發過程中採取適當的措施可以限制熵的增長。 敏捷開發的結對編程方面在這方面特別有用。 因為在編寫代碼時涉及到多個開發人員，所以分發了基本細節的知識，並減輕了離職團隊成員的影響。
另一個有用的做法是製作結構良好且易於使用的文檔，尤其是在採用瀑布方法的組織中。 此類文檔必須以每個人都理解的嚴格和明確定義的原則為後盾。 依靠文檔作為主要交流手段和保護技術知識的組織非常適合這種方法。 只有當沒有關於如何編寫和使用內部書面文檔的指導或培訓時——在使用 RAD 或敏捷方法的年輕組織中經常出現這種情況——它們的價值才會受到質疑。
有兩種方法可以減少系統中熵的增長：執行旨在減少
第一個涉及重構。 旨在減少 I 的操作在本質上往往是技術性的，讀者可能已經熟悉了。 必須進行開發迭代。 此迭代中旨在減少熵增長的部分不會帶來任何切實的商業利益，同時會消耗時間和資源。 這一事實通常使減少熵的增長在任何組織中都成為一種硬推銷。
降低 C 的值是一種更有效的策略，因為效果是長期的。 此外，C 是對 I 與 S 比率增長的重要檢查。降低 C 的行動往往集中在人類的行為和思維上。 儘管這些行動本身可能不需要開發迭代，但隨著參與者接受並適應新程序，它們將減慢後續迭代。 隨著項目參與者和利益相關者的不同目標突然暴露出來，就應該進行哪些改進達成一致這一看似簡單的行為本身就充滿了危險。
包起來
軟件熵是更改現有軟件將導致意外問題、未實現目標或兩者兼而有之的風險。
儘管在首次創建軟件時可以忽略不計，但軟件熵會隨著每次開發迭代而增長。 如果任其發展，軟件熵最終將導致進一步的發展停滯。
然而，並不是每個項目都應該考慮軟件熵的影響。 在熵產生明顯和有害影響之前，許多系統將停止生產。 對於那些生命週期足夠長以至於熵構成可信風險的人來說，建立對它的認識並衡量其程度，雖然仍然很低，但提供了一種確保發展不會過早中斷的方法。
一旦系統完全被軟件熵的影響所淹沒，就無法再進行任何更改，開發基本上就結束了。