架構師必須掌握的 10 條設計原則

1、遵循單一職責原則

函數是程式員的工具中最重要的抽象形式。它們能更多地被重複使用，你需要編寫的代碼就越少，代碼也是以變得更可靠。較小的函數遵循單一職責原則更有可能被重複使用。

2、盡量減少共享狀态

你應該盡量減少函數之間的隐式共享狀态，無論它是檔案作用域的變量還是對象的成員字段，這有利于明确要求把值作為參數。當能明确地顯示函數需要什麼才可以産生所需的結果時，代碼會變得更容易了解和重用。

對此的一個推論是，在一個對象中，相對于成員變量，你更應該優先選擇靜态的無狀态變量 (static stateless variables)。

3、将副作用局部化

理想的副作用（例如：列印到控制台、日志記錄、更改全局狀态、檔案系統操作等）應該被放置到單獨的子產品中，而不是散布在整個代碼裡面。函數中的一些“副作用”功能往往違反了單一職責原則。

4、優先使用不變的對象

如果一個對象的狀态在其構造函數中僅被設定一次，并且從不再次更改，則調試會變得更加容易，因為隻要構造正确就能保持有效。這也是降低軟體項目複雜性的最簡單方法之一。

5、接口高于類

接收接口的函數（或 C++ 中的模闆參數和概念）比在類上運作的函數更具可重用性。點選這裡檢視 6 大設計原則。

6、對子產品應用良好的原則

尋找機會将軟體項目分解成更小的子產品（例如庫和應用程式），以促進子產品級别的重用。對于子產品，應該遵循的一些關鍵原則是：

1.盡可能減少依賴

2.每個項目應該有一個明确的職責

3.不要重複自身

你應該努力使你的項目保持小巧和明确。

7、避免繼承

在面向對象程式設計中，繼承 —— 特别是和虛拟函數結合使用時，在可重用性方面往往是一條死胡同。我很少有成功的使用或編寫重載類的庫的經曆。

8、将測試作為設計和開發的一部分

我不是測試驅動開發的堅定分子，但開始編碼時先編寫測試代碼會使得代碼十分自然地遵循許多指導原則。這也有助于盡早發現錯誤。不過要注意避免編寫無用的測試，良好的編碼實踐意味着更進階别的測試（例如單元測試中的內建測試或特征測試）在揭示缺陷方面更有效。

9、優先使用标準的庫

我經常看到更好版本的 std::vector或 std::string ，但這幾乎總是浪費時間和精力。一個明顯的事實是 —— 你正在為一個新的地方引入 bug，其他開發者也不太可能重用你的代碼，因為沒有被廣泛了解、支援和測試。

10、避免編寫新的代碼

這是每個程式員都應遵循的最重要的教誨：最好的代碼就是還沒寫的代碼。你寫的代碼越多，你将遇到的問題就越多，查找和修複錯誤就越困難。

在寫一行代碼之前先問一問自己，有沒有一個工具、函數或者庫已經實作了你所需要的功能？你真的需要自己實作這個功能，而不是調用一個已經存在的功能嗎？