架构师应该是一种角色，而不是一个职位

目前架构师既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案，确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点。

在整个软件开发过程中都起着重要的作用，并随着开发进程的推进而其职责或关注点不断地变化。在需求阶段，软件架构师主要负责理解和管理非功能性系统需求。在软件设计阶段，负责对整个软件体系结构、关键构件、接口和开发政策的设计。在编码阶段，架构师则成为详细设计者和代码编写者的顾问。随着软件开始测试、集成和交付，集成和测试支持将成为软件架构师的工作重点;在软件维护开始时，软件架构师就开始为下一版本的产品是否应该增加新的功能模块进行决策。

在DZone看到一篇关于架构师的文章。原文作者是Bozhidar Bozhanov。Bozhidar Bozhanov是一位资深的Java开发者，同时也是stackoverflow高级用户。读了他的这篇文章我的感触很深。现在分享给大家。

当一个资深开发者变得更高级时会发生什么？一般的，他们会被提拔为“架构师”。有时一个架构师不一定必须成为一个开发者，只要他们拥有更宽广的视角。“最后，总有一个人任命为“架构师”的职位，他要开发的系统和正在开发的系统做出架构上的决策。在一些更大的公司，还有“架构师议会”，每个团队指定的架构师们聚在一起决定着一些明智的事情。

但是我不认为专门设立“架构师”这样的职位是一个好的主意。架构师应该是建筑行业的一个职位，这是无可厚非的，因为不能在项目中期改变和调整原有的架构。但是软件架构是十分灵活的，会在开发的过程中需要不断的进行调整，不应该预先就严格地定义好。而且开发工作和架构设计是如此的紧密关联，所以说某个人决定“什么要做”和“什么不要做”是不科学也不严谨的。这会带来各种各样的问题，主要是因为架构师经常无法全面的考虑到具体的实现是怎么样。如果一个架构师长时间不写代码，他们更加倾向于忽略“实现细节”，转而仅仅考虑抽象设计。但是，抽象总是会造成遗漏，只考虑抽象而不考虑特定的实现这样的解决方案很少可行有效的。

我主张的第一个观点就是：如果你不知道如何详细地编写所有代码地情况下，你就无法在成为一个优秀的架构师。大多数情况下都不是“简单地编码”。如果你已经成为架构师多年，同时也多年没有写过代码了，那几乎可以肯定你不是一个优秀的架构师。

当然，好吧。你可能是一个优秀的架构师。或许在你所在的那个特别的公司里，有人坐在象牙塔中，指挥着码农去整合这个实现那个，这可能说的过去。但即使是这种情况，也有更好的方法。

架构师更应该是一种角色。每个资深的团队成员都应该扮演架构师的角色，不一定每个团队中的某个人。实际上，最好有多个人来扮演架构师。在会议中讨论架构设计和讨论功能设计类似，如果你是那个要实现所有事情的人，那么你需要带着明确的想法去参会。任何的过度设计（大部分架构师经常会犯这个错误）需要在你面前证明是合理的——“我是否愿意去写这些模板代码，或者是否有一种更简单优雅的实现方式”。

职位可以是“软件工程师”，但角色可以是“敏捷专家”、”架构师”、”持续集成官”，等等。如果公司需要一个“架构师议会”去决定系统间更宏观的整合，开发者可以提名某个人去参与这些会议，这个人有可能是对这些系统最了解的人。

我知道现在架构师在想什么——有一些更加高层次的关注点开发要么不太能理解要么不应该为此被打扰。这是大错特错！如果你的开发不理解更高层次的架构规划，那么迟早你会遇到问题的。是的，因为他们要让代码适应你正在规划的更大的蓝图，他们需要被打扰。

还有一方面，那就是团队成员的态度和互动交流。如果某个不是特别优秀或者受人尊敬的开发被提升为“架构师”，那么可能破坏团队的和谐。另一方面，某些人被提升为“架构师”以后可能会过于自信，以至于他们会想当然的去做出设计决定，而不管那些反对他们的好的争论点。

因此，理想的情况（这是我主张的第二个观点）是取消架构师的职位。确保你团队中资深的成员能够参与架构设计和决策，那样他们可能会变得更加积极主动，他们也会对他们开发的成果有一个更加清晰的规划。最重要的是，架构决策不能脱离日常的“现实世界”的开发环境，否则它们会不必要的复杂化。