想象一下，你走進(jìn)一個熙熙攘攘的工作室——這里不是機(jī)器嗡嗡作響的地方，而是人們齊心協(xié)力的思想。這才是軟件編程的真正本質(zhì)：集體努力，代碼不僅是機(jī)器的指令，也是開發(fā)人員的共同語言。然而，與口頭語言不同，代碼往往會成為一種晦澀難懂的方言，籠罩在復(fù)雜性之中，新手難以理解。這就是為人類編寫代碼的藝術(shù)發(fā)揮作用的地方，將神秘的腳本轉(zhuǎn)化為其他人可以輕松理解的敘述。

畢竟，我們代碼的主要用戶群是軟件工程師;那些目前正在與我們合作或?qū)頃槲覀兊拇a工作的人。這改變了我們的軟件開發(fā)思維。僅僅為機(jī)器理解和執(zhí)行編寫代碼是不夠的。這是必要的，但還不夠。如果我們的代碼易于人類閱讀和理解，那么我們就朝著可管理的代碼復(fù)雜性邁出了足夠的一步。

本文重點介紹以人為本的代碼如何幫助實現(xiàn)可控的代碼復(fù)雜性。有許多最佳實踐，但應(yīng)仔細(xì)思考并考慮我們的環(huán)境來處理它們。最后，使用叢林隱喻來解釋代碼復(fù)雜性的一些基本動態(tài)。

復(fù)雜的迷宮

所有人類可讀代碼的天敵是什么?復(fù)雜性。隨著項目的發(fā)展、功能的增加以及屏幕上代碼行的蜿蜒，理解代碼成為一項艱巨的任務(wù)。為了解決這個問題，開發(fā)人員采用了一套經(jīng)過時間考驗的原則，作為對抗混亂的武器。重要的是要記住復(fù)雜性是不可避免的。它可能是最小的復(fù)雜性或高的復(fù)雜性，但這里的一個關(guān)鍵要點是復(fù)雜性會悄悄出現(xiàn)，但它不必征服我們的代碼。 我們必須保持警惕并盡早采取行動，這樣我們才能編寫不斷增長而不是呻吟的代碼。

慢下來

通過應(yīng)用模塊化設(shè)計、清晰的命名約定、適當(dāng)?shù)奈臋n和下一段中提到的原則等最佳實踐，我們可以顯著降低復(fù)雜性增加的速度。這使得代碼更容易理解、維護(hù)和修改，即使它增長。

打破復(fù)雜性

我們可以使用重構(gòu)和代碼審查等技術(shù)來識別和消除現(xiàn)有代碼庫中不必要的復(fù)雜性。這并不能消除所有復(fù)雜性，但可以顯著減少。

選擇更好的工具和方法

較新的編程語言和范例通常注重通過設(shè)計來降低復(fù)雜性。例如，函數(shù)式編程提倡不變性和模塊化，這可以減少代碼結(jié)構(gòu)的復(fù)雜程度。

徹底消除復(fù)雜性

降低代碼復(fù)雜性是一回事，減少它是另一回事，而完全消除它是另一回事，在實踐中很少能實現(xiàn)。

經(jīng)過時間考驗的原則

下面，我們可以找到一些可能有助于我們對抗復(fù)雜性的原則示例。這絕不是一個詳盡的清單，但它有助于說明我們的觀點：環(huán)境是王道。雖然這些原則提供了寶貴的指導(dǎo)，但嚴(yán)格遵守有時會適得其反。始終考慮項目的具體環(huán)境。過度應(yīng)用單一職責(zé)或接口隔離等原則可能會導(dǎo)致代碼庫臃腫，從而掩蓋核心功能。

別讓我思考

努力讓代碼讀起來自然，并且只需付出最少的腦力勞動就能理解。使用清晰的邏輯和不言自明的結(jié)構(gòu)，而不是過于復(fù)雜的設(shè)計。盡可能讓自己和他人都能輕松理解代碼。

封裝

將相關(guān)數(shù)據(jù)和功能分組到類或模塊內(nèi)，以促進(jìn)數(shù)據(jù)隱藏和更好的組織。

松耦合

最大限度地減少代碼庫不同部分之間的依賴性，使得修改和測試單個組件變得更加容易。

關(guān)注點分離

將代碼分為不同的層(例如，表示、業(yè)務(wù)邏輯、數(shù)據(jù)訪問)，以提高可維護(hù)性和可重用性。

可讀性

使用有意義的名稱、一致的格式和注釋來解釋代碼背后的“為什么”。

設(shè)計模式(明智)

理解并應(yīng)用這些常見的解決方案，但不要強(qiáng)迫使用它們。例如，SOLID 原則可以總結(jié)如下：

單一職責(zé)原則(SRP)

想象一下一把擁有百萬種工具的瑞士軍刀。雖然很酷，但不切實際。同樣，代碼應(yīng)該專注于每個類的一個明確定義的任務(wù)。這使得修改代碼時更容易理解、維護(hù)和避免意外后果。

開放/封閉原則(OCP)

想想樂高積木。你可以構(gòu)建無數(shù)東西而不用改變單個積木本身。在軟件方面，OCP 鼓勵通過擴(kuò)展添加新功能，而不改變核心代碼。這可以保持代碼的穩(wěn)定性和適應(yīng)性。

fbusin 替代原則 (LSP)

想象一下派你的朋友代替你工作。他們可能會做些略有不同的事情，但他們應(yīng)該無縫地履行相同的職責(zé)。LSP 確保子類型(繼承)可以無縫替換其基類型，而不會導(dǎo)致錯誤或意外行為。

接口隔離原則 (ISP)

想象一下遙控器上所有按鈕都擠在一起。很混亂，對吧?ISP 提倡創(chuàng)建更小、更專業(yè)的界面，而不是一個巨大的界面。這使得代碼更清晰、更易于使用，因為不同的部分只與它們需要的功能交互。

依賴倒置原則 (DIP)

想象一下每個任務(wù)都依賴特定工具。不切實際!DIP 建議依賴抽象(接口)而不是具體實現(xiàn)。這允許您輕松交換實現(xiàn)而不影響其余代碼，從而提高靈活性和可測試性。

重構(gòu)

定期重新審視和改進(jìn)代碼庫以提高清晰度和效率。

簡單 (KISS)

優(yōu)先考慮清晰的設(shè)計，避免不必要的功能和過度設(shè)計。

DRY(不要重復(fù)自己)

通過使用函數(shù)、類和模塊消除代碼重復(fù)。

文檔

為代碼和軟件使用寫出清晰的解釋，以幫助用戶和未來的開發(fā)人員。

濫用如何導(dǎo)致適得其反

雖然上述原則旨在清晰和簡單，但誤用這些原則可能會導(dǎo)致相反的效果。以下是一些例子。

1. 過度使用 SOLID

嚴(yán)格的 SRP

想象一下，將一個具有多項明確職責(zé)的類拆分成多個較小的類，每個類處理一項微小的任務(wù)。這會因眾多的類和依賴關(guān)系而產(chǎn)生不必要的復(fù)雜性，妨礙理解。

強(qiáng)迫癥

為每個潛在的未來擴(kuò)展實現(xiàn)接口，即使對于不太可能出現(xiàn)的情況，也可能會因未使用的抽象而導(dǎo)致代碼庫膨脹，并使理解實際功能變得復(fù)雜。

2. 誤用設(shè)計模式

強(qiáng)制工廠模式

在直接創(chuàng)建對象時應(yīng)用工廠模式是有意義的，但會引入不必要的復(fù)雜性和抽象，尤其是在較簡單的項目中。

過度殺戮單身人士

為每個服務(wù)或?qū)嵱贸绦蝾愂褂脝卫Ｊ?，即使在沒有必要的情況下也會產(chǎn)生全局狀態(tài)管理問題和緊密耦合的代碼。

3.過度重構(gòu)

重構(gòu)狂熱

在沒有明確目標(biāo)或理由的情況下不斷重構(gòu)可能會引起混亂，使代碼庫變得不穩(wěn)定，其他開發(fā)人員更難跟進(jìn)。

過早優(yōu)化

過早地針對未來潛在的性能瓶頸優(yōu)化代碼可能會產(chǎn)生可能永遠(yuǎn)不需要的復(fù)雜解決方案，從而增加不必要的開銷并降低可讀性。

4. 對封裝的誤解

數(shù)據(jù)堡壘

過度嚴(yán)格的封裝，將所有內(nèi)部數(shù)據(jù)和方法隱藏在復(fù)雜的訪問器后面，會妨礙理解并使代碼更難測試和修改。

5. 忽視背景

盲目應(yīng)用原則

嚴(yán)格遵守原則而不考慮項目的具體需求可能會導(dǎo)致解決方案對于特定情況來說過于復(fù)雜和繁瑣。

記住

· 目標(biāo)是將這些原則用作指導(dǎo)方針，而不是嚴(yán)格的規(guī)則。

· 簡單和清晰至關(guān)重要，即使這意味著在特定情況下偏離原則。

· 背景為王：根據(jù)項目的獨(dú)特需求和復(fù)雜性調(diào)整您的方法。

通過了解這些潛在的陷阱并明智地運(yùn)用這些原則，您可以使用它們編寫清晰高效的代碼，避免過度設(shè)計的陷阱。

20240701_66825af63f45f__實踐中的代碼復(fù)雜性第一部分：軟件復(fù)雜性介紹