實踐中的代碼復雜性第一部分：軟件復雜性介紹

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

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

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

復雜的迷宮

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

慢下來

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

打破復雜性

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

選擇更好的工具和方法

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

徹底消除復雜性

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

經過時間考驗的原則

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

別讓我思考

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

封裝

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

松耦合

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

關注點分離

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

可讀性

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

設計模式(明智)

理解并應用這些常見的解決方案，但不要強迫使用它們。例如，SOLID 原則可以總結如下：

單一職責原則(SRP)

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

開放/封閉原則(OCP)

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

fbusin 替代原則 (LSP)

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

接口隔離原則 (ISP)

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

依賴倒置原則 (DIP)

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

重構

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

簡單 (KISS)

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

DRY(不要重復自己)

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

文檔

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

濫用如何導致適得其反

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

1. 過度使用 SOLID

嚴格的 SRP

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

強迫癥

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

2. 誤用設計模式

強制工廠模式

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

過度殺戮單身人士

為每個服務或實用程序類使用單例模式，即使在沒有必要的情況下也會產生全局狀態(tài)管理問題和緊密耦合的代碼。

3.過度重構

重構狂熱

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

過早優(yōu)化

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

4. 對封裝的誤解

數(shù)據堡壘

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

5. 忽視背景

盲目應用原則

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

記住

· 目標是將這些原則用作指導方針，而不是嚴格的規(guī)則。

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

· 背景為王：根據項目的獨特需求和復雜性調整您的方法。

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

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