一提到架構，很多程序員可能會立刻心生敬畏，覺得這是一件很高端、很難且極具挑戰的事情。然而，與編程相比，架構更多地關注宏觀層面。雖然架構確實存在一些挑戰，但在某些時候，架構的 “世界” 在復雜度上可能還不如編碼中的細枝末節那么大。所有程序員都應盡可能早地培養自己的架構思維。即便你未來不從事架構相關工作，但擁有架構思維能極大地開拓你的視野，助力你在技術道路上走得更遠。

在了解具體的架構思維培養方法之前，需先明確架構的意義究竟是什么。簡單來說，架構表達的是一種關系，即多個現實元素之間的關系。這里有兩個關鍵詞：關系和現實。其中，“關系” 很好理解，指的是不同事物之間以何種形式共存。而 “現實” 卻常常容易被人忽視，因為它顯得很平常。但是，在做架構時，如果對某些現實的定義不精準，那么后續的工作大概率也是錯誤的。所以，要做好架構，第一步就是先明確當前要解決的問題或要達成的目標，并弄清楚其中涉及的相關概念所表達的業務含義。你可以將這一步中得到的相關概念用工具或者紙筆畫出來，平鋪開來即可。

圖片

做完這一步，接下來就是傳統意義上做架構的過程。對于這個過程，可以用一句話來概括：架構的過程其實就是建模的過程。所謂建模，就是進一步細化當前的事物，并基于所得信息做相關的延展和規劃，循序漸進，得到一個完整的、可執行的方案的過程。

說起來容易，做起來卻并不輕松。在架構的過程中，會涉及到分解、集成、復用、分層、抽象、結構化以及迭代等方面。具體該怎么做呢？可以參考以下 5 個步驟。

第一步：搞清楚要解決的現實問題。

當拿到一個稍具規模的功能后，需先弄清楚這個功能要解決的問題是什么，不要一上來就寫代碼或者找現成的解決方案。總是依樣畫葫蘆的話，很難培養出自己的架構思維。

第二步：確定邊界。

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

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

把問題進行拆解，看看解決了哪些小問題之后，這個大問題就能被解決。然后，思考每一個小問題是否有解決方案。如果有，可以把中間的邏輯用流程圖畫出來。如果邏輯太復雜，那就說明設置的問題顆粒度還是太大，繼續拆。如果某個小問題沒有解決方案，同樣繼續拆，直到有解決方案為止。

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

根據自己的技術儲備，針對每一個問題給出具體的技術實現方案，選擇最簡單、高效的一個。然后把所有問題的解決方案放在一起看，提煉可復用的部分出來，并考慮用什么形式進行封裝。可以是一個簡單的庫，也可以是一個完整的框架，或是 API 等等。

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

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

圖片

整個流程下來，就完成了一次架構設計工作，這些工作可以幫助你培養自己的架構思維。等慢慢熟練之后，也可以根據實際情況自行刪減一些步驟。