我對設計的思考

前幾天被人問如何作架構設計，當時準備不足，回答的不理想，因此想在這裏把本身對架構設計的思考梳理一下。

做爲一個程序員，我對編程有基本的信念：代碼首先是給人閱讀，而後順便讓機器運行。基於這個信念造成了我對設計的思考。若是你不認同這點，那麼後面就沒有必要看了。

首先，命名很是重要。某名宿說過，命名是計算機世界中最重要的兩件事之一（另外一件事是緩存）。作設計首先要取名，名字可以表明系統的職責和功能，體現你對問題本質的理解。模塊的設計、類的設計、接口設計、函數設計也同樣。系統中每一個邏輯單元都應該有清晰的名字，若是你發現命名很難或者須要不少單詞組合，那就說明你的設計出了問題：職責太多或者不夠清晰。

第二，設計的本質是管理複雜度。業務自己的複雜度沒法下降，可是能夠把複雜的業務分解爲不少較簡單的子問題，而後再對子問題進行設計。對系統的分解須要遵循兩個原則：一、分解後的子系統應該在邏輯上屬於同一個層級；二、子系統在邏輯上應該彼此獨立，互不影響。

你們基本都會作分解，可是分解的結果差異很大，主要是因爲視角的區別。在我最開始作架構的幾年，主要從技術視角考慮怎麼作分解（追求代碼的複用），設計很精巧，可是後期可維護性差。如今我會更多從業務視角出發（業務自己包含哪些部分，各部分是什麼關係），不刻意追求複用，後期的可維護性很不錯。我理解兩種方式的區別在於，根據業務作的分解體現的是業務結構，只要業務不產生結構性變化，架構就會保持穩定；而出於複用目的作的分解體現的是功能之間的類似關係，不少業務上沒有關係的功能被劃分到了一塊兒，致使當這些功能出現變化時很容易影響架構的穩定。固然，技術上你有100種方法經過加強擴展性來保證架構的穩定，代價就是複雜度增長，最終會愈來愈難以維護（我曾經架構過一個產品，各類奇技淫巧，逼瘋了不少新人）。因此最好的辦法是一開始就從業務入手，後面都是天然而然的事情了。

第三，程序=算法+數據結構。在架構層面上，數據結構和算法的設計也很重要。在數據結構方面，咱們須要思考系統包含哪些數據，這些數據之間是什麼關係，數據在內存中是什麼結構（線性表、Hash表、樹仍是圖），數據如何持久化（文件、數據庫）。在算法方面，若是可以把業務問題抽象成經典的算法，這樣就能夠找到數學上已經證實有效的解法，並且還會增長代碼的可讀性。以前有個表達式解析器，須要判斷變量之間的循環引用，我使用了經典的拓撲排序算法實現，很是簡潔並且程序員都能懂。

第四，系統的可伸縮性、健壯性、可測試性、可維護性等非功能性需求也很重要，甚至在某些時候決定了項目的成敗。好消息是，這些需求很是通用，因此有不少廣受歡迎的開源項目供你選擇，基本不須要你本身開發。可是你要很是剋制你的技術狂熱，只在真正有必要的時候才引入。記住一個原則，若是引入組件的複雜度超過你要解決問題的複雜度，那就別引入了。

最後一點，必定要關注產品價值和用戶體驗。產品若是因爲價值或體驗失敗了，沒有人會關注你的技術架構作的多麼牛逼。