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

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

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

好的設(shè)計(jì)很簡單

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

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

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

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

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

正確的問題

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

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

將解決方案分為多個部分

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

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

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

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

好的代碼很容易更改

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

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

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

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

唯一有意義的注釋是：

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

如何編寫更好的代碼

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

類

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

方法/功能

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

有意義的名字

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

格式和代碼樣式

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