架構師應該是一種角色，而不是一個職位

目前架構師既需要掌控整體又需要洞悉局部瓶頸並依據具體的業務場景給出解決方案，確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節、掃清主要難點。

在整個軟體發展過程中都起著重要的作用，並隨著開發進程的推進而其職責或關注點不斷地變化。在需求階段，軟體架構師主要負責理解和管理非功能性系統需求。在軟體設計階段，負責對整個軟體體系結構、關鍵構件、介面和開發政策的設計。在編碼階段，架構師則成為詳細設計者和代碼編寫者的顧問。

隨著軟體開始測試、集成和交付，集成和測試支援將成為軟體架構師的工作重點;在軟體維護開始時，軟體架構師就開始為下一版本的產品是否應該增加新的功能模組進行決策。

在DZone看到一篇關於架構師的文章。原文作者是Bozhidar Bozhanov。 Bozhidar Bozhanov是一位資深的Java開發者，

同時也是stackoverflow高級用戶。讀了他的這篇文章我的感觸很深。現在分享給大家。

當一個資深開發者變得更高級時會發生什麼？一般的，他們會被提拔為“架構師”。有時一個架構師不一定必須成為一個開發者，只要他們擁有更寬廣的視角。 “最後，總有一個人任命為“架構師”的職位，他要開發的系統和正在開發的系統做出架構上的決策。在一些更大的公司，還有“架構師議會”，每個團隊指定的架構師們聚在一起決定著一些明智的事情。

但是我不認為專門設立“架構師”這樣的職位是一個好的主意。架構師應該是建築行業的一個職位，這是無可厚非的，因為不能在項目中期改變和調整原有的架構。但是軟體架構是十分靈活的，

會在開發的過程中需要不斷的進行調整，不應該預先就嚴格地定義好。而且開發工作和架構設計是如此的緊密關聯，所以說某個人決定“什麼要做”和“什麼不要做”是不科學也不嚴謹的。這會帶來各種各樣的問題，主要是因為架構師經常無法全面的考慮到具體的實現是怎麼樣。如果一個架構師長時間不寫代碼，他們更加傾向於忽略“實現細節”，轉而僅僅考慮抽象設計。但是，抽象總是會造成遺漏，只考慮抽象而不考慮特定的實現這樣的解決方案很少可行有效的。

我主張的第一個觀點就是：如果你不知道如何詳細地編寫所有代碼地情況下，你就無法在成為一個優秀的架構師。大多數情況下都不是“簡單地編碼”。

如果你已經成為架構師多年，同時也多年沒有寫過代碼了，那幾乎可以肯定你不是一個優秀的架構師。

當然，好吧。你可能是一個優秀的架構師。或許在你所在的那個特別的公司裡，有人坐在象牙塔中，指揮著碼農去整合這個實現那個，這可能說的過去。但即使是這種情況，也有更好的方法。

架構師更應該是一種角色。每個資深的團隊成員都應該扮演架構師的角色，不一定每個團隊中的某個人。實際上，最好有多個人來扮演架構師。在會議中討論架構設計和討論功能設計類似，如果你是那個要實現所有事情的人，那麼你需要帶著明確的想法去參會。任何的過度設計（大部分架構師經常會犯這個錯誤）需要在你面前證明是合理的——“我是否願意去寫這些範本代碼，

或者是否有一種更簡單優雅的實現方式”。

職位可以是“軟體工程師”，但角色可以是“敏捷專家”、”架構師”、”持續集成官”，等等。如果公司需要一個“架構師議會”去決定系統間更宏觀的整合，開發者可以提名某個人去參與這些會議，這個人有可能是對這些系統最瞭解的人。

我知道現在架構師在想什麼——有一些更加高層次的關注點開發要麼不太能理解要麼不應該為此被打擾。這是大錯特錯！如果你的開發不理解更高層次的架構規劃，那麼遲早你會遇到問題的。是的，因為他們要讓代碼適應你正在規劃的更大的藍圖，他們需要被打擾。

還有一方面，那就是團隊成員的態度和互動交流。如果某個不是特別優秀或者受人尊敬的開發被提升為“架構師”，那麼可能破壞團隊的和諧。另一方面，某些人被提升為“架構師”以後可能會過於自信，以至於他們會想當然的去做出設計決定，而不管那些反對他們的好的爭論點。

因此，理想的情況（這是我主張的第二個觀點）是取消架構師的職位。確保你團隊中資深的成員能夠參與架構設計和決策，那樣他們可能會變得更加積極主動，他們也會對他們開發的成果有一個更加清晰的規劃。最重要的是，架構決策不能脫離日常的“現實世界”的開發環境，否則它們會不必要的複雜化。

如果某個不是特別優秀或者受人尊敬的開發被提升為“架構師”，那麼可能破壞團隊的和諧。另一方面，某些人被提升為“架構師”以後可能會過於自信，以至於他們會想當然的去做出設計決定，而不管那些反對他們的好的爭論點。