作為一個資深開發(fā)者，今天給大家總結(jié)出來了5條超有用的開發(fā)原則！

原則一 剔除無效狀態(tài)

我把這一點排第一，是因為我認為它是最重要、最強大的原則之一。

你可能在定義類型時聽到過這個詞，但其實這個原則適用于所有與表示數(shù)據(jù)相關(guān)的地方——例如數(shù)據(jù)庫設(shè)計。

它不僅可以減少系統(tǒng)的狀態(tài)數(shù)量（從而變得更簡單），還能減少無效狀態(tài)的數(shù)量！你的系統(tǒng)不需要處理這些無效狀態(tài)，因為它們在你的程序中實際上是不可表示的。

這不只是一個小技巧，它可以極大簡化你的系統(tǒng)，并防止出現(xiàn)各種類型的 bug。

原則二 數(shù)據(jù)一致性讓系統(tǒng)更簡單

對數(shù)據(jù)施加一致性規(guī)則，減少了系統(tǒng)需要處理的狀態(tài)數(shù)量。這是從上一個原則派生而來的。

定義

這里說的是一致性的普遍含義：即數(shù)據(jù)遵循某些規(guī)則，并且在任意時刻都始終遵循這些規(guī)則。這一定義與 ACID 有關(guān)，但不要與 CAP 混淆起來了。

規(guī)則可以是任何東西，例如，你的信用永遠不能變成負數(shù)，或者私密的帖子不應(yīng)該被其他人看到。它不僅限于外鍵或唯一索引，盡管它們也是有效的規(guī)則。

和數(shù)據(jù)庫一樣，應(yīng)用程序也可以通過使用 ACID 事務(wù)來加強一致性。如果能在數(shù)據(jù)庫級別強制保持一致性是最好的，但在實際中，對稍微復(fù)雜一點的東西來說，這樣做并不常見。

實用建議

任何限制或損害一致性的行為都會導(dǎo)致復(fù)雜性。這就引出了以下這些實用的建議：

讓系統(tǒng)更簡單：

?l?更少的數(shù)據(jù)庫 (理想情況下是一個)

?l?規(guī)范化，減少冗余數(shù)據(jù)

?l?一個“好的”數(shù)據(jù)庫設(shè)計

?l?ACID 事務(wù)

?l?更多的數(shù)據(jù)約束

?讓系統(tǒng)更復(fù)雜：

?l?多個數(shù)據(jù)庫

?l?冗余或非正規(guī)化數(shù)據(jù)

?l?糟糕的數(shù)據(jù)庫設(shè)計

?l?較少（或沒有）數(shù)據(jù)約束

?當然，有時候讓系統(tǒng)變復(fù)雜也是有正當理由的，我并不想讓復(fù)雜性變成一個“骯臟的”詞。請參閱后面的一個原則“殺雞不要用牛刀”。

?我認為這個原則是當今軟件工程中最被低估的原則之一。一致性問題經(jīng)常被忽視。很多問題，我敢說大多數(shù)問題，基本上都是一致性問題——數(shù)據(jù)不符合某些期望。

原則三 數(shù)據(jù)設(shè)計先行

這個問題，“代碼還是數(shù)據(jù)？”，哪一個在 10 年后更有可能繼續(xù)存在。

代碼可以被丟掉重寫，但數(shù)據(jù)很少會這樣。

數(shù)據(jù)比代碼更重要。代碼的唯一目的是轉(zhuǎn)換數(shù)據(jù)。

在設(shè)計新系統(tǒng)時，最好先從數(shù)據(jù)庫和數(shù)據(jù)結(jié)構(gòu)開始，并在此基礎(chǔ)上開發(fā)代碼。要考慮可以在數(shù)據(jù)上施加的約束并實施它們，理想情況下是通過表示數(shù)據(jù)的方式進行的。

代碼設(shè)計是數(shù)據(jù)設(shè)計的下一步。數(shù)據(jù)模型越簡單、越一致，代碼就會越簡單。

你們把流程圖給我看，但把表藏起來，我就一頭霧水。你們把表給我看，通常我就不需要你們的流程圖，它們會不言自明?！?Fred Brooks

糟糕的程序員關(guān)心代碼。好的程序員關(guān)心數(shù)據(jù)結(jié)構(gòu)和它們之間的關(guān)系?！?Linux 之父 Linus Torvalds

原則四 殺雞不要用牛刀

這是軟件開發(fā)人員最常犯的錯誤。

這個原則是說，當你在做需要付出復(fù)雜性代價的權(quán)衡時，要確保權(quán)衡的必要性得到經(jīng)驗證據(jù)的支持。

常見錯誤：

試圖構(gòu)建一個復(fù)雜的“可伸縮”系統(tǒng)，可以伸縮到你可能永遠都不需要的規(guī)模。

在不考慮需求或成本的情況下，讓服務(wù)盡可能地小。

在非性能瓶頸的地方優(yōu)化性能，增加不一致性或復(fù)雜性。

建議：

盡可能從最簡單、最正確的系統(tǒng)開始

對性能進行度量

如果不能解決實際問題，就不要付出復(fù)雜性代價或違反其他原則。

有些優(yōu)化可以不進行度量，因為它們的成本非常低或為零。例如，為了保證你想要執(zhí)行的操作具有你想要的性能，使用正確的數(shù)據(jù)結(jié)構(gòu)。

的確，有時候經(jīng)驗本身就能告訴你是否做出了正確的權(quán)衡。但如果你能證明，那就更好了。

當你必須做出選擇時，請選擇正確性和簡單性，而不是性能。

在某些情況下，正確而簡單的代碼是性能最好的代碼！

真正的問題是程序員在錯誤的地方和錯誤的時間花了太多的時間在擔心效率上。過早優(yōu)化是編程中所有（或者至少是大部分）罪惡的根源?！嬎銠C科學家 Donald Knuth

原則五 避免為了局部簡單性而增加全局復(fù)雜性

也就是避免為了讓系統(tǒng)的一部分變得更簡單，而導(dǎo)致整個系統(tǒng)變得更復(fù)雜。

這種交換通常是不平等的。追求局部的簡單性會導(dǎo)致全局復(fù)雜性的增加，而且是數(shù)量級的。

例如，使用較小的服務(wù)可以讓這些服務(wù)變得更簡單，但一致性的降低和對更多進程間通信的需求讓系統(tǒng)變得更加復(fù)雜。