作者 | Joydip Kanjilal
編譯 | 王瑞平
意大利面是一種很好吃的食物，但是，如果用它來形容代碼意味著這種程序很糟糕。
“意大利面條式代碼”是一個術(shù)語，用于描述組織不良、糾纏不清或嵌套復(fù)雜的代碼。這些代碼非常難以理解、更新、擴展和維護，缺乏適當(dāng)組織，具有復(fù)雜或令人費解的控制流。這違反了軟件設(shè)計原則。
無論你的代碼如何天衣無縫，混亂代碼都將或多或少地潛入你應(yīng)用程序的源代碼中。最終，你的代碼將變得難以閱讀、難以處理，從而難以添加新的功能、無法修復(fù)錯誤和維護代碼庫。
一、溯源：混亂代碼出現(xiàn)的原因
那么，你的C#程序中為什么會出現(xiàn)混亂代碼呢？這通常由以下原因?qū)е拢?/p>
1.未能遵循正確的方法和原則編寫代碼
2.編寫代碼時沒有組織代碼的計劃
3.使用借來的代碼
4.使用沒有經(jīng)驗的開發(fā)人員編寫的代碼
從項目迭代到后期，往往會變得很混亂，只有少數(shù)人能知道某段代碼的作用和該如何去改，或者是干脆誰都不知道，只能靠通過注釋去猜測這段代碼可能的作用。
因為團隊內(nèi)部人員變動導(dǎo)致撰寫代碼的人不再管理這段代碼了。我們稱這類代碼為“祖?zhèn)鞔a”，沒人懂也沒人敢動。祖?zhèn)鞔a一多，開發(fā)人員再想迭代就難上加難，形成可怕的惡性循環(huán)。
二、陷阱：混亂代碼會使你焦頭爛額
混亂和無組織代碼會給C#程序員帶來麻煩，現(xiàn)在列舉出來，看看你是否曾經(jīng)遇到過這些情況：
·首先，它會為開發(fā)人員帶來難以修復(fù)的bug或?qū)е聼o法向程序中添加新的功能，還會導(dǎo)致試圖更改C#代碼的團隊成員困惑不解。
·其次，由于算法效率低下或缺乏優(yōu)化，混亂代碼可能會導(dǎo)致應(yīng)用程序性能降低、響應(yīng)時間變慢、內(nèi)存消耗增加，影響用戶體驗。
·最后就是安全問題，混亂代碼中可能暗藏被黑客利用的漏洞。
如果你的程序中出現(xiàn)了混亂代碼，需要付出昂貴的成本修復(fù)。幸運的是，這些情況都是可以避免的。在文章的下半部分，我們將提供10個最佳方法，用來避免C#語言中出現(xiàn)混亂代碼并保持程序整潔、組織良好和可維護。
三、10招：避免出現(xiàn)混亂代碼
你需要遵循以下10種方法確保你的C#語言中代碼干凈、精簡和易于維護。
方法一：堅持面向?qū)ο笤瓌t
您應(yīng)該在C#語言的類和對象中封裝數(shù)據(jù)和行為，并遵循“面向?qū)ο缶幊?OOP)”原則，如，繼承、組合和多態(tài)性來創(chuàng)建模塊化、可管理和有組織的代碼。
方法二：堅持采用SOLID和DRY原則編程
首先來介紹下什么是SOLID和DRY原則：
SOLID原則：
（1）SRP(Single Responsibility Principle)單一職責(zé)
一個類或模塊只負責(zé)完成一個功能。
（2）OCP(Open Closed Principle)開閉原則
(模塊、類、方法)對拓展開放，對修改關(guān)閉
（3）LSP(Liskov Substitution Principle)里氏替換
子類對象能夠替換程序中父類對象出現(xiàn)的任何地方，并保證原來程序的邏輯行為不變及正確性不被破壞。
（4）ISO(Interface Segregation Principle)接口隔離
客戶端(接口調(diào)用者)不應(yīng)該被強迫依賴它不需要的接口。
（5）DIP(Dependency Inversion Principle)依賴倒置/依賴反轉(zhuǎn)
高層模塊不依賴低層模塊，它們共同依賴同一個抽象，抽象不要依賴具體實現(xiàn)細節(jié)，具體實現(xiàn)細節(jié)依賴抽象。
DRY(Don’t Repeat Yourself)原則：
不要開發(fā)重復(fù)代碼，可以復(fù)用或提取公共代碼，同時，也要注意遵守“單一職責(zé)”和“接口隔離”原則。
總之，構(gòu)建遵循“SOLID和DRY”原則的軟件可以將出現(xiàn)混亂代碼的相關(guān)風(fēng)險降至最低。
·這里特殊說明下，根據(jù)“單一職責(zé)原則”(五個SOLID原則之一)，每類程序或方法只需要具備一個職責(zé)。例如，應(yīng)用程序中的Logger類代碼只需要負責(zé)記錄數(shù)據(jù)，而不應(yīng)該包含其它功能。
·當(dāng)具有復(fù)雜功能的程序被分解成更小、更集中的組件時，就更容易理解和維護它們?！癉RY原則”可以將公共函數(shù)抽象為可重復(fù)使用的方法、類和庫，從而減少出現(xiàn)重復(fù)的代碼。
方法三：保持清晰和集中的步驟
將復(fù)雜的任務(wù)分解為可管理的步驟，可以使你的代碼更易于閱讀和理解。這也減少了代碼的冗余并提高了代碼的可維護性。
方法四：使用有意義的名稱
通過遵守編碼標(biāo)準(zhǔn)和風(fēng)格指南有利于讓你的代碼庫保持整齊，確保變量、類、方法和其它元素都能匹配上有意義的描述性名稱。這些名稱使你的代碼更容易理解，從而減少注釋并使維護代碼變得更容易。
方法五：降低圈復(fù)雜度
“圈復(fù)雜度”用來確定源代碼中線性獨立路徑數(shù)量，可以幫助你理解代碼復(fù)雜性。過多的if-else語句和深度嵌套使代碼難以理解并增加了圈復(fù)雜度。你可以通過重構(gòu)代碼減少嵌套級別并簡化分支邏輯。
方法六：代碼中少用注釋
6代碼中應(yīng)該包含注釋，用來解釋類、接口、方法和屬性出現(xiàn)的目的，使代碼更容易管理、維護和調(diào)試。但是，文檔需要更加清晰。清晰的名稱和更簡單的代碼(即，圈復(fù)雜度更低的代碼)使代碼更容易理解，并不一定需要出現(xiàn)太多的注釋。
方法七：定期重構(gòu)代碼
刪除代碼冗余或重復(fù)，簡化復(fù)雜的代碼片段，并通過定期重構(gòu)提高代碼質(zhì)量。通過改進代碼的設(shè)計和結(jié)構(gòu)，重構(gòu)使代碼庫隨著時間的推移更容易維護。
方法八：KISS和YAGNI原則簡化代碼
KISS原則是英語Keep It Simple的縮寫，也有人稱“懶人原則”，是指在設(shè)計當(dāng)中應(yīng)當(dāng)注重簡約。
你可以將KISS原則應(yīng)用于編程，用來構(gòu)建最簡單的框架，滿足用戶需求并避免不必要的復(fù)雜性。當(dāng)你的應(yīng)用程序中包含不必要的特性和代碼時，它不僅會使單元測試和代碼維護變得困難，而且還會影響用戶體驗。
YAGNI原則的英文全稱是：You Ain’t Gonna Need It。直譯就是：你不會需要它。當(dāng)用在軟件開發(fā)中的時候，它的意思是：不要去設(shè)計當(dāng)前用不到的功能，不要去編寫當(dāng)前用不到的代碼。
類似的，你可以遵循YAGNI原則清除不重要的功能和代碼。你應(yīng)該只關(guān)注需要的功能，避免為追求完美而給代碼“鍍金”。
方法九：經(jīng)常運行單元測試
你應(yīng)該在軟件開發(fā)工作流程中充分利用單元測試工具，減少應(yīng)用程序中的錯誤。單元測試有助于確保代碼單元按照預(yù)期運行。如果你已經(jīng)更改或重構(gòu)了代碼，應(yīng)該再次運行單元測試功能，用來確保一切工作正常進行。
方法十：進行代碼審查
進行代碼審查可以讓你深入了解代碼并獲得反饋。同行評審代碼使你和團隊成員有機會識別混亂代碼并收集改進建議。同行評審可以幫助你的團隊避免編寫混亂代碼并付諸實踐。
四、寫在最后：不與混亂代碼糾纏
總之，混亂代碼錯綜復(fù)雜，就像一盤糾纏在一起的面條。如果你要清理它，最好從小處開始并不斷改進代碼。通過遵循本文中概述的10個指導(dǎo)方針，你可以避免應(yīng)用程序中出現(xiàn)混亂代碼，并為團隊成員節(jié)省大量時間、精力和避免麻煩。
參考資料：
https://www.infoworld.com/article/3699709/how-to-avoid-spaghetti-code-in-c-sharp.html
