先前寫過一篇文章《作為軟件工程師選擇比努力更重要》
今天主要談談怎樣成長為優秀的軟件架構師？這個話題
軟件架構師的職責，並不單單是我們通常理解的，對軟件系統進行邊界划分和模塊規格的定義。
從根本目標來說，軟件架構師要對軟件工程的執行結果負責，這包括：按時按質進行軟件的迭代和發布、敏捷地響應需求變更、防范軟件質量風險（避免發生軟件質量事故）、降低迭代維護成本。
那怎么才能成長為優秀的軟件架構師？軟件架構師和軟件工程師最根本的差別又在哪里？我認為關鍵在於四個字：掌控全局。
怎么做到掌控全局？核心在於對知識脈絡的體系化梳理。
與架構相關的圖書分類:
-
架構思維類。這類圖書通常從一些著名的架構理論講起，比如開閉原則、單一職責原則、依賴倒置原則、接口分離原則，等等。這種圖書的問題在於過度理論化。計算機科學歸根到底屬於工程技術類，實踐第一。
-
設計模式類。這一類圖書則一下子進入架構的局部細節，每個模式的來龍去脈並不容易理解。就算理解了某個具體的模式，但是也很難真正做到活學活用，不知道還是不知道。
-
分布式系統架構設計類。這類圖書通常從服務端的通用問題如一致性、高可用、高並發挑戰等話題講起，講大型業務系統面臨的挑戰。這些知識是非常有價值的，但無法延伸到通用業務架構，對大部分企業的架構實踐並不具備真正的指導意義。
-
重構類。這類圖書主要講怎么把壞代碼一步步改進到好代碼。我認為這是最實用的一類。但在沒有優秀架構師主導的情況下，大部分公司的代碼不可避免地越變越壞，直到不堪重負最后不得不重寫。實際上，一個模塊最初的地基是最重要的，基本決定了這座大廈能夠撐多久，而重構更多側重於大廈建成之后，在服務於人的前提下怎么去修修補補，延長生命。
我看到不少架構師都會傾向於把架構看作一項純技術性的行為。他們的工作流程是這樣的：產品經理根據用戶的需求做出產品設計，然后架構師再依據產品設計給出實現，也就是軟件的架構設計方案。
在我看來，這其實是個誤解。架構關乎的是整個復雜的軟件工程，它關乎實現它的人，它又因團隊的能力而異。
同時，架構也關乎用戶需求，作為架構師，我們不只是要知道當前的用戶需求是什么，我們還要預測需求未來可能的變化，預判什么會發生，而什么一定不會發生。預測什么不會發生最為重要，只有做到這一點，才能真正防止架構的過度設計，把簡單的事情復雜化。