怎麼才能做軟體架構師？

01-05

需要哪些知識和學閱歷，請高人明示

稍微來點正面的，別都黑了

1. 多看書

1.1 設計模式，重構，這兩本讓我能從程序員的視野往外走一點

1.2 企業應用架構模式，領域驅動設計，比設計模式深一點，解決的也是更實際的問題

1.3 人件、人月神話、夢斷代碼，理解一下軟體工程為啥會失敗

2. 多看文章

2.1 QCon 的就不錯，有很多架構相關的PPT，拿著一個 PPT，等對方講完問題之後，自己想想，自己的解決方案是什麼？

2.2 多看看各個企業的架構變化史

2.3 多看看基礎組件的設計思路，比如 MySQL, Memcache, nginx, ...

3. 多做

3.1 做點演算法題，不是為了練習演算法，而是為了讓你思考更細緻，畢竟少考慮一個點，肯定就無法 AC

3.2 對於不同組件，自己去測試，上壓力，真實測量容量。壓死為止，看瓶頸究竟在哪兒？

3.3 到線上去，看一看你的系統，哪些響應慢，不穩定。哪些資源消耗狠，需要優化或者擴容。

還有多找人聊天，說出你的想法，等別人反駁，從別人的反駁中吸取知識，再去做驗證。

1. 溝通配合能夠和項目經理合作愉快，他管流程你管技術架構

2. 需求分析能夠將客戶的需求分析並和客戶和經理討論做出取捨合理建模

3. 技術架構講模型按照可行的方式轉換成基礎框架代碼擁有自己寫原型和深入細節的能力

4. 工程劃分能夠建立良好的模型分配給不同的團隊來實現同時掌控進度和技術難點

5. 部署集成熟悉各種管理工具配合項目進行代碼管理自動化部署自動集成等

6. 技術分析能夠每一步都能有很好的分析能力解決各個步驟的問題

@李道兵的回答很好，總結起來需要學習和提高自己的能力：

1 溝通能力

2 工程管理

3 技術全面性

4 技術深入性

5 掌握各種技術工具

6 技術與時俱進

7 全面的基本功

這些東西都可以通過看書和寫代碼來獲得

溝通能力需要一句其實就夠了：

就事論事，根據團隊情況，選擇合適的資源，平衡各個決策做出合理的技術架構和方案，

及時跟進項目中的技術關鍵點，保證項目順利完成

基礎的代碼能力，做框架代碼演進的時候需要能看到框架

基本infra的能力，你要能明白各種中間件之間的不同

企業級軟體架構能力，企業級架構包含了性能，安全，高可用，這些在普通時候不會遇到

口才，你需要能給不懂技術的各級老闆們講清楚技術，這個能力目前市面上非常欠缺

devops能力，這個可選，不太重要

同意 @李道兵的答案，但我認為還忽視了一樣。作為 architect，除了 know-how know-why 之外，最重要的就是對 requirement 的挖掘、理解、預測上，能從功能、性能、安全等不同角度有深入把握。

在 LinkedIn 上有一個 99 things architect should know 的 group，記得探討過這個問題，題主可以去查閱一下。

針對當下我想再補充一點個人看法，我不覺得 architect 就那麼理應比 developer 被看的更高級，只是不同的 focus 而已。architect 有時也是一個 developer，但 architect 還要做大量的理論分析和 inter-component 的溝通工作。牛逼的 developer，能把產品里屬於自己的那一塊每一個細節都做的爐火純青，也能在系統每次出現各種詭異時出手解圍。這都跟 architecture design 沒多大關係，但這樣的 developer 反而更缺乏。

把代碼寫牛逼了就入門了，面廣一點，那些沒寫過多少代碼就只會講架構的人說的話別太信

我不清楚，我一開始也老想做架構師，後來發現互聯網圈扯蛋的實在太多，於是退出互聯網圈也不想當所謂架構師了。

面試地點在新天地的一家德國餐館。老闆點了啤酒加肉排，我也順勢點了啤酒加漢堡。然後我就是架構師了。

架構師其實和產品經理一樣，都是為了解決問題而存在的。所以呢……平常別犯懶，更不要遇到問題躲著走。從解決小問題到能夠解決大問題，你自然就是合格的架構師。

架構師是頭銜而不是職位。一旦你是公司里最牛逼的，你就可以強行以架構師自居。

懂開發，懂運維，懂系統 =&> 懂架構。

不要以成為架構師為目的，接觸一切感興趣的。

看多了，有經驗了，也就成了。

架構師有很多種，有的靠實踐出來的，有的靠張嘴說出來的，有的被直接賦於的。

但真貨都符合一個條件 =================&> 懂松耦合，且發揮得淋漓盡致

架構師在建築領域就是建築設計師，就是那個畫圖紙的，軟體架構師跟這個差不多。

首先，要知道軟體架構是個什麼東西，明白架構的定義：

1. 一個程序和計算系統軟體體系結構是指系統的一個或多個結構。結構中包括軟體的構建，構建的外部可見屬性以及它們之間的相互關係。

2. 體系結構並非可運行軟體。確切的說，它是一種表達，使軟體工程師能夠：

① 分析設計在滿足規定需求方面的有效性。

② 在設計變更相對容易的階段，考慮體系結構可能的選擇方案。

③ 降低與軟體構造相關聯的風險。

其實架構師也是有細分的，基本上可以分為這三類：

1. 系統架構師：伺服器負載，可靠性，伸縮，擴展，資料庫切分，緩存應用等

2. 應用架構師：理解業務，梳理模型，設計模式，介面，數據交互等

3. 業務架構師：也可以叫業務領域專家、行業專家、產品諮詢師、資深顧問

通常我們說的架構師是1和2的合體，有一個前提，就是首先你要是個有著豐富實踐經驗的牛逼的程序猿，否則都是空談，然後再讓自己具備1和2的條件，這些是硬條件，只有具備了這些硬條件，你才能從技術上全方位的把控軟體的架構，這是技術層面的；但是只這些還不夠，你具體架構一個領域的軟體的時候，就要對這個領域的業務十分的了解，就是做不到業務專家的級別，最起碼也要十分了解業務，如果是做產品，這個要求就更高了，這樣你才能架構出合理的軟體。這應該就是中國所謂的架構師了...

關於技術層面的學習， @李道兵這哥們說的挺好。

做架構首先要懂軟體過程

其次架構來源於需求還要懂得需求過程在軟體過程中的需求過程占很重要的地位的

需求過程當中如需求上下文的獲取.系統的邊界的劃分角色定義角色的業務系統用例的推導系統用例的各種約束

然後通過需求之後在分析架構方面的設計之後就可以大致的分析出系統都要提供哪些模塊了

具體的模塊之間的協作圖時序圖狀態圖然後逐漸劃分出架構子系統

由大到小

(具體的設計模式重構什麼的那是程序員的時候就應該掌握了基本功了如果架構師還是在停留在會設計模式重構什麼的就太low了)

1.先讀懂客戶需求. (60%的工作都在這裡了)

2.抽象客戶需求成為技術模塊 (靠工作經驗)

3.明白如何用最合理的現有技術實現技術模塊 (靠工作經驗+讀書)

4.保證技術模塊之間的連接通暢.(只能靠團隊)

5. bla bla bla (靠嘴)

根據上面幾位大神的分析，我進行了總結。大家可以進行分析

例一、有人認為做架構首先要懂軟體過程，其次架構來源於需求還要懂得需求過程。在軟體過程中的需求過程占很重要的地位。如需求上下文的獲取.系統的邊界的劃分、角色定義、角色的業務、系統用例的推導、系統用例的各種約束、然後通過需求之後在分析架構方面的設計，之後就可以大致的分析出系統都要提供哪些模塊了。具體的模塊之間的協作圖、時序圖、狀態圖、然後逐漸劃分出架構子系統。

例二、還有人認為懂開發，懂運維，懂系統可以超越架構的概念。認為不能以成為架構師為目的，接觸一切感興趣的系統、運維、開發。在實踐經驗中看多了，有經驗了，也就能夠自然而然的成為一個架構師。

例三、還有人認為架構師其實和產品經理一樣，都是為了解決問題而存在的。所以平常需要努力，要迎難而上，不要遇到問題躲著走。從解決小問題到能夠解決大問題，你自然就是合格的架構師。

小編是這樣認為的。首先，想成為一個合格的架構師，你要知道軟體架構是個什麼概念，明白架構的定義：

1. 一個程序和計算系統軟體體系結構是指系統的一個或多個結構。結構中包括軟體的構建，構建的外部可見屬性以及它們之間的相互關係。

2. 體系結構並非可運行軟體。確切的說，它是一種表達，使軟體工程師能夠做的：

① 分析設計在滿足規定需求方面的有效性。

② 在設計變更相對容易的階段，考慮體系結構可能的選擇方案。

③ 降低與軟體構造相關聯的風險。

其實架構師也是有細分的，基本上可以分為三類：

1. 系統架構師：伺服器負載，可靠性，伸縮，擴展，資料庫切分，緩存應用等

2. 應用架構師：理解業務，梳理模型，設計模式，介面，數據交互等

3. 業務架構師：也可以叫業務領域專家、行業專家、產品諮詢師、資深顧問通常我們說的架構師是1和2的合體，有一個前提，就是首先你要是個有著豐富實踐經驗的牛逼的程序猿，否則都是空談，然後再讓自己具備1和2的條件，這些是硬條件，只有具備了這些硬條件，你才能從技術上全方位的把控軟體的架構，這是技術層面的；但是只這些還不夠，你具體架構一個領域的軟體的時候，就要對這個領域的業務十分的了解，就是做不到業務專家的級別，最起碼也要十分了解業務，如果是做產品，這個要求就更高了，這樣你才能架構出合理的軟體。這應該就是中國所謂的架構師了...

看了所有的答案，感覺沒有一個特別滿意。問什麼涅，因為，這些對架構師的認識太淺了。

首先什麼是架構，什麼是架構師？然後才是如何成為的問題。

答案里看不到啊。

另外，難道架構師就只存在網站中么。嵌入式要不要，操作系統要不要，資料庫軟體要不要，

軟體行業細分的話幾十上百，難道每一個子類的架構師都可以用一樣的知識武裝，可以用一樣的方法培養么。

還有些大而不當，空如大海的回答，真是看與不看一個樣，不知道興許更有效果。

感覺就一個字：失望

談點自己的感受。

1.首先是要有方法論，需求有需求的方法，設計有設計的方法，做架構，當然也需要有架構規劃的方法。方法論會把你的知識結構系統化的整合起來，形成一個體系，而不是case by case現想。架構規劃方法有很多，TOGAF,FEAF等。現在我主要採用的是FEAF架構方法論。

2.技術能力、業務能力的學習和沉澱，這些能力一方面通過學習活動，但主要還是通過實踐來驗證和積累。只是有知識沒有實踐，作出的架構設計很可能就是一張紙，落不了地，或者直接被實現的弟兄們鄙視。

3.綜合素質能力。架構師需要有創新能力、總結歸納能力，但個人認為最重要的是洞察力、判斷力和平衡的能力。做規劃的時候就需要預先考慮到技術、人員、時間等因素，要考慮系統和原有系統的關係，是推倒還是延伸，每種路徑都會產生不同的架構方案。不同的架構方案，就會存在不同的問題，沒有最好只有最佳，這些都需要架構師去決斷平衡。

4.保持一顆敬畏的心。明白自己的角色和責任，一將無能、累死千軍。一個錯誤規劃，可能導致實現團隊數月的工作全都白費，所有架構規劃要慎之又慎。

某A公司一百多架構師，某B公司系統全靠程序員設計，B完爆A，就是這樣，而且A的碼農由於沒有設計系統的機會，永遠只會填鴨子……

0）架構師 ≠ 軟體架構師

1）軟體架構師很多時候= 明確指出解決問題方向的人的稱號，僅此而已

領導讓你是軟體架構師你就是架構師，中國特色!干著，干著，自己也就感覺是架構師了。