我承認我是標題黨， 為什麽要寫這篇充滿爭議的文章？目前架構師這個職位特別火熱，程序員的目標都是成為一個令人尊敬的架構師。但是我們真的理解架構師應該做些什麽？很多人把架構師和框架師等同起來，認為研究框架多的才是架構師

下面說的情況請勿對號入座。

盲目的追新：
技術人員的喜好往往是什麽技術流行就追什麽技術。現在的技術發展快，前後端不斷湧現各種框架，我們恨不得把這些框架都用在自己的項目裏才行，要不然怎麽好意思和別人打招呼啊。

我親身經歷，有個技術人員一定要把原來單元測試框架的xml初始數據改為json，他的原話是”json看的更舒服”，但是改完後，我們的單元測試反而難落地了，原因是原來的單元測試框架有個工具是可以將表中的數據自動生成xml的，而改成json後，我們必須手寫json數據了。 他的喜好不包括給大家更好用的工具。

按技術站隊，以結果反推：
很多人把手段當成了目的，成為了框架的信徒。用了Java開發，你的設計就一定是面向對象的？用了Spring boot就是微服務了嗎？這些荒唐的事情卻在技術圈不斷發生，技術人員甚至會按照語言、框架形成不同的圈子，各種技術圈互相鄙視，互相踩，真相此時無法越辯越明，反而把技術方向帶歪了。

技術要和實際場景結合

架構師也要深入了解掌握技術，但是更多的是了解技術的優劣和使用場景，而不是簡單的生搬硬套。以現在流行的微服務架構來說，Netflix使用RESTful接口作為通訊，我們是不是要把公司的用了n年的基於TCP的RPC換成RESTful接口，因為根據Netflix的實踐，RESTful可以更好的解耦、更強的伸縮性等優點，還能支持多種語言開發，互通性好。但是我們需要對RESTful徹底的理解清楚：

RESTful接口不簡單是是http+json，Richardson成熟度模型中哪個層級更合適我們的內網API通訊，HATEOAS是否需要？
RESTful的核心是資源，如何在微服務中抽象資源概念，如何將基於過程的RPC調用平滑的遷移到RESTful上？
多語言開發是快，但是後續維護如何找到穩定的Go、Scala、xxx語言程序員來源？
以上的問題應該是架構師在考慮引入新技術的時候的重點，其中對技術優劣和架構思路是核心

多研究些架構，少談些框架（4）：架構師是技術的使用者