1.6 隨處可見的隨機(jī)復(fù)雜度

下面通過案例說明隨機(jī)復(fù)雜度的表現(xiàn)形式。

案例1：如圖1-5所示，服務(wù)A和服務(wù)B調(diào)用服務(wù)S，開始的時(shí)候一切正常，相安無事。后來，增加的服務(wù)C也調(diào)用服務(wù)S，這時(shí)發(fā)現(xiàn)服務(wù)S有一個(gè)實(shí)現(xiàn)上的缺陷。此時(shí)，理論上應(yīng)該修改服務(wù)S，但由于負(fù)責(zé)服務(wù)S的團(tuán)隊(duì)怕影響其他現(xiàn)有服務(wù)，因此缺乏解決該問題的動(dòng)力，或者由于負(fù)責(zé)服務(wù)A的團(tuán)隊(duì)正忙于其他新特性的研發(fā)，因此服務(wù)C的團(tuán)隊(duì)不得不“曲線救國”，在自己的服務(wù)C中實(shí)現(xiàn)變通。一段時(shí)間以后，服務(wù)B也發(fā)現(xiàn)了服務(wù)S的缺陷，同樣也是自己采用了變通方法。但是服務(wù)B和服務(wù)C采用的變通方法可能并不相同，這就為以后的維護(hù)挖了“坑”，這些都是在積累系統(tǒng)的隨機(jī)復(fù)雜度。

圖1-5 隨機(jī)復(fù)雜度的表現(xiàn)形式案例

案例2：團(tuán)隊(duì)成員因?yàn)閭€(gè)人喜好，在一個(gè)全部是Java體系的系統(tǒng)中加入Node.js的組件，這對(duì)于其他不熟悉Node.js的成員來說，就是純粹多出來的隨機(jī)復(fù)雜度，而且一旦引入后面再想去掉就難了。

案例3：團(tuán)隊(duì)的不同成員為了快速實(shí)現(xiàn)通用功能，使用了能實(shí)現(xiàn)相同功能的不同組件，或者即使使用了相同的組件，但是使用的組件版本也各不相同，這種不一致性也直接產(chǎn)生了本不應(yīng)該存在的隨機(jī)復(fù)雜度。

案例4：團(tuán)隊(duì)新人不熟悉系統(tǒng)，但急于實(shí)現(xiàn)一個(gè)新特性，又不想對(duì)系統(tǒng)其他部分產(chǎn)生影響，就會(huì)很自然地在原有代碼的基礎(chǔ)上添加if-else判斷，甚至直接復(fù)制代碼并在復(fù)制的代碼上做修改，而不是去調(diào)整系統(tǒng)設(shè)計(jì)以適應(yīng)新的問題空間，這種做法看似“短、平、快”，實(shí)則引入了隨機(jī)復(fù)雜度，為以后的維護(hù)挖了“坑”。

案例5：缺乏領(lǐng)域建模，同一個(gè)業(yè)務(wù)領(lǐng)域概念在不同模塊中使用了不同的命名，但是領(lǐng)域內(nèi)涵完全一致。更糟的是，在不同模塊中的實(shí)現(xiàn)又不同，各自還加入了差異的屬性，這樣，后續(xù)對(duì)模塊的理解和維護(hù)成本都會(huì)變得更加復(fù)雜。

案例6：由于項(xiàng)目時(shí)間緊張，因此設(shè)計(jì)的變更直接在代碼上修改，使得設(shè)計(jì)文檔和實(shí)現(xiàn)不匹配，這也是增加隨機(jī)復(fù)雜度的一個(gè)重要因素。

類似的例子，筆者相信你們可以列舉更多。

隨機(jī)復(fù)雜度是我們需要重點(diǎn)關(guān)注的，其中的短視效應(yīng)表現(xiàn)為急功近利，這種做法會(huì)快速增加系統(tǒng)的技術(shù)債務(wù)使架構(gòu)腐化加速，由此造成后續(xù)研發(fā)認(rèn)知負(fù)荷的增加，更多的協(xié)作也會(huì)造成協(xié)同復(fù)雜化，進(jìn)而降低研發(fā)效能。當(dāng)研發(fā)效能降低時(shí)，工程師就更傾向于使用急功近利的奇技淫巧來實(shí)現(xiàn)交付業(yè)務(wù)，最終形成惡性循環(huán)。