本文要點：
- 唯一不變的就是變化。這一點在軟件工程中表現得尤爲明顯，在軟件工程中，開發人員的日常工作就是修修補補、調調改改，甚至是重新構建他們所負責的系統。
- 隨着應用程序的增長和團隊規模的擴大，仍能保持對該軟件清晰的理解變得更具挑戰性。複雜性會影響工程師理解軟件並根據需要做有效的變更。
- 可理解性這一概念，即系統所呈現的內容應該使工程師能夠很容易理解它。一個系統越容易被人理解，工程師就越容易以可預測和安全的方式改變它。
- 如果某一系統符合完整、簡潔、清晰、有條理這些標準，那麼它就是可理解的。
- 可理解性和可觀察性是互補的，但後者更側重於兩件事：在系統行爲不正常時發出警報的能力，並幫助識別原因，以便恢復正常服務；以及，幫助識別性能瓶頸的能力，以便分配額外的資源或通知相關團隊。
2500年前，赫拉克利特說過：“唯一不變的就是變化。”這一點在軟件工程中表現得尤爲明顯，在軟件工程中，開發人員的日常工作就是修修補補、調調改改，甚至是重新構建他們負責的系統。還有一個方面使軟件工程在人類學科中顯得特別獨特，那就是計算機科學定義了一些人爲邊界，在此邊界內我們有着高度的自由來決定我們的工作。
我們能夠有效地運用這麼強大的力量，卻常常在一個非常令人意想不到的地方做不到位，那就是我們認識自己所創造的東西的能力。隨着應用程序的發展和團隊規模的擴大，對軟件本身保持清晰的理解變得更加困難，導致項目像聖經中的巴別塔一樣崩潰。
舉個恰當的例子
大多數商業軟件工程任務都不是從頭開始的。現在已有一款應用程序，它是使用某種計算機語言編寫的，依賴於一組框架和類庫，並運行在某些操作系統之上。
我們自己（或我們的團隊）負責變更現有的這款應用程序，以滿足某些需求，比如開發一個新特性，修復一處已有的bug，等等。同時，我們需要繼續滿足所有現有的文檔化或非文檔化的需求，並儘可能維持現有的表現。
每一個初級軟件工程師在這項任務上第一天開展工作就會發現，編寫一段代碼解決一個簡單的計算機科學問題（或者從StackOverflow複製人家的答案）的複雜程度遠不及在一個龐大而複雜的系統上解決同樣的問題。
可理解性是什麼?
借用金融行業的說法，讓我們來定義可理解性：“即系統所呈現的內容應該使工程師能夠很容易地理解它。”一個系統越容易被人理解，工程師就越容易以可預測和安全的方式改變它。
進一步推導，我們可以說，如果一個系統符合以下標準，它是可理解的：
- 完整。系統必須使用一組預定義的來源（源代碼、文檔等）來呈現，以涵蓋所有的關鍵信息。任何重要的信息都不能丟給工程師去想象。
- 簡潔。系統源代碼不應該將用戶淹沒於過多的細節中。關注點分離和抽象應該能就這一點發揮很好的作用，它們使工程師能夠專注於手頭的任務。
- 明確。使用便於讀者瀏覽的展示方法。一致性、編碼約定、源代碼格式、代碼註釋和語法高亮顯示能夠使這一點產生天壤之別。
- 有條理。工程師應該能夠很容易在系統中找到相互引用的信息。模塊化、軟件文檔、源代碼導航控件和源代碼管理工具使工程師們能夠做到這一點。
運行時的可理解性
隨着軟件即服務（SaaS）和其他新的軟件交付範式的興起，許多組織正在實踐整體對軟件負責，授權工程師在整個生命週期中對應用程序負責。
在這樣的組織中，可理解性以一種更爲強力的形式表現出來，它決定了工程師對軟件如何運行以及應用程序的客戶如何利用軟件有多麼深入的理解。
因此，決定這麼做的團隊可以獲取諸如使用模式、真實的輸入和輸出以及實際性能和可用性統計數據等非常有價值的信息。
可觀察性不是可理解性
閱讀本文時，你可能會想，重點應該是可觀察性和監視工具吧。很遺憾，事實並非如此。這些工具是爲了支持更傳統的IT問題，主要關注於：
- 當系統出現不正常行爲時發出警報，並幫助識別根源，以便恢復正常服務。
- 識別性能瓶頸，以便分配額外的資源或通知相關團隊。
- 爲運維、安全性和支持目的保留詳細的事件日誌。
這些都是很好的用例，IT從很早以前就已經開始在處理這些用例了，而且由於它們有着非常清晰明確的投資回報率，所以許多供應商都提供了很好的工具來解決這些問題。然而，這些不是軟件工程團隊所要負責的用例，這些工具從來就沒有對他們起到什麼幫助作用。
所有這些IT用例的共同點是，這些具備系統方面常識的人需要確切地知道系統在特定實例中的行爲，以便他們能夠適當地做出響應。這意味着我們就一組預定義事件收集相關數據，這些數據往往是關於系統如何與周圍的世界交互的。
而反之，軟件工程團隊對系統的內部工作方式有深入的瞭解，並希望更多地瞭解它是如何工作的。基於他們對系統所做的特定變更，每天（甚至是每小時）收集所需瞭解的數據。
戰勝複雜性
軟件隨着不斷地發展變化，變得越來越複雜。很大一部分複雜性是內在的，原因很簡單，因爲事實上業務需求的數量就是在不斷地增長。除此之外的複雜性是不必要的，隨着時間的推移，應用程序被改變了用途，再加上糟糕的設計選擇，造成了這些複雜性，通常它們被稱爲技術債務。
不管複雜性來自哪裏，它都會影響工程師理解軟件並根據需要有效更改軟件。人員流動會造成一定的知識損失，這往往進一步加劇了這一問題。
當然，在軟件行業中大家都很清楚，必須儘量減少軟件的複雜性。軟件越複雜，開發新功能的成本就越高，系統的整體質量就會越低。關於如何構建軟件能將複雜性降到最低，並使系統和團隊更好地擴展，已經有人寫過很多文章。
新軟件的可理解性
當你正在開發新的軟件時，可能會忽視可理解性，而偏愛它的另一面：複雜性。如果專注於避免和減少複雜性，你將自然而然地使軟件擁有可理解性。幸運的是，無數軟件開發工具和技術都特別關注軟件的複雜性。
首先，要有一支高素質的員工隊伍。富有才華的工程師們利用他們的經驗在軟件源代碼和架構中以簡單優雅的方式表達複雜的業務問題，創造出更容易理解的軟件。
其次，嘗試使系統儘可能小，因爲從本質上講越小的系統就越沒有那麼複雜，也更容易理解。將真正重要的業務需求作爲關注焦點，而忽略（至少是暫時忽略）那些非強制性的需求，可以從“頂層”縮減系統規模。通過使用更高層次的抽象，比如新的編程語言、高級框架和現代數據庫，通常也可以在“底層”對系統進行簡化。
最後一點同樣重要，確保有恰當的腳手架，以便在複雜性出現時予以處理。以單元測試和系統測試的形式編寫自動化測試，以確保你的工程團隊能夠安全地重構複雜性。使用高質量的觀測工具來幫助你從高層次上理解系統。自動化集成和部署流水線，使你能夠快速改進和迭代。
現有軟件的可理解性
另一方面，當涉及到現有的軟件時，我們往往接受工程團隊無法理解代碼，因爲這可謂是神藉災難。直接改變複雜性不再是提高可理解性的可行方法。
通常，你面對的遺留系統都是使用較低級別的工具編寫的，而不是現行的工具，原作者可能很久之前就已經離職了，而且沒有留下任何腳手架。面對這些必須處理的技術債務和你的工程師無法理解的“不可讀的代碼”，抱怨不會帶來任何幫助。也不要做什麼長遠的重構和遷移之夢，因爲很少有美夢成真的時候。
這就是生產調試平臺的亮點之所在。通過讓你的工程師深入瞭解他們正在與之纏鬥的代碼，使他們可以開始切入去理解它。並且他們可以通過跨環境和用例來跟蹤碎片逐步解開復雜性。
結語
現在我們對軟件開發中可理解性的重要性有了更全面的看法。一方面，我們一直都清楚，保持代碼易於閱讀和易於維護是很重要的，而軟件工程主要就是致力於實現這一目標。而現在，我們更深刻地認識到，軟件隨着時間的推移而帶來的發展變化對它有着多麼大的影響。
另一方面，我們也挑戰了這樣一個假設，認爲總是可以通過處理複雜性、設計和編寫更好、更簡單的軟件來提高可理解性。很多時候，我們發現自己是在中途登上的火車，幾乎無法控制火車是如何到達目的地的。因此，我們必須開始跟蹤和管理可理解性，將其作爲自己的關鍵度量，盡最大可能提高工程速度和質量，甚至未處於最佳條件下。
作者簡介：
Liran Haimovitch是Rookout的聯合創始人和首席技術官。他是敏捷、精益和Devops等現代軟件方法論的倡導者。Liran的熱衷於去理解軟件是如何工作的。當他不去想代碼的時候，通常會去潛水或者徒步旅行。
譯者簡介：
冬雨，小小技術宅一枚，從事研發過程改進及質量改進方面的工作，關注編程、軟件工程、敏捷、DevOps、雲計算等領域，非常樂意將國外新鮮的IT資訊和深度技術文章翻譯分享給大家。
原文鏈接：
Article: Understandability: The Most Important Metric You’re Not Tracking