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