在做軟件開發(fā)的時候，有這么幾個問題是一定要掌握的先后順序的，其實也就是原則問題，只有在這些節(jié)點上掌控好軟件開發(fā)的細(xì)節(jié)，才能做出更為完善的系統(tǒng)，接下來，云南來可云小編給大家來分享一下這幾個原則。

1、剔除無效狀態(tài)

我把這一點排第—，是因為我認(rèn)為它是比較重要、又比較強大的原則之一。

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

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

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

2、數(shù)據(jù)一致性讓系統(tǒng)更簡單

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

定義

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

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

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

實用建議

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

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

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

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

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

ACID 事務(wù)

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

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

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

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

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

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

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

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

參見附錄，了解不一致性是如何導(dǎo)致復(fù)雜性的。

3、數(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ù)模型越簡單、越一致，代碼就會越簡單。

4、殺雞不要用牛刀

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

這個原則是說，當(dāng)你在做需要付出復(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)衡。但如果你能證明，那就更好了。

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

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

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

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

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

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

6、識別內(nèi)在的復(fù)雜性

有時候事情本身就很復(fù)雜，你不能把問題簡單化。

任何這樣的嘗試都只會讓系統(tǒng)變得更加復(fù)雜。

7、使用的技術(shù)越少，系統(tǒng)就越簡單

深入理解一小部分技術(shù)要比只是表面理解很多技術(shù)好。

更少的技術(shù)意味著更少的東西要學(xué)習(xí)和更少的運維復(fù)雜性。

8、集中精力學(xué)習(xí)概念，而不是技術(shù)

不要太關(guān)心技術(shù)的復(fù)雜細(xì)節(jié)，因為你可以隨時查閱它們。你要學(xué)習(xí)底層的基本概念。

技術(shù)會變化，概念卻是永恒的。你學(xué)到的概念將被用在更新的技術(shù)中，你就可以更快地學(xué)會新技術(shù)。

例如，不要太關(guān)注 React、Kubernetes、Haskell、Rust 的表面細(xì)節(jié)。

9、代碼一致性很重要

有時候，具有一致性的代碼比“正確”的代碼更重要。如果你想要改變代碼庫中某些代碼的行為，就要修改它所有的實例。否則的話，就只能忍受。

代碼的可讀性更多地與一致性（而不是簡單性）有關(guān)。人們通過模式識別來理解代碼，所以請重復(fù) (和記錄) 模式！

10、分享原則很重要

如果你和隊友之間的共同原則越多，就能越好地在一起工作，而且你會越喜歡和他們在一起工作。