一提到架構，對于工作經驗不多的小伙伴來說會心生敬畏之心。覺得是一個很高端、很難、很有挑戰的事情。

沒錯，架構不像我們平時的coding工作，這是一個宏觀層面的事情。而對我們內心來說，越宏觀、越大的東西，我們總會覺得更不容易控制，所以會心生敬畏。但實際上，架構的“世界”在復雜度上可能還不如coding上的細枝末節那么大。

我有幸從2015年開始接觸架構相關的工作，作為過來人，我建議所有程序員們盡可能早地培養自己的架構思維，這對你未來在技術路線上走的更遠很有幫助。

因為這是一個視野問題。同一個功能，代碼的實現方式可以有千千萬，每一次coding就是一次決策。你在視野10米內做決策，自然沒有在1000米范圍內做出的決策來得更優。

架構思維的培養并不需要你非得是架構師，每個程序員都可以。下面我來分享一個大家都能嘗試的方法。

首先，心里一定要清楚「架構的意義」是什么？并且一直帶著這個意義做接下去的事情。否則很容易本末倒置甚至是跑偏。

Z哥對架構意義的理解是：架構表達的是一種關系，是多個現實元素之間的關系。

這里面的兩個關鍵詞是「關系」和「現實」。「關系」很好理解，就是不同事物之間以什么樣的形式共存。而「現實」容易被人輕視，因為它顯得很平常，但是往往我們在做架構的時候，對于某些現實的定義是不精準的。現實定義錯了，后面的工作大概率也是錯的。

所以，要做的第一件事就出來了：明確你當前要解決的問題，或者要達成的目標。并且弄清楚其中涉及到的相關概念所表達的業務含義。

你可以將這一步中所得到的相關概念用工具或者紙筆畫出來，平鋪開來就可以。比如像下面這樣。

做完了這一步，接下來就是傳統意義上做架構的過程。對于這個過程，也用一句話來概括就是：架構的過程其實就是建模的過程。

沒錯，「建模」就是進一步細化當前的事物，并且基于所得的信息做相關的延展和規劃，循序漸進，得到一個完整的、可執行的方案的過程。

說起來很簡單，做起來卻不那么簡單。在這個過程中會涉及到以下一些思維方向：

• 分解。一個復雜的概念如何通過分解變得更容易理解和控制。

• 集成。多個模型之間以什么樣的技術方案“溝通”。

• 復用。哪些模型之間有較高重合度，可以將重合部分單獨建模重復利用。

• 分層。這就是「高內聚低耦合」思想的體現，為了讓項目更加的井然有序，將職責類似的模型歸納到同一個“層”里。

• 抽象。將模糊不清的概念進行提煉，讓其表現得更加通用，降低復雜度。

• 結構化。這是一種系統化的決策思維。比如你可以將信息通過二維表或者樹型來陳列，然后就能發現其中隱含的一些關系，幫助你決策。

• 迭代。拋棄完美主義，尋求“合適”。因為那些現在看起來優秀的架構，都是慢慢迭代出來的。

那么具體怎么做呢？

Z哥建議你可以先按照以下的步驟來進行。

搞清楚要解決的現實問題。

確定邊界。

用分解、抽象、結構化的思維來拆分問題并梳理好每個流程。

借助集成、復用、分層思維給出你認為最合理的技術實現方案。形成最終一份完整的架構。

根據對未來的預判對架構方案進行局部修正，直到合理。

在你熟練后，可以根據實際情況自行刪減一些步驟。下面我來展開說一下。

01

拿到一個稍具規模（小于一周的功能發揮空間就很小了）的功能后，首先先弄清楚“這個功能要解決的問題是什么？”。不要上來就寫代碼或者找現成的解決方案。首先不說質量如何，如果總是走一步算一步或者依樣畫葫蘆如何能鍛煉架構思維呢？

02

考慮問題所在的場景中有哪些輸入數據，最終輸出的又是什么。這樣就把問題的邊界給定下來了。

03

把問題進行拆解，看看解決了哪些小問題之后，這個問題就能被解決。這個過程中再做前面提到的，把其中的相關概念在紙上畫出來。

然后，再思考每一個小問題你是否有解決方案。如果有，那么把中間的邏輯用流程圖畫出來。如果邏輯太復雜，說明問題的顆粒度還是太大，繼續拆。如果某個小問題沒有解決方案同樣繼續拆，直到有解決方案為止。

最終形成的一個個針對每個小問題的流程圖，就是你初步的架構設計。

這個環節主要發揮你的分解、抽象、結構化的思維。

04

根據你的技術儲備，針對每一個問題給出具體的技術實現方案，選擇你認為最簡單、高效的一個即可。

然后把所有問題的解決方案放在一起看，提煉可復用的部分出來，并考慮用什么形式進行封裝。可以是一個簡單的庫，也可以是一個完整的框架，或是API等等。

這個環節主要發揮你的集成、復用、分層思維。

還沒完。

05

根據你對業務理解和與產品經理、業務方的溝通，預判一下后續可能的擴展點，看當前的設計是否能滿足。如果不能滿足，逐級逆向倒推父問題，直到找到與這個新的擴展點相關的根問題，停下來把這個根問題下面的子問題全部重新設計一下。

再重復第4步，直到得到一個當下看起來完全滿足預期的方案。至此，你就完成了一次架構設計工作。

切記，變更盡量從根問題開始調整，而不是從最近的問題開始。因為選擇后者容易積累技術債務。

最后，還是那句話。架構是迭代出來的，一次性拆分剛好能恰到好處幾乎是不可能的。

如果你想成為一位優秀的架構師，那么畫架構圖的技能也需要專門學習一下。架構圖的種類有很多，常見的類型我之前做過整理，你可以參考一下：《軟件開發中會用到的圖》。

好了，總結一下。

這篇呢Z哥和你分享了什么是架構思維，以及如何來培養架構思維。

主要分為以下5步。

搞清楚要解決的現實問題。

確定邊界。

用分解、抽象、結構化的思維來拆分問題并梳理好每個流程。

借助集成、復用、分層思維給出你認為最合理的技術實現方案。形成最終一份完整的架構。

根據對未來的預判對架構方案進行局部修正，直到合理。

希望對你有所啟發。既然都看到這了，你肯定很想成為架構師，祝愿你早日成功。

推薦閱讀：

• 職業規劃的關鍵在于「如何選擇」
  

• 怎么開會才不浪費時間？
  

原創不易，如果你覺得這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵我的創作 ：）

如果你有關于軟件架構、分布式系統、產品、運營的困惑

可以試試點擊「閱讀原文」

總結

以上是生活随笔為你收集整理的架构思维其实就那么回事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。