在本文中，我想詳細介紹優(yōu)質(zhì)軟件設(shè)計的廣泛概念，而不是因語言而異的細節(jié)。

什么時候代碼好而什么時候壞? 這是一個主觀且有爭議的話題。 有許多特定于語言或框架的規(guī)則和準則，但是我堅信，好的代碼或好的設(shè)計不僅或總是與它們相關(guān)。 通常，它們會使代碼變得復(fù)雜，分散且結(jié)構(gòu)過度。 因此，我相信好的設(shè)計取決于它的用例。

幸運的是，我認為仍然有一些方法可以確定該軟件在其使用案例中是"好"還是"壞"。

好的設(shè)計很簡單

通常，我遇到的代碼具有完美的結(jié)構(gòu)，并具有適當(dāng)?shù)慕涌冢⒉捎昧诉m當(dāng)?shù)慕涌?，并且采用了特定的代碼模式和代碼樣式工具，這些工具不會返回單個錯誤或警告。 但是，我仍然認為這很糟糕。

每次寫東西時，都應(yīng)該成比例。 許多開發(fā)人員只是為了模式而采用模式。 他們幾乎在大喊："看看我在采用我剛剛讀過的這種模式方面有多強"，而不是真正理解他們?yōu)槭裁催x擇特定模式。

好的設(shè)計通常很簡單。 我的意思是與他們提供的解決方案的大小成正比。 如果您為應(yīng)用程序提供僅使用一次的簡單功能，那么您是否應(yīng)該使用各種花哨的東西? 考慮一下您的代碼復(fù)雜度是否與您提供的解決方案成比例。 您的功能將成為應(yīng)用程序的骨干，還是應(yīng)用程序中擴展或繼承的基礎(chǔ)? 您最好使其結(jié)構(gòu)合理。 這僅僅是解決您的應(yīng)用程序中的一個小問題的方法嗎? 最好盡可能地簡單。

我們傾向于過于復(fù)雜化我們的功能

與我們的應(yīng)用程序的項目負責(zé)人交談時，我們會檢索需求。 在首先提出實現(xiàn)想法之后，我們常常使方法的初始設(shè)計過于復(fù)雜。 與幾個開發(fā)人員坐下來并深入研究實際需要的東西通常是有益的。 您可以通過幾種方法來確保提供更簡單的解決方案。

正確的問題

作為開發(fā)人員，我們經(jīng)常被要求做某事，而我們只是這樣做。 這種按需行為對于初級開發(fā)人員而言可能是正常的，但是隨著您的前進，請嘗試提出明智的問題，并確保在估計或設(shè)計解決方案之前已回答了這些問題。 當(dāng)您一遍又一遍地問某些問題時，您還培訓(xùn)您的產(chǎn)品負責(zé)人或管理人員在請求功能之前考慮這些問題。 像這樣的問題：

• 此功能的最終目標是什么?
• 誰將使用它?
• 有沒有更簡單的方法可以實現(xiàn)相同的目標?
• 它將使應(yīng)用程序更大，更復(fù)雜嗎? 值得嗎?

將解決方案分為多個部分

我始終要做的第一件事是遠離需要在其中實現(xiàn)功能的應(yīng)用程序。然后考慮一下您可以制作和交付的最小代碼段，這使您更加接近為此功能設(shè)置的目標。 對所有這些都執(zhí)行此操作，重新評估所有步驟是否必要，并分別估計其開發(fā)時間。 另外，請嘗試以盡可能獨立的方式開發(fā)這些元素。 交換功能，更改或刪除功能越容易，編寫代碼就越容易。

如果某些必要的小功能真的很重要，請?zhí)魬?zhàn)產(chǎn)品負責(zé)人

當(dāng)您將方法劃分為小部分時，與非技術(shù)人員進行討論通常會更容易。 這樣就可以與團隊和產(chǎn)品負責(zé)人進行討論，并重新評估是否需要所有部分。 由于您已經(jīng)估算了它們，因此如果功能值得，則可以做出更好的基于價值的決策。

不要忘記估計它增加的復(fù)雜程度以及它如何影響維護應(yīng)用程序的成本。

好的代碼很容易更改

如果代碼易于更改，則維護成本較低，易于理解，擴展，刪除，甚至可以更改! 就像《實用程序員》一書中所寫："如果事物能夠適應(yīng)使用它的人，那么它就是經(jīng)過精心設(shè)計的。" 本質(zhì)上，所有設(shè)計原則都是使代碼更易于更改的一種方式。 解耦，單責(zé)任原則，干。 這些都是使您的代碼更好，更容易更改的原則。

為什么我討厭代碼中的注釋

當(dāng)您需要注釋代碼時，它基本上很爛。 當(dāng)您需要解釋為什么要執(zhí)行某項操作時，該代碼并不是不言自明的，因此無論如何都應(yīng)該對其進行重構(gòu)。 代碼注釋清楚地表明了錯誤代碼，并且可以采取許多簡單的步驟使代碼更具可讀性。

注釋不能彌補混亂的代碼。 當(dāng)代碼令人困惑或做出危險的假設(shè)時，我們傾向于寫一些額外的注釋。

唯一有意義的注釋是：

• 法律評論
• 目的說明
• 提高可讀性
• 警告后果
• 待辦事項

如何編寫更好的代碼

有許多簡單的原則可以幫助您編寫更輕松的代碼，而您的同事會喜歡并喜歡與他們一起工作。 對于其中的每一個，都可以編寫一個完全獨立的文章，因此，這里有一個簡單的清單，可以開始您邁向更好的代碼。

類

類應(yīng)該很小。 多么小? 盡可能小。 一個類應(yīng)該只承擔(dān)一個責(zé)任，并且其名稱應(yīng)從該責(zé)任派生。 如果您無法想到一個具有邏輯性和描述性的類名，則它可能太大。

方法/功能

像類一樣，它們應(yīng)該很小，只做一件事，并具有解釋性和簡單的名稱。 注意標識。 許多縮進通常是一種凌亂方法的跡象。 對于Foreach和switch語句，請確保將實際執(zhí)行的代碼編寫在單獨的函數(shù)中，這使其更像是該方法針對不同實現(xiàn)實際執(zhí)行的操作的索引。

有意義的名字

類，函數(shù)和變量都應(yīng)具有有意義的名稱。 例如，切勿使用$ a = b;。 讓您的代碼成為功能和意圖的文檔。

格式和代碼樣式

確保您的整個應(yīng)用程序和整個團隊使用完全相同的代碼樣式，并且對此非常嚴格。 每種IDE和語言都有用于此目的的工具。 一致的空格或換行符可以起到很大作用。 如果不一致，則會使您發(fā)瘋。 在這方面非常嚴格將立即提高應(yīng)用程序的整潔度，尤其是在這方面不是很嚴格的語言中。