架構師必須掌握的 10 條設計原則
01
遵循單一職責原則
函式是程式員的工具中最重要的抽象形式。它們能更多地被重複使用，你需要編寫的程式碼就越少，程式碼也因此變得更可靠。較小的函式遵循單一職責原則更有可能被重複使用。
02
儘量減少共享狀態
你應該儘量減少函式之間的隱式共享狀態，無論它是檔案作用域的變數還是物件的成員欄位，這有利於明確要求把值作為引數。當能明確地顯示函式需要什麼才可以產生所需的結果時，程式碼會變得更容易理解和重用。
對此的一個推論是，在一個物件中，相對於成員變數，你更應該優先選擇靜態的無狀態變數 (static stateless variables)。
03
ofollow,noindex"> 將“副作用”區域性化
理想的副作用（例如：列印到控制檯、日誌記錄、更改全域性狀態、檔案系統操作等）應該被放置到單獨的模組中，而不是散佈在整個程式碼裡面。函式中的一些“副作用”功能往往違反了單一職責原則。
04
優先使用不變的物件
如果一個物件的狀態在其建構函式中僅被設定一次，並且從不再次更改，則除錯會變得更加容易，因為只要構造正確就能保持有效。這也是降低軟體專案複雜性的最簡單方法之一。
如果你依然在程式設計的世界裡迷茫，不知道自己的未來規劃，可以加入JAVA架構學習交流群：614478470 裡面可以與大神一起交流並走出迷茫。進群免費領取學習資料，看看前輩們是如何在程式設計的世界裡傲然前行！群裡不停更新最新的教程和學習方法（進群送JAVA架構視訊資料），有想學習JAVA的，或是轉行，還有工作中想提升自己能力的，正在學習的小夥伴歡迎加入學習
05
介面高於類
接收介面的函式（或 C++ 中的模板引數和概念）比在類上執行的函式更具可重用性。點選這裡 檢視 6 大設計原則。
06
尋找機會將軟體專案分解成更小的模組（例如庫和應用程式），以促進模組級別的重用。對於模組，應該遵循的一些關鍵原則是：
1.儘可能減少依賴
2.每個專案應該有一個明確的職責
3.不要重複自身
你應該努力使你的專案保持小巧和明確。
07
在面向物件程式設計中，繼承 —— 特別是和虛擬函式結合使用時，在可重用性方面往往是一條死衚衕。我很少有成功的使用或編寫過載類的庫的經歷。
08
我不是測試驅動開發的堅定分子，但開始編碼時先編寫測試程式碼會使得程式碼十分自然地遵循許多指導原則。這也有助於儘早發現錯誤。不過要注意避免編寫無用的測試，良好的編碼實踐意味著更高級別的測試（例如單元測試中的整合測試或特徵測試）在揭示缺陷方面更有效。
09
優先使用標準的庫
我經常看到更好版本的 std::vector或 std::string ，但這幾乎總是浪費時間和精力。一個明顯的事實是 —— 你正在為一個新的地方引入 bug，其他開發者也不太可能重用你的程式碼，因為沒有被廣泛理解、支援和測試。
10
避免編寫新的程式碼
這是每個程式設計師都應遵循的最重要的教誨：最好的程式碼就是還沒寫的程式碼。你寫的程式碼越多，你將遇到的問題就越多，查詢和修復錯誤就越困難。
在寫一行程式碼之前先問一問自己，有沒有一個工具、函式或者庫已經實現了你所需要的功能？你真的需要自己實現這個功能，而不是呼叫一個已經存在的功能嗎？
想要學習Java高架構、分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師視訊免費獲取架構群：614478470
點選連結加入群聊【JAVA高階架構】：https://jq.qq.com/?_wv=1027&k=5gMDouY
你還知道別的設計原則嗎？歡迎留言！