经验经验是一个很好的衡量指标，但你应该看地更深

没有人是在一夜之间或一次升职就成为软件架构师的。架构师是一个角色（role），而非 级别。它是一个演进的过程，在这个过程中你会不断增长承担这个角色所需的经 验与自信。

架构师身上有许多不同的品质，而他们过去的经验通常是他们承担这个角色所需能力的一种 很好的度量（gauge）。架构师的角色包括很多方面，因此你需要在更深层次地去看，理解他们 在不同方面展现出来的参与度、影响力、领导力和责任。

宽泛地说，大部分项目的软件架构过程可以分成两个阶段：定义阶段和交付阶段

软件架构的定义（definition）

架构的定义过程似乎相当直接：确定需求，然后设计一个满足这些需求的系统。但实际 中并没有这样简单，随着你的参与程度和你对待自己角色的认真程度的不同，软件架构的角色也有很大变化。如下图 所示，角色的架构定义部分可以进一步分解为几个子部分。

把控更大的图

要确保架构成功落地，必须得有人在软件开发的整个生命周期内把握整张大图、向大家描绘 前景。如有必要，要跟随项目一起演进，承担将它成功交付的责任 。如果你定义了一个架构，那始终保持对架构的参与和演进是很有意义的，而不是将它交给 “实现团队”。

领导力

把控大图是技术领导力的一部分，但软件项目的交付期间，还有其它一些事情要做。包括： 向大家介绍责任（的重要性）、提供技术规范、做技术决策，以及具备做这种决策的权威。

作为架构师，你需要承担技术领导力，以保证所有的事情都考虑到了，而且团队走在正确的 道路上。软件架构师的位置天然就是关于领导力的，这虽然听起来显而易见，但很多团队中 架构师可能认为成功的交付并不是一个他们需要考虑的问题，因而并不具备所需的技术领导 力。

培训团队和指导下属

培训团队和指导下属是大部分软件开发项目中容易被忽视的一项活动，导致的后果就是，一 些团队成员并没有得到他们应该得到的帮助。虽然技术领导力是关于对项目整体进行掌舵，但也有一些时候个人需要帮助。而且，培训团队和指导下属提供了一种增强队 员技能和提升他们职业生涯的方式。

这是架构师职责的一部分，而且很显然，给你的团队培训架构和设计技能与 助他们解决代码问题之间还是有明显区别的。

质量保障

如果交付工作做的太差的话，那即使有世界上最好的架构和最强的领导力，项目仍然会失败。

质量保障是架构师角色中的很大一部分，但它远非仅仅是。例如，你需要有基准的性能指标，这意味着需要引入标准和工作惯例。从软件开发的角度讲，这包括：编码标准、设计原则，以及源代码分析工具 等等。我们可以肯定地说，大部分项目的质量保障做的并不够，因此你需要辨别出哪些是重 要的，并优先保证这些部分被执行。对于我来说，一切对架构有重要影响的，或对业务非常 关键的，或复杂的，或高度可视化的东西都是重要的。你需要务实，意识到你无法保障所有 方面，但是做一部分总是比什么都不做好。

设计、开发和测试

软件架构师角色的最后任务就是设计、开发和测试。作为一名工作在一线的架构师并不意味 着你必须参与每天的写代码任务，而是说你要持续的参与到项目中，积极主动地去帮助打造 和交付它。话已至此，那我们不禁要说，为什么每天写代码不应该成为架构师角色的一部分 呢？大部分架构师都是经验丰富的程序员，因此保持这项技能的状态是有意义的。除此之外 ，架构师还能经历团队成员都会经历的痛苦，在此过程中可以帮助他们从开发的角度理解他 们设计出来的架构。一些公司明令禁止他们的架构师参与编码工作，因为觉得他们的架构 师太宝贵了，不应该从事编码这样普通的工作。显然，这种态度是错误的，如果你不让他们参与成功交付的过程，那又为什么让他花精力设计架构呢？

当然，有些情况下让架构师参与到写代码的程度确实不太可行。例如，一个大型项目通常意 味着需要考虑很大一张图，因而不一定有时间参与到实现过程。但通常来说，写代码的 架构师比只是旁观的架构师更加高效和快乐。

你是一名软件架构师吗？

不管将软件开发和软件架构之间的那条线看作是神话还是鸿沟，本文讨论的内容都说明：软 件架构师在这个角色上的经验都随着他们参与到项目的程度和他们对待自己角色的认真程度 而异。大部分开发者都不会周一早上醒来就宣称自己是一名软件架构师了。我自己当然不是 这样，我成为架构师的过程是一个演进的过程。

彩蛋分享：转发后台私信回复【笔记】获取领取地址。

Spring面试专题：

JVM面试专题：

MySQL面试专题：

还有更多面试知识点专题：

本文所有资料分享地址请转发后私信回复关键词【笔记】获取地址，会有甄别审核，审核过后才能获取，资料整理花费了不少心血，希望能对大家今后有所帮助。感谢阅读，感谢赞赏，提前祝大家都拿到心仪offer。

相关文章