前言

在進(jìn)行軟件開發(fā)時，我們常常會追求軟件的高可維護(hù)性，高可維護(hù)性意味著當(dāng)有新需求來時，系統(tǒng)易擴(kuò)展；當(dāng)出現(xiàn)bug時，開發(fā)人員易定位。而當(dāng)我們說一個系統(tǒng)的可維護(hù)性太差時，往往指的是該系統(tǒng)太過復(fù)雜，導(dǎo)致給系統(tǒng)增加新功能時容易出現(xiàn)bug，而出現(xiàn)bug之后又難以定位。

那么，軟件的復(fù)雜性又是如何定義的呢？

John Ousterhout給出的定義如下：

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

可見，軟件的復(fù)雜性是一個很泛的概念，任何使軟件難以理解和難以修改的東西，都屬于軟件的復(fù)雜性。為此，John Ousterhout提出了一個公式來度量一個系統(tǒng)的復(fù)雜性：

公式中，表示系統(tǒng)中的模塊，表示該模塊的認(rèn)知負(fù)擔(dān)（Cognitive Load，即一個模塊難以理解的程度），表示在日常開發(fā)中在該模塊花費(fèi)的開發(fā)時間。

從公式上看，一個軟件的復(fù)雜性由它的各個模塊的復(fù)雜性累加而成，而模塊復(fù)雜性 = 模塊認(rèn)知負(fù)擔(dān) * 模塊開發(fā)時間，也就是模塊的復(fù)雜性即和模塊本身有關(guān)，也跟在該模塊上花費(fèi)的開發(fā)時間有關(guān)。需要注意的是，如果一個模塊非常難以理解，但是后續(xù)開發(fā)過程中幾乎沒有涉及到它，那么它的復(fù)雜性也是很低的。

導(dǎo)致軟件復(fù)雜的原因

導(dǎo)致軟件復(fù)雜的原因可以細(xì)分出很多種來，而概括起來莫過于兩種：依賴（dependencies）和隱晦（obscurity）。前者會讓修改起來很費(fèi)勁而且容易出現(xiàn)bug，比如當(dāng)修改模塊1時，往往也涉及到模塊2、模塊3、... 的改動；后者會讓軟件難以理解，定位一個bug，甚至是僅僅讀懂一段代碼都需要花費(fèi)大量的時間。

軟件的復(fù)雜性往往伴隨著如下幾種癥狀：

霰彈式修改（Change amplification）。當(dāng)只需要修改一個功能，但又不得不對許多模塊作出改動時，我們稱之為霰彈式修改。這通常是因?yàn)槟K之間耦合過重，相互依賴太多導(dǎo)致的。 比如，有一組Web頁面，每個頁面都是一個HTML文件，每個HTML都有一個背景屬性。由于各個HTML的背景屬性都是分開定義的，因此如果需要把背景顏色從橙色修改為藍(lán)色時，就需要改動所有的HTML文件。

霰彈式修改的典型例子

認(rèn)知負(fù)擔(dān)（Cognitive load）。當(dāng)我們說一個模塊隱晦、難以理解時，它就有過重的認(rèn)知負(fù)擔(dān)，這種情況下往往需要讀者花費(fèi)大量時間才能明白該模塊的功能。比如，提供一個不帶任何注釋的calculate接口，它有2個int類型的入?yún)⒑鸵粋€int類型的返回值。從該函數(shù)的簽名上看，調(diào)用者根本無法得知函數(shù)的功能是什么，他只能通過花時間去閱讀源碼來確定函數(shù)功能后才敢去調(diào)用該函數(shù)。

int calculate(int val1, int val2);

不確定性（Unknown unknowns）。相比于前兩種癥狀，不確定性的破壞性更大，它通常指一些在開發(fā)需求時，你必須注意的，但是又無從得知的點(diǎn)。它常常是因?yàn)橐恍╇[晦的依賴導(dǎo)致的，會讓你在開發(fā)完一個需求之后感覺心里很沒譜，隱約覺得自己的代碼哪里有問題，但又不清楚問題在哪，只能祈禱在測試階段能夠暴露而不要漏洞商用階段。

如何降低軟件的復(fù)雜性

對 “戰(zhàn)術(shù)編程” Say No！

很多程序員在進(jìn)行特性開發(fā)或bug修復(fù)時，關(guān)注點(diǎn)往往是如何簡單快速讓程序跑起來，這就是典型的戰(zhàn)術(shù)編程（Tactical programming）方法，它追求的是短期的效益——節(jié)省開發(fā)時間。戰(zhàn)術(shù)編程最普遍的體現(xiàn)就是在編碼之前沒有進(jìn)行模塊設(shè)計(jì)，想到哪里就寫到哪里。戰(zhàn)術(shù)編程在系統(tǒng)前期可能會比較方便，一旦系統(tǒng)龐大起來、模塊之間的耦合變重之后，添加或修改功能、修復(fù)bug都會變得寸步難行。隨著系統(tǒng)變得越來越復(fù)雜，最后不得不對系統(tǒng)進(jìn)行重構(gòu)甚至重寫。

與戰(zhàn)術(shù)編程相對的就是戰(zhàn)略編程（Strategic programming），它追求的是長期的效益——增加系統(tǒng)可維護(hù)性。僅僅是讓程序跑起來還不足以滿足，還需要考慮程序的可維護(hù)性，讓后續(xù)在添加或修改功能、修復(fù)bug時都能夠快速響應(yīng)。因?yàn)榭紤]的點(diǎn)比較多，也就注定戰(zhàn)略編程需要花費(fèi)一定的時間去進(jìn)行模塊設(shè)計(jì)，但相比于戰(zhàn)術(shù)編程后期導(dǎo)致的問題，這一點(diǎn)時間也是完全值得的。

戰(zhàn)術(shù)編程 VS 戰(zhàn)略編程

讓模塊更“深”一點(diǎn)！

一個模塊由接口（interface）和實(shí)現(xiàn)（implementation）兩部分組成，如果把一個模塊比喻成一個矩形，那么接口就是矩形頂部的邊，而實(shí)現(xiàn)就是矩形的面積（也可以把實(shí)現(xiàn)看成是模塊提供的功能）。當(dāng)一個模塊提供的功能一定時，深模塊（Deep module）的特點(diǎn)就是矩形頂部的邊比較短，整體形狀高瘦，也即接口比較簡單；淺模塊（Shallow module）的特點(diǎn)就是矩形頂部的邊比較長，整體形狀矮胖，也即接口比較復(fù)雜。

深模塊 VS 淺模塊

模塊的使用者往往只看到接口，模塊越深，模塊暴露給調(diào)用者的信息就越少，調(diào)用者與該模塊的耦合性也就越低。因此，把模塊設(shè)計(jì)得更“深”一點(diǎn)，有助于降低系統(tǒng)的復(fù)雜性。

那么，怎樣才能設(shè)計(jì)出一個深模塊呢？

更簡單的接口

簡單的接口比簡單的實(shí)現(xiàn)更重要，更簡單的接口意味著模塊的易用性更好，調(diào)用者使用起來更方便。而簡單的實(shí)現(xiàn) + 復(fù)雜的接口這種形式，一方面影響了接口的易用性，另一方面則加深了調(diào)用者與模塊的耦合。因此，在進(jìn)行模塊設(shè)計(jì)時，最好遵守“把簡單留給別人，把復(fù)雜留給自己”的原則。

異常也屬于接口的一部分，在編碼過程中，應(yīng)該杜絕沒經(jīng)過處理，就隨意將異常往上拋的現(xiàn)象，這樣只會增加系統(tǒng)的復(fù)雜性。

更通用的接口

在設(shè)計(jì)接口時，你往往有兩種選擇：（1）設(shè)計(jì)成專用的接口；（2）設(shè)計(jì)成通用的接口。前者實(shí)現(xiàn)起來更方便，而且完全可以滿足當(dāng)前的需求，但可擴(kuò)展性低，屬于戰(zhàn)術(shù)編程；后者則需要花時間對系統(tǒng)進(jìn)行抽象，但可擴(kuò)展性高，屬于戰(zhàn)略編程。通用的接口意味著該接口適用的場景不止一個，典型的就是“一個接口，多個實(shí)現(xiàn)”的形式。

有些程序員可能會反駁，在無法預(yù)知未來變化的情況下，通用就意味著過度設(shè)計(jì)。過度通用確實(shí)屬于過度設(shè)計(jì)，但對接口進(jìn)行適度的抽象并不是，相反它可以使系統(tǒng)更有層次感，可維護(hù)性也更高。

隱藏細(xì)節(jié)

在進(jìn)行模塊設(shè)計(jì)時，還要學(xué)會區(qū)分對于調(diào)用者而言，哪些信息是重要的，哪些信息是不重要的。隱藏細(xì)節(jié)指的就是只給調(diào)用者暴露重要的信息，把不重要的細(xì)節(jié)隱藏起來。隱藏細(xì)節(jié)一則使模塊接口更簡單，二則使系統(tǒng)更易維護(hù)。

如何判斷細(xì)節(jié)對于調(diào)用者是否重要？以下有幾個例子：

1、對于Java的Map接口，重要的細(xì)節(jié)：Map中每一個元素都是由<Key, Value>組成的；不重要的細(xì)節(jié)：Map底層是如何存儲這些元素、如何實(shí)現(xiàn)線程安全等。

2、對于文件系統(tǒng)中的read函數(shù)，重要的細(xì)節(jié)：每次讀操作從哪個文件讀、讀多少字節(jié)；不重要的細(xì)節(jié)：如何切換到內(nèi)核態(tài)、如何從硬盤里讀數(shù)據(jù)等。

3、對于多線程應(yīng)用程序，重要的細(xì)節(jié)：如何創(chuàng)建一個線程；不重要的細(xì)節(jié)：多核CPU如何調(diào)度該線程。

進(jìn)行分層設(shè)計(jì)！

設(shè)計(jì)良好的軟件架構(gòu)都有一個特點(diǎn)，就是層次清晰，每一層都提供了不同的抽象，各個層次之間的依賴明確。不管是經(jīng)典的Web三層架構(gòu)、DDD所提倡的四層架構(gòu)以及六邊形架構(gòu)，抑或是所謂的Clean Architecture，都有著鮮明的層次感。

在進(jìn)行分層設(shè)計(jì)時，需要注意的是，每一層都應(yīng)該提供不同的抽象，并要盡量避免在一個模塊中出現(xiàn)大量的Pass-Through Mehod。比如在DDD的四層架構(gòu)中，領(lǐng)域?qū)犹峁┝藢︻I(lǐng)域業(yè)務(wù)邏輯的抽象，應(yīng)用層提供了對系統(tǒng)用例的抽象，接口層提供了對系統(tǒng)訪問接口的抽象，基礎(chǔ)設(shè)施層則提供對如數(shù)據(jù)庫訪問這類的基礎(chǔ)服務(wù)的抽象。

所謂的Pass-Through Mehod是指那些“在函數(shù)體內(nèi)直接調(diào)用其他函數(shù)，而本身只做了極少的事情”的函數(shù)，通常其函數(shù)簽名與被其調(diào)用的函數(shù)簽名很類似。Pass-Through Mehod所在的模塊通常都是淺模塊，讓系統(tǒng)增加了無謂的層次和函數(shù)調(diào)用，會使系統(tǒng)更加復(fù)雜。

Pass-Through Mehod（選自《A Philosophy of Software Design》中的例子）

學(xué)會寫代碼注釋！

注釋是降低軟件復(fù)雜性的性價比極高的一種手法，它只需要花費(fèi)20%的時間，即可獲取80%的價值。它可以提高晦澀難懂的代碼的可讀性；可以起到隱藏代碼復(fù)雜細(xì)節(jié)的作用，比如接口注釋可以幫助開發(fā)者在沒有閱讀代碼的情況下快速了解該接口的功能和用法；如果寫的好，它還可以改善系統(tǒng)的設(shè)計(jì)。

具體如何寫好代碼注釋，參考《教你寫好代碼注釋》一文。

總結(jié)

軟件的復(fù)雜性是我們程序員在日常開發(fā)中所必須面對的東西，學(xué)會如何 “弄清楚什么是軟件復(fù)雜性，找到導(dǎo)致軟件復(fù)雜的原因，并利用各種手法去戰(zhàn)勝軟件的復(fù)雜性” 是一門必備的能力。有句話說得很好，“代碼質(zhì)量決定生活質(zhì)量”，當(dāng)你把軟件的復(fù)雜性降低了，bug減少了，系統(tǒng)可維護(hù)性更高了，自然也就帶來了更好的生活質(zhì)量。

模塊設(shè)計(jì)是降低軟件復(fù)雜度最有效的手段，學(xué)會使用“戰(zhàn)略編程”的方法，并堅(jiān)持下去。我們常常提倡“一次把事情做對”，但這對于模塊設(shè)計(jì)而言并不適用，幾乎沒有人可以第一次就把一個模塊設(shè)計(jì)成完美的模樣。二次設(shè)計(jì)是一個非常有效的手法，與其在系統(tǒng)腐化之后再花大量時間進(jìn)行重構(gòu)或重寫，還不如在第一次完成模塊設(shè)計(jì)后，再花點(diǎn)時間進(jìn)行二次設(shè)計(jì)，多問問自己：是否有更簡單的接口？是否有更通用的設(shè)計(jì)？是否有更簡潔高效的實(shí)現(xiàn)？

"羅馬不是一天建成的"，降低軟件的復(fù)雜性也一樣，貴在堅(jiān)持。

以上就是淺談如何降低軟件復(fù)雜性的詳細(xì)內(nèi)容，更多關(guān)于如何降低軟件復(fù)雜性的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論