如何成为一个技术全面的架构师

架构师是一个充满挑战的职业，需要关注很多维度和技术。只专注于单一领域的架构师并不是优秀的架构师。Pat Kua（原ThoughtWorks咨询师）是一位经验丰富的技术人员，他在本文中指出一个好的架构师需要是技术全面的架构师，并探讨了成为一个技术全面的架构师所必须具备的六个方面。

作为技术领导者

一名好的软件架构师需要明白，作为领导者并不一定要告诉开发人员做什么。相反，好的架构师就像一个导师，带领开发团队向同一个技术愿景前进。好的架构师会借助于讲故事、影响力、引导冲突、构建信任等领导技能，将他们的架构愿景变成现实。一个好的领导者，同时也是一个好的架构师。他/她会仔细听取每个参与者的意见，通过与团队的反馈互动调整他们的愿景。

作为开发人员

一个架构师同时又是一个好的开发人员。通常，做出一个良好的架构选择需要权衡理想的架构状态与软件系统的当前状态。例如，如果一个问题更适合采用关系型数据库来解决，那么将文档数据库引入到系统中的做法是毫无道理的。一个架构师如果不考虑技术选型与问题域之间的匹配度，那么会很容易受到各种技术的诱惑——这也就是常见的“象牙塔式架构师”行为模式。

缓解这种情况的最佳方式是架构师多与开发人员待在一起，花一些时间在代码上。了解系统的构建方式及系统的约束将帮助架构师在当下环境做出正确的选择。

聚焦系统

经验丰富的开发人员明白代码只是软件的一个方面。为了让代码可运行，他们还需要了解代码在生产环境中运行良好所需的其他重要质量属性。他们需要考虑部署过程、自动化测试、性能、安全和可支持性等方面。开发人员可能以临时的方式来实现这些质量属性，而架构师不仅需要专注于了解代码，还要了解并满足不同利益相关者（如支持、安全和运营人员）的需求。一个好的架构师需要专注于寻找那些能够满足不同利益相关者需求的解决方案，而不是选择针对某一个参与者的偏好或风格进行优化的工具或方法。

企业家思维

所有的技术选型都有相关的成本和收益，一个好的架构师需要从这两个角度考虑新的技术选型。成功的企业家愿意承担风险，不过也会寻求快速学习和快速失败的方法。架构师也可以用类似的方式做出技术选型，收集真实世界中有关短期和长期成本的信息，以及他们可能意识到的好处。

这方面一个很好的例子是，架构师避免承诺立即使用一个在阅读新文章时看到的工具或某一会议上听过的工具。相反，他们试图通过架构调研来了解工具在其环境中的相关性，以收集更多信息。他们对于工具的选择不是基于销售量，而是考虑他们需要什么以及这个工具所提供的价值。他们还会寻找这些工具背后的隐性成本，例如工具的支持情况（如文档化程度、社区使用情况），工具可能带来的约束或长期来看可能引入的额外风险。

权衡策略思维与战术思维

许多团队由一些独立的开发人员一起构建软件，而每个人都倾向于选择自己最舒适或最有经验的工具和技术。好的架构师持续关注可能有用的新技术、工具或方法，但不一定立即采用它们。技术采用往往需要长期的考量。架构师将在团队和组织层面寻求敏捷度（允许团队快速采取行动）和对齐（保持足够的一致性）之间的良好平衡。建立自己的技术雷达这样的练习是用战略思维探索技术的一个有用工具。

良好的沟通

架构师需要知道，有效沟通是建立信任和影响团队以外成员的关键技能。他们知道不同群体使用不同的词汇，而使用技术术语和描述与业务人员沟通将会变得比较困难。与其谈论模式、工具和编程概念，架构师需要使用听众熟悉的词汇与之交流，诸如风险回报、成本和收益等。这比单纯使用技术词汇进行沟通来得更好。架构师还需要认识到团队内部沟通与外部沟通同样重要，可以使用图表和小组讨论的方式来建立和完善技术愿景，并书面记录之（如架构决策日志或Wiki等），从而为将来留下可追溯的历史。

结论

最后Pat指出，做一个技术全面的架构师并不容易，因为有很多的方面需要我们关注，而每个方面都有很多作为开发人员经常不会专注去练习的技能。其实最重要的不一定是一个架构师的能力，而是他们在每个不同的领域都有足够的专业知识。仅仅掌握上述某个领域的架构师不如在六个方面都有良好专业知识的架构师来得更有价值。

想获取Java工程化、高性能及分布式、高性能、性能调优、Spring，MyBatis，Netty源码分析，nginx、dubbo、java分布式、redis、jvm、多线程、java网络编程、netty、kafka资料的加群：651013434

是针对有1到5年工作的经验的java开发人员，帮助突破技术瓶颈，提升思维能力