簡介：軟件的復雜性，是一個很泛的概念。但是一直都是開發過程中的一個難題，本文旨在探討如何去從容應對復雜性。
作者 | 無涯
來源 | 阿裏技術公眾號
軟件的復雜性，是一個很泛的概念。
但是一直都是開發過程中的一個難題，本文旨在探討如何去從容應對復雜性。
一 軟件的熵增、構造定律
1 熵增定律
熵的概念最早起源於物理學，熱力學第二定律（又稱“熵增定律”），錶明瞭在自然過程中，一個孤立的係統總是從最初的集中、有序的排列狀態，趨嚮於分散、混亂和無序；當熵達到最大時，係統就會處於一種靜寂狀態。
軟件係統亦是如此， 在軟件係統的維護過程中。軟件的生命力會從最初的集中、有序的排列狀態，逐步趨嚮復雜、無序狀態，直到軟件不可維護而被迫下綫或重構。
2 構造定律
自然界是如何應對這復雜性？
這在物理中被稱為構造定律 （Constructal Law), 是由Adrian Bejan於1995提齣的：
For a finite-size system to persist in time (to live), it must evolve in such a way that it provides easier access to the imposed currents that flow through it.
對於一個有限大小的持續活動的係統，它必須以這種方式發展演進：它提供瞭一種在自身元素之間更容易訪問的流動方式。
這個定理在自然界中比比皆是，最典型的比如水循環係統，海水蒸發到大氣，下雨時降落在地麵，一部分滲入地麵流入江河，一部分繼續蒸發，不斷循環。這種自發性質的設計反映瞭這一趨勢：他們允許實體或事物更容易地流動 - 以最少的能量消耗到達最遠的地方，就連街道和道路這些人為地構建物體，往往也是有排序的模式，以提供最大的靈活性。
二 如何應對軟件係統的復雜性？
軟件係統的復雜性往往是被低估的。復雜越高，開發人員會感到不安。對其的理解認知負荷代價就越高，我們就更不快樂。真正的挑戰是在構建我們的係統時要保持其有序以及工程師的生産方式。
Ousterhout教授在《軟件設計的哲學》書中提到：軟件設計的最大目標，就是降低復雜度（complexity）。
就是設計符閤業務的構造定律的演進方式，一種可以以最小的開發維護成本， 使業務更快更好的流動發展的方式。
三 軟件復雜性來自哪裏， 如何解決？
1 不確定性的來源
1、業務的不確定性
2、技術的不確定性
3、人員流動的不確定性
2 如何麵對不確定性
麵對外部的確定性，轉化為內核的確定性。
麵對外部的不確定性，找到穩定的內核基礎。
專注問題域
當下互聯網發展速度是迅猛的， 軟件的形態也在不斷的變化演進。麵對未來的業務及變化，橫嚮業務與縱嚮業務的發展都是不確定性的。
Robert C. Martin提到的BDUF，永遠不要想著在開始就設計好瞭全部的事情(big design up front)，一定要避免過度設計。除非能夠十分確認的可預見變化， 業務邊界，否則專注解決當前1-2年內業務變化設計, 講好當下的用戶故事，專注解決眼前的問題域。 麵嚮不確定設計，增量敏捷開發。
確認穩定的係統內核
隨著業務的變化、係統設計也要持續演進升級。沒有一開始就完美的架構， 好的架構設計一定演化來的，不是一開始就設計齣來的。
一個健康公司的成長，業務橫嚮、縱嚮會發展的會越來越復雜，支持業務的係統也一定會越來越復雜。
係統演進過程中的成本，會受到最開始的設計、係統最初的內核影響的。麵對外部業務的不確定性， 技術的不確定性，外部依賴的不確定性。一個穩定的內核應該盡量把外部的不確定性隔離。
- 業務與技術的隔離
以業務為核心，分離業務復雜度和技術復雜度。
- 內部係統與外部依賴的隔離
- 係統中常變部分與不常變部分的隔離
- 隔離復雜性（把復雜性的部分隔離在一個模塊，盡量不與其他模塊互動）
3 無序性
係統和代碼像多個綫團一樣散落一地一樣，混亂不堪，毫無頭緒。
4 如何麵對無序性
1、統一認知（秩序化）
2、係統清晰明瞭的結構（結構化）
3、業務開發流程化（標準化）
注：這裏說的流程化並非指必須使用類似BPM的流程編排係統，
而是指對於一個需求，業務開發有一定的順序， 有規劃的先做一部分事情，開發哪一個模塊再去做剩下的工作，是可以流程化的。
5 規模
業務規模的膨脹以及開發團隊規模的膨脹，都會帶來係統的復雜性提升。
6 如何麵對規模膨脹帶來的復雜性
1、業務隔離， 分而治之
2、專注産品核心競爭力的發展
3、場景分層
關鍵場景
投入更多的開發、測試資源、業務資源(比如單元測試覆蓋率在90%以上)在關鍵場景。
普通場景
更快，更低成本、更少資源投入地完成普通場景的迭代
7 認知成本
是指開發人員需要多少知識纔能完成一項任務。
在引入新的變化時，要考慮到帶來的好處是否大於係統認知成本的提升，比如：之前提到的BPM流程編排引擎，如果對係統帶來的好處不夠多也是增加認知成本的一種。
不閤適的設計模式也是增加認知成本的一種，前台同學吐槽的中台架構比較高的學習成本， 也是認知成本的一種。
8 如何降低認知成本
1、係統與現實業務更自然真實的映射，對業務抽象建模
軟件工程師實際上隻在做一件事情，即把現實中的問題搬到計算機上，通過信息化提升生産力。
2、代碼的含義清晰，不模糊
3、代碼的整潔度
4、係統的有序性， 架構清晰
5、避免過度設計
6、減少復雜、重復概念， 降低學習成本
7、謹慎引入會帶來係統復雜性的變化
四 應對復雜性的利器
1 領域驅動設計——DDD
DDD是把業務模型翻譯成係統架構設計的一種方式, 領域模型是對業務模型的抽象。
不是所有的業務服務都閤適做DDD架構，DDD閤適産品化，可持續迭代，業務邏輯足夠復雜的業務係統，小規模的係統與簡單業務不適閤使用，畢竟相比較於MVC架構，認知成本和開發成本會大不少。但是DDD裏麵的一些戰略思想我認為還是較為通用的。
對通用語言的提煉和推廣
清晰語言認知， 比如之前在詳情裝修係統中：
ItemTemplate : 錶示當前具體的裝修頁麵
ItemDescTemplate、Template，兩個都能錶示模闆概概念
剛開始接觸這塊的時候比較難理解這一塊邏輯，之後在負責設計詳情編輯器大融閤這個項目時第一件事就是團隊內先重新統一認知。
- 裝修頁麵統一使用 —— Page概念
- 模闆統一使用 —— Template概念
不將模闆和頁麵的概念糅雜在一起，含糊不清，避免重復和混亂的概念定義。
貧血模型和充血模型
1）貧血模型
貧血模型的基本特徵是：它第一眼看起來還真像這麼迴事兒。項目中有許多對象，它們的命名都是根據領域模型來的。然而當你真正檢視這些對象的行為時，會發現它們基本上沒有任何行為，僅僅是一堆getter/setter方法。
這些貧血對象在設計之初就被定義為隻能包含數據，不能加入領域邏輯；所有的業務邏輯是放在所謂的業務層（xxxService, xxxManager對象中)，需要使用這些模型來傳遞數據。
@Data
public class Person {
/**
* 姓名
*/
private String name;
/**
* 年齡
*/
private Integer age;
/**
* 生日
*/
private Date birthday;
/**
* 當前狀態
*/
private Stauts stauts;
}
public class PersonServiceImpl implements PersonService {
public void sleep(Person person) {
person.setStauts(SleepStatus.get());
}
public void setAgeByBirth(Person person) {
Date birthday = person.getBirthday();
if (currentDate.before(birthday)) {
throw new IllegalArgumentException("The birthday is before Now,It's unbelievable");
}
int yearNow = cal.get(Calendar.YEAR);
int dayBirth = bir.get(Calendar.DAY_OF_MONTH);
/*大概計算， 忽略月份等，年齡是當前年減去齣生年*/
int age = yearNow - yearBirth;
person.setAge(age);
}
}
}
public class WorkServiceImpl implements WorkService{
public void code(Person person) {
person.setStauts(CodeStatus.get());
}
}
這一段代碼就是貧血對象的處理過程，Person類， 通過PersonService、WorkingService去控製Person的行為，第一眼看起來像是沒什麼問題，但是真正去思考整個流程。WorkingService， PersonService到底是什麼樣的存在？與真實世界邏輯相比， 過於抽象。基於貧血模型的傳統開發模式，將數據與業務邏輯分離，違反瞭 OOP 的封裝特性，實際上是一種麵嚮過程的編程風格。但是，現在幾乎所有的 Web 項目，都是基於這種貧血模型的開發模式，甚至連 Java Spring 框架的官方 demo，都是按照這種開發模式來編寫的。
麵嚮過程編程風格有種種弊端，比如，數據和操作分離之後，數據本身的操作就不受限製瞭。任何代碼都可以隨意修改數據。
2）充血模型
充血模型是一種有行為的模型，模型中狀態的改變隻能通過模型上的行為來觸發，同時所有的約束及業務邏輯都收斂在模型上。
@Data
public class Person extends Entity {
/**
* 姓名
*/
private String name;
/**
* 年齡
*/
private Integer age;
/**
* 生日
*/
private Date birthday;
/**
* 當前狀態
*/
private Stauts stauts;
public void code() {
this.setStauts(CodeStatus.get());
}
public void sleep() {
this.setStauts(SleepStatus.get());
}
public void setAgeByBirth() {
Date birthday = this.getBirthday();
Calendar currentDate = Calendar.getInstance();
if (currentDate.before(birthday)) {
throw new IllegalArgumentException("The birthday is before Now,It's unbelievable");
}
int yearNow = currentDate.get(Calendar.YEAR);
int yearBirth = birthday.getYear();
/*粗略計算， 忽略月份等，年齡是當前年減去齣生年*/
int age = yearNow - yearBirth;
this.setAge(age);
}
}
3）貧血模型和充血模型的區彆
/**
* 貧血模型
*/
public class Client {
@Resource
private PersonService personService;
@Resource
private WorkService workService;
public void test() {
Person person = new Person();
personService.setAgeByBirth(person);
workService.code(person);
personService.sleep(person);
}
}
/**
* 充血模型
*/
public class Client {
public void test() {
Person person = new Person();
person.setAgeByBirth();
person.code();
person.sleep();
}
}
上麵兩段代碼很明顯第二段的認知成本更低， 這在滿是Service，Manage 的係統下更為明顯，Person的行為交由自己去管理， 而不是交給各種Service去管理。
貧血模型是事務腳本模式
貧血模型相對簡單，模型上隻有數據沒有行為，業務邏輯由xxxService、xxxManger等類來承載，相對來說比較直接，針對簡單的業務，貧血模型可以快速的完成交付，但後期的維護成本比較高，很容易變成我們所說的麵條代碼。
充血模型是領域模型模式
充血模型的實現相對比較復雜，但所有邏輯都由各自的類來負責，職責比較清晰，方便後期的迭代與維護。
麵嚮對象設計主張將數據和行為綁定在一起也就是充血模型，而貧血領域模型則更像是一種麵嚮過程設計，很多人認為這些貧血領域對象是真正的對象，從而徹底誤解瞭麵嚮對象設計的涵義。
Martin Fowler 曾經和 Eric Evans 聊天談到它時，都覺得這個模型似乎越來越流行瞭。作為領域模型的推廣者，他們覺得這不是一件好事，極力反對這種做法。
貧血領域模型的根本問題是，它引入瞭領域模型設計的所有成本，卻沒有帶來任何好處。最主要的成本是將對象映射到數據庫中，從而産生瞭一個O/R（對象關係）映射層。
隻有當你充分使用瞭麵嚮對象設計來組織復雜的業務邏輯後，這一成本纔能夠被抵消。如果將所有行為都寫入到Service對象，那最終你會得到一組事務處理腳本，從而錯過瞭領域模型帶來的好處。而且當業務足夠復雜時， 你將會得到一堆爆炸的事務處理腳本。
對業務的理解和抽象
限定業務邊界，對業務進行與現實更自然的理解和抽象，數據模型與業務模型隔離，把業務映射成為領域模型沉澱在係統中。
結構與防腐層
User Interfaces
負責對外交互, 提供對外遠程接口
application
應用程序執行其任務所需的代碼。
它協調域層對象以執行實際任務。
該層適用於跨事務、安全檢查和高級日誌記錄。
domain
負責錶達業務概念。
對業務的分解，抽象，建模 。
業務邏輯、程序的核心。
防腐層接口放在這裏。
infrastucture
為其他層提供通用的技術能力。如repository的implementation（ibatis，hibernate, nosql），中間件服務等anti-corruption layer的implementation 防腐層實現放在這裏。
防腐層的作用：
封裝三方服務。
隔離內部係統對外部的依賴。
讓隱性概念顯性化
文檔與注釋可能會失去實時性（文檔、注釋沒有人持續維護），但是綫上生産代碼是業務邏輯最真實的展現，減少代碼中模糊的地方，讓業務邏輯顯性化體現齣來，提升代碼清晰度。
if (itemDO != null && MapUtils.isNotEmpty(itemDO.getFeatures()) && itemDO.getFeatures().containsKey(ITEM_PC_DESCRIPTION_PUSH)) {
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_PC_TEMPLATEID, "" + templateId);
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_PC_PUSH, "" + pcContent.hashCode());
} else {
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_PC_TEMPLATEID, "" + templateId);
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_WL_TEMPLATEID, "" + templateId);
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_PC_PUSH, "" + pcContent.hashCode());
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_WL_PUSH, "" + content.hashCode());
}
比如這一段代碼就把判斷裏的業務邏輯隱藏瞭起來，這段代碼其實的業務邏輯是這樣， 判斷商品是否有PC裝修內容。如果有做一些操作， 如果沒有做一些操作，將hasPCContent 這個邏輯錶現齣來， 一眼就能看齣來大概的業務邏輯，讓業務邏輯顯現化，能讓代碼更清晰。可以改寫成這樣：
boolean hasPCContent = itemDO != null && MapUtils.isNotEmpty(itemDO.getFeatures()) && itemDO.getFeatures().containsKey(ITEM_PC_DESCRIPTION_PUSH);
if (hasPCContent) {
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_PC_TEMPLATEID, "" + templateId);
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_PC_PUSH, "" + pcContent.hashCode());
} else {
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_PC_TEMPLATEID, "" + templateId);
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_WL_TEMPLATEID, "" + templateId);
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_PC_PUSH, "" + pcContent.hashCode());
itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_WL_PUSH, "" + content.hashCode());
}
2 簡單設計原則——《Clean Code》
1、保持係統最大可測試
隻要係統可測試並且越豐富的單元測試越會導嚮保持類短小且目的單一的設計方案，遵循單一職責的類，測試起來比較簡單。
遵循有關編寫測試並持續運行測試的簡單、明確規則，係統就會更貼近OO低偶爾度，高內聚度的目標。編寫測試越多，就越會遵循DIP之類的規則，編寫最大可測試可改進並走嚮更好的係統設計。
2、避免重復
重復是擁有良好設計係統的大敵。它代錶著額外的工作、額外的風險和額外且不必要的復雜度。除瞭雷同的代碼，功能類似的方法也可以進行包裝減少重復，“小規模復用”可大量降低係統復雜性。要想實現大規模復用，必須理解如何實現小規模復用。
共性的抽取也會使代碼更好的符閤單一職責原則。
3、更清晰的錶達開發者的意圖
軟件項目的主要成本在於長期維護，當係統變得越來越復雜，開發者就需要越來越多的時間來理解他，而且也極有可能誤解。
所以作者需要將代碼寫的更清晰：選用好名稱、保持函數和類的短小、采用標準命名法、標準的設計模式名，編寫良好的單元測試。用心是最珍貴的資源。
4、盡可能減少類和方法
如果過度使用以上原則，為瞭保持類的函數短小，我們可能會造齣太多細小的類和方法。所以這條規則也主張函數和類的數量要少。
如應當為每個類創建接口、字段和行為必須切分到數據類和行為類中。應該抵製這類教條，采用更實用的手段。目標是在保持函數和類短小的同時，保持係統的短小精悍。不過這是優先級最低的一條。更重要的是測試，消除重復和清晰錶達。
五 最後
總而言之，做業務開發其實一點也不簡單，麵對不確定性的問題域，復雜的業務變化，
如何更好的理解和抽象業務，如何更優雅的應對復雜性，一直都是軟件開發的一個難題。
在對抗軟件熵增，尋找對抗軟件復雜性，符閤業務的構造定律的演進方式，我們一直都在路上。
本文為阿裏雲原創內容，未經允許不得轉載。
責任編輯：
