【易龍天】5個有用的軟件開發原則
我總結了一些軟件開發原則。在這些原則中，大多數都是以簡化系統為核心。在我看來，簡單的系統會更可靠，更容易修改，而且一般更容易使用。當觀念發生改變時，我希望更新它們。對數據施加一致性規則，減少了系統需要處理的狀態數量。這是從上一個原則派生而來的。這里說的是一致性的普遍含義：即數據遵循某些規則，并且在任意時刻都始終遵循這些規則。這一定義與 ACID 有關，但不要與 CAP 混淆起來了。規則可以是任何東西，例如，你的信用永遠不能變成負數，或者私密的帖子不應該被其他人看到。它不僅限于外鍵或惟一索引，盡管它們也是有效的規則。和數據庫一樣，應用程序也可以通過使用 ACID 事務來加強一致性。如果能在數據庫級別強制保持一致性是最好的，但在實際中，對稍微復雜一點的東西來說，這樣做并不常見。任何限制或損害一致性的行為都會導致復雜性。這就引出了以下這些實用的建議：
更少的數據庫 (理想情況下是一個)
規范化，減少冗余數據
一個“好的”數據庫設計
ACID 事務
更多的數據約束
多個數據庫
冗余或非正規化數據
糟糕的數據庫設計
較少（或沒有）數據約束
當然，有時候讓系統變復雜也是有正當理由的，我并不想讓復雜性變成一個“骯臟的”詞。請參閱后面的一個原則“殺雞不要用牛刀”。我認為這個原則是當今軟件工程中最被低估的原則之一。一致性問題經常被忽視。很多問題，我敢說大多數問題，基本上都是一致性問題——數據不符合某些期望。這個原則是說，當你在做需要付出復雜性代價的權衡時，要確保權衡的必要性得到經驗證據的支持。
盡可能從最簡單、最正確的系統開始
對性能進行度量
如果不能解決實際問題，就不要付出復雜性代價或違反其他原則。
有些優化可以不進行度量，因為它們的成本非常低或為零。例如，為了保證你想要執行的操作具有你想要的性能，使用正確的數據結構。
的確，有時候經驗本身就能告訴你是否做出了正確的權衡。但如果你能證明，那就更好了。
當你必須做出選擇時，請選擇正確性和簡單性，而不是性能。
在某些情況下，正確而簡單的代碼是性能最好的代碼！
真正的問題是程序員在錯誤的地方和錯誤的時間花了太多的時間在擔心效率上。過早優化是編程中所有（或者至少是大部分）罪惡的根源。——計算機科學家 Donald Knuth
不要太關心技術的復雜細節，因為你可以隨時查閱它們。你要學習底層的基本概念。技術會變化，概念卻是永恒的。你學到的概念將被用在更新的技術中，你就可以更快地學會新技術。例如，不要太關注 React、Kubernetes、Haskell、Rust 的表面細節。
純函數式編程
關系型模型
規范的方法
邏輯編程
代數數據類型
類型類 (通用的和特定的)
借位檢查器 (仿射 / 線性類型)
依賴類型
Curry-Howard 同構
宏
同像性（Homoiconicity）
VirtualDOM
線性回歸
如果你和隊友之間的共同原則越多，就能越好地在一起工作，而且你會越喜歡和他們在一起工作。這是我能想到的最簡單的例子，希望能毫不費力地與現實問題聯系起來。假設一個數據庫有兩個布爾變量 x 和 y，你的應用程序有一個規則，即 x = y，可以通過使用一個事務修改這兩個變量來執行這個規則。如果這個規則被正確執行，那么數據只有兩種狀態：(x = True，y = True) 或 (x = False，y = False)。基于這個規則的函數“toggle”就非常簡單。你可以讀取其中一個值，并將兩個值都設置為反向值。現在，假設你將這兩個變量放到不同的數據庫中，并且不能再被一起修改，那么會發生什么？因為你不能確保 x = y 的一致性，所以數據可以有兩種以上的狀態：(x = True，y = False) 或 (x = False，y = True)。
當然，如果我們一開始就遵循“剔除無效狀態”的原則，那么將只有一個變量！
更多新聞
