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

正文

请到「今天看啥」查看全文

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

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

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

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

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

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

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

请到「今天看啥」查看全文