架構師需要參與項目開發的全部過程，包括需求分析、架構設計、系統實現、集成、測試和部署各個階段，負責在整個項目中對技術活動和技術說明進行指導和協調。

架構師主要職責有4條：

1、確認需求

在項目開發過程中，架構師是在需求規格說明書完成后介入的，需求規格說明書必須得到架構師的認可。架構師需要和分析人員反復交流，以保證自己完整并準確地理解用戶需求。

2、系統分解

依據用戶需求，架構師將系統整體分解為更小的子系統和組件，從而形成不同的邏輯層或服務。隨后，架構師會確定各層的接口，層與層相互之間的關系。架構師不僅要對整個系統分層，進行“縱向”分解，還要對同一邏輯層分塊，進行“橫向”分解。

軟件架構師的功力基本體現于此，這是一項相對復雜的工作。

3、技術選型

架構師通過對系統的一系列的分解，最終形成了軟件的整體架構。技術選擇主要取決于軟件架構。

Web Server運行在Windows上還是Linux上?數據庫采用MSSql、Oracle還是Mysql?需要不需要采用MVC或者Spring等輕量級的框架?前端采用富客戶端還是瘦客戶端方式?類似的工作，都需要在這個階段提出，并進行評估。

架構師對產品和技術的選型僅僅限于評估，沒有決定權，最終的決定權歸項目經理。架構師提出的技術方案為項目經理提供了重要的參考信息，項目經理會從項目預算、人力資源、時間進度等實際情況進行權衡，最終進行確認。

4、制定技術規格說明

架構師在項目開發過程中，是技術權威。他需要協調所有的開發人員，與開發人員一直保持溝通，始終保證開發者依照它的架構意圖去實現各項功能。

架構師與開發者溝通的最重要的形式是技術規格說明書，它可以是UML視圖、Word文檔，Visio文件等各種表現形式。通過架構師提供的技術規格說明書，保證開發者可以從不同角度去觀察、理解各自承擔的子系統或者模塊。

架構師不僅要保持與開發者的溝通，也需要與項目經理、需求分析員，甚至與最終用戶保持溝通。所以，對于架構師來講，不僅有技術方面的要求，還有人際交流方面的要求。

架構師的誤區

1、架構師就是項目經理

架構師不是項目經理。項目經理側重于預算控制、時間進度控制、人員管理、與外部聯系和協調等等工作，具備管理職能。一般小型項目中，常見項目經理兼架構師。

2、架構師負責需求分析

架構師不是需求分析員。需求分析人員的工作是收集需求和分析需求，并與最終用戶、產品經理保持聯系。架構師只對最終的需求審核和確認，提出需求不清和不完整的部分，他會跟需求分析員時刻保持聯系。架構師是技術專家，不是業務專家。

3、架構師從來不寫代碼

這是一個尚存爭論的問題。目前有兩種觀點：

觀點1：

架構師不寫代碼，寫代碼純體力活，架構師寫代碼大材小用。架構師把UML的各種視圖交給開發人員，如果有不明確的地方，可以與架構師隨時溝通。

觀點2：

架構師本來自于程序員，只是比程序員站的層面更高，比程序員唯一多的是經驗和知識，所以架構師也免不了寫代碼。

我個人覺得這兩種說法是與架構師的出身和所處的環境有關。

架構師首先是一個技術角色，所以一定是來自于技術人員這個群體，比如系統架構師，多是來自于運維人員，可能本身代碼寫得并不多，或者說寫不出來很漂亮的代碼。軟件架構師多是來自于程序員，有著程序員的血統和情懷，所以在項目開發過程中，可能會寫一些核心代碼。我們的理想是架構師不用寫代碼，但事實上有時候過于理想。架構師寫不寫代碼，可能取決于公司的規模、文化、開發人員的素質等現實情況。

原文地址：https://www.toutiao.com/i6901592091944944135/