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

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

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

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

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

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

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

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

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

正確的問(wèn)題

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

此功能的最終目標(biāo)是什么?

誰(shuí)將使用它?

有沒(méi)有更簡(jiǎn)單的方法可以實(shí)現(xiàn)相同的目標(biāo)?

它將使應(yīng)用程序更大，更復(fù)雜嗎? 值得嗎?

將解決方案分為多個(gè)部分

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

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

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

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

好的代碼很容易更改

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

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

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

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

唯一有意義的注釋是：

法律評(píng)論

目的說(shuō)明

提高可讀性

警告后果

待辦事項(xiàng)

如何編寫更好的代碼

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

類

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

方法/功能

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

有意義的名字

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

格式和代碼樣式

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