1 剔除無效狀態
  我把這一點排第一，是因為我認為它是最重要、最強大的原則之一。
  你可能在定義類型時聽到過這個詞，但其實這個原則適用于所有與表示數據相關的地方——例如數據庫設計。
  它不僅可以減少系統的狀態數量（從而變得更簡單），還能減少無效狀態的數量！你的系統不需要處理這些無效狀態，因為它們在你的程序中實際上是不可表示的。
  這不只是一個小技巧，它可以極大簡化你的系統，并防止出現各種類型的 bug。這有一些例子。
   2 數據一致性讓系統更簡單
  對數據施加一致性規則，減少了系統需要處理的狀態數量。這是從上一個原則派生而來的。
  定義
  這里說的是一致性的普遍含義：即數據遵循某些規則，并且在任意時刻都始終遵循這些規則。這一定義與 ACID 有關，但不要與 CAP 混淆起來了。
  規則可以是任何東西，例如，你的信用永遠不能變成負數，或者私密的帖子不應該被其他人看到。它不僅限于外鍵或惟一索引，盡管它們也是有效的規則。
  和數據庫一樣，應用程序也可以通過使用 ACID 事務來加強一致性。如果能在數據庫級別強制保持一致性是最好的，但在實際中，對稍微復雜一點的東西來說，這樣做并不常見。
  實用建議
  任何限制或損害一致性的行為都會導致復雜性。這就引出了以下這些實用的建議：
  讓系統更簡單：
  更少的數據庫 (理想情況下是一個)
  規范化，減少冗余數據
  一個“好的”數據庫設計
  ACID 事務
  更多的數據約束
  讓系統更復雜：
  多個數據庫
  冗余或非正規化數據
  糟糕的數據庫設計
  較少（或沒有）數據約束
  當然，有時候讓系統變復雜也是有正當理由的，我并不想讓復雜性變成一個“骯臟的”詞。請參閱后面的一個原則“殺雞不要用牛刀”。
  我認為這個原則是當今軟件工程中最被低估的原則之一。一致性問題經常被忽視。很多問題，我敢說大多數問題，基本上都是一致性問題——數據不符合某些期望。
  參見附錄，了解不一致性是如何導致復雜性的。
   3 數據設計先行
  這個問題，“代碼還是數據？”，哪一個在 10 年后更有可能繼續存在。
  代碼可以被丟掉重寫，但數據很少會這樣。
  數據比代碼更重要。代碼的唯一目的是轉換數據。
  在設計新系統時，最好先從數據庫和數據結構開始，并在此基礎上開發代碼。要考慮可以在數據上施加的約束并實施它們，理想情況下是通過表示數據的方式進行的。
  代碼設計是數據設計的下一步。數據模型越簡單、越一致，代碼就會越簡單。
  你們把流程圖給我看，但把表藏起來，我就一頭霧水。你們把表給我看，通常我就不需要你們的流程圖，它們會不言自明?！?Fred Brooks
  糟糕的程序員關心代碼。好的程序員關心數據結構和它們之間的關系。—— Linux 之父 Linus Torvalds
  4 殺雞不要用牛刀
  這是軟件開發人員最常犯的錯誤。
  這個原則是說，當你在做需要付出復雜性代價的權衡時，要確保權衡的必要性得到經驗證據的支持。
  常見錯誤：
  試圖構建一個復雜的“可伸縮”系統，可以伸縮到你可能永遠都不需要的規模。
  在不考慮需求或成本的情況下，讓服務盡可能地小。
  在非性能瓶頸的地方優化性能，增加不一致性或復雜性。
  建議：
  盡可能從最簡單、最正確的系統開始
  對性能進行度量
  如果不能解決實際問題，就不要付出復雜性代價或違反其他原則。
  有些優化可以不進行度量，因為它們的成本非常低或為零。例如，為了保證你想要執行的操作具有你想要的性能，使用正確的數據結構。
  的確，有時候經驗本身就能告訴你是否做出了正確的權衡。但如果你能證明，那就更好了。
  當你必須做出選擇時，請選擇正確性和簡單性，而不是性能。
  在某些情況下，正確而簡單的代碼是性能最好的代碼！
  真正的問題是程序員在錯誤的地方和錯誤的時間花了太多的時間在擔心效率上。過早優化是編程中所有（或者至少是大部分）罪惡的根源。——計算機科學家 Donald Knuth
  5 避免為了局部簡單性而增加全局復雜性
  也就是避免為了讓系統的一部分變得更簡單，而導致整個系統變得更復雜。
  這種交換通常是不平等的。追求局部的簡單性會導致全局復雜性的增加，而且是數量級的。
  例如，使用較小的服務可以讓這些服務變得更簡單，但一致性的降低和對更多進程間通信的需求讓系統變得更加復雜。 6 識別內在的復雜性
  有時候事情本身就很復雜，你不能把問題簡單化。
  任何這樣的嘗試都只會讓系統變得更加復雜。
  7 使用的技術越少，系統就越簡單
  深入理解一小部分技術要比只是表面理解很多技術好。
  更少的技術意味著更少的東西要學習和更少的運維復雜性。
  8 集中精力學習概念，而不是技術
  不要太關心技術的復雜細節，因為你可以隨時查閱它們。你要學習底層的基本概念。
  技術會變化，概念卻是永恒的。你學到的概念將被用在更新的技術中，你就可以更快地學會新技術。
  例如，不要太關注 React、Kubernetes、Haskell、Rust 的表面細節。
  重點學習：
  純函數式編程
  關系型模型
  規范的方法
  邏輯編程
  代數數據類型
  類型類 (通用的和特定的)
  借位檢查器 (仿射 / 線性類型)
  依賴類型
  Curry-Howard 同構
  宏 同像性（Homoiconicity）
  VirtualDOM
  線性回歸 ......
  9 代碼一致性很重要
  有時候，具有一致性的代碼比“正確”的代碼更重要。如果你想要改變代碼庫中某些代碼的行為，就要修改它所有的實例。否則的話，就只能忍受。
  代碼的可讀性更多地與一致性（而不是簡單性）有關。人們通過模式識別來理解代碼，所以請重復 (和記錄) 模式！
  10 分享原則很重要
  如果你和隊友之間的共同原則越多，就能越好地在一起工作，而且你會越喜歡和他們在一起工作。
  11 附錄：不一致性導致的復雜性
  這是我能想到的最簡單的例子，希望能毫不費力地與現實問題聯系起來。
  假設一個數據庫有兩個布爾變量 x 和 y，你的應用程序有一個規則，即 x = y，可以通過使用一個事務修改這兩個變量來執行這個規則。
  如果這個規則被正確執行，那么數據只有兩種狀態：(x = True，y = True) 或 (x = False，y = False)。
  基于這個規則的函數“toggle”就非常簡單。你可以讀取其中一個值，并將兩個值都設置為反向值。
  現在，假設你將這兩個變量放到不同的數據庫中，并且不能再被一起修改，那么會發生什么？
  因為你不能確保 x = y 的一致性，所以數據可以有兩種以上的狀態：(x = True，y = False) 或 (x = False，y = True)。
  如果你的系統處于這些狀態中的一種，你應該使用哪個值？
  當處于其中的一種狀態時，“toggle”函數的行為是怎樣的？
  在寫入新值時，如何確保兩次寫入都成功？
  這些問題沒有正確的答案。
  當然，如果我們一開始就遵循“剔除無效狀態”的原則，那么將只有一個變量！