内容简介：架构师应该是一种角色，而不是一个职位
昨天看到一篇关于“架构师”的文章，读后非常有感触。我个人比较认同作者的大部分观点，故决定将原文进行翻译，和国内的开发者一起分享。原文地址： “Architect” Should Be a Role, Not a Position” 。
当一个资深的开发者变得更加资深时会发生什么事情？他们经常会被提拔做去“架构师”。有时一个架构师也不一定非要是开发者，如果他们能看到更大的蓝图。最终，总有一个人挂着“架构师”的头衔：他对要开发的系统和正在开发的系统做出架构上决策。在一些更大的公司，还有“架构师议会”，每个团队指定的架构师们聚在一起决定着一些明智的事情。
但我认为专门设立“架构师”的职位是一个糟糕的想法。架构师应该是建筑行业的一个职位，这是说的过去的，因为你不能在项目中期改变和调整架构。但是软件架构是十分灵活的，不应该预先就严格地定义好。而且开发工作和架构设计是如此的紧密关联，所以说某个人决定“什么要做”和“什么不要做”是不科学的。这会带来各种各样的问题，主要是因为架构师经常无法全面的考虑到具体的实现是怎么样。如果一个架构师长时间不写代码，他们更加倾向于忽略“实现细节”，转而仅仅考虑抽象设计。然而，抽象总是伴随着遗漏，只考虑抽象而不考虑特定的实现这样的解决方案很少行得通。
我的第一个论点就是：在不知道详细地编写所有代码地情况下，你无法在成为一个优秀的架构师。大多数情况下都不是“简单地编码”。如果你已经成为架构师多年，同时也多年没有写过代码了，那几乎可以肯定你不是一个优秀的架构师。
当然，你可能是一个优秀的架构师。或许在你所在的那个特别的公司里，有人坐在象牙塔中，指挥着 码农 去整合这个实现那个，这可能说的过去。但即使是这种情况，也有更好的方法。
架构师应该是一种角色。每个资深的团队成员都可以也应该扮演架构师的角色，不用每个团队指定一个人来当。实际上，最好有多个人来扮演架构师。在会议中讨论架构设计和讨论功能设计类似，如果你是那个要实现所有事情的人，那么你需要带着明确的想法去参会。任何的过度设计（大部分架构师经常会犯这个错误）需要在你面前证明是合理的——“我是否愿意去写这些模板代码，或者是否有一种更简单优雅的实现方式”。
职位可以使“软件工程师”，但角色可以是“敏捷大师”、”架构师”、”持续集成官”，等等。如果公司需要一个“架构师议会”去决定系统间更宏观的整合，开发者可以提名某个人去参与这些会议，这个人有可能是对这些系统最了解的人。
我知道现在架构师在想什么——有一些更加高层次的关注点开发要么不太能理解要么不应该为此被打扰。大错特错！如果你的开发不理解更高层次的架构规划，那么迟早你会遇到问题的。是的，因为他们要让代码适应你正在规划的更大的蓝图，他们需要被打扰。
还有一方面于团队成员的态度和动态的交流。如果某个不是特别优秀或者受人尊敬的开发被提升为“架构师”，那么可能破坏团队的和谐。另一方面，某些人被提升为“架构师”以后可能会过于自信，以至于他们会想当然的去做出设计决定，而不管那些反对他们的好的争论点。
所以，理想的情况（这是我的第二个论点）是取消架构师的职位。确保你团队中资深的成员能够参与架构设计和决策，那样他们可能会更有干劲，他们也会对他们开发的成果有一个更加清晰的规划。最为重要的是，架构决策不能脱离日常的“现实”的开发环境，否则它们会不必要的复杂化。
很久没有翻译了，有很多句子拿捏不准。如果有误翻的地方，还望指正，谢谢！
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
JAVA多线程设计模式
结城 浩、博硕文化 / 博硕文化 / 中国铁道出版社 / 2005-4-1 / 49.00元
《JAVA多线程设计模式》中包含JAVA线程的介绍导读，12个重要的线程设计模式和全书总结以及丰富的附录内容。每一章相关线程设计模式的介绍，都举一反三使读者学习更有效率。最后附上练习问题，让读者可以温故而知新，能快速地吸收书中的精华，书中最后附上练习问题解答，方便读者学习验证。一起来看看 《JAVA多线程设计模式》 这本书的介绍吧!
