架构师及其目标在软件项目中的挫折感

软件架构在软件项目中是否经常做得糟糕，经常被忽视了呢？这是CodingTheArchitecture.com的创始人兼独立咨询师Simon Brown在最近一篇博文中提到的一种现象。Brown认为这是对架构的误解，是敏捷项目中随意的架构方法导致架构走到如此糟糕的境地。

\u0026#xD;\n

Brown说，脱离现实的象牙塔里的架构师继续损害着软件架构的声誉。很多架构师不是通过与开发团队的紧密合作设计出切实可行且深思熟虑的解决方案，相反，他们脱离开发者，交出一大堆高层规范。当软件架构师不能给项目带来直接价值时，其结果往往是架构工作被边缘化，致使一些并无准备的开发者承担软件设计的职责。Brown认为这是架构面临的主要问题，而且敏捷项目使问题进一步恶化。他说，敏捷项目常常以快速交付之名忽视坚实的架构原则。

\u0026#xD;\n

\u0026#xD;\n

那些陈旧的软件架构到底是什么？许多软件开发团队认为他们并不需要软件架构师，取而代之提出了诸如“自治团队”、“YAGNI”、“演化架构”、“最后责任时刻”的术语。若他们的确需要架构师，那么他们寻找的可能是“敏捷架构师”。我并不太清楚这个词的实际含义，但是我猜它应该包含使用便签帖（Post It）代替UML或使用TDD取代架构图的意味吧。总之，我假设他们已经抛弃了仅使用高层系统隐喻的观念，并且没有把“紧急设计”作为期待一切顺利的借口。

\u0026#xD;\n

\u0026#xD;\n

希望仍然是有的。Brown坚信任何项目中都有架构原则的一席之地。但是，他要求软件架构社区通过更好地工作来解释架构师的价值，为未来的架构师进行投资。InfoQ联系到Brown并向他询问了一些关于架构的现状以及如何提升该角色相关的问题。

\u0026#xD;\n

InfoQ：引用您博文中一条评论，“架构师到底应该做什么？”

\u0026#xD;\n

\u0026#xD;\n

Brown：“架构师”这一词汇所面临的主要问题是，每个人、团队或组织对它都有自己的定义。对我而言，软件架构师角色就是将技术领导力带入软件团队。我们坚信所有项目必须要有预先的设计，而其中妙处就在于如何做到“恰到好处”，简单来说，就是创建最初的高层结构，应对重大风险，确定其他团队成员认可的愿景。除了这些事先设计的工作之外，架构师的角色还要在整个交付生命周期中，在必要时刻负责并改进最初的设计。需要强调的一点是，我这里谈的是角色而非职位，该角色可由一个人承担也可有团队里的多人承担。我最近在2012伦敦的QCon大会上组织了一个研讨会，在会议上我回答了许多关于软件架构师角色的问题。读者可以从http://www.codingthearchitecture.com/2012/03/13/photos_from_my_qcon_london_2012_tutorial.html阅读问题小结，有意思的是我们在这里谈论的角色与许多组织里的该角色差别很大。

\u0026#xD;\n

\u0026#xD;\n

InfoQ：为什么您认为软件架构仍然被人们误解了呢？怎么才能更好地理解这一角色呢？

\u0026#xD;\n

\u0026#xD;\n

Brown：我认为软件架构被误解的原因是软件架构角色在行业中的名声太坏，另外许多关于它的科教材料都太抽象太学术化。所谓的“业务技术战略师”和“业务价值呈现”不会吸引开发者，相反大多数开发者对此望而却步。我们创建“Coding the Architecture”网站的目的就是为大家带来一种与软件开发者喜爱的务实且有效的软件架构视图。为什么？因为太多软件项目因为最基本的原因而失败，我非常喜欢看到软件架构能够简单地像软件开发角色的一部分，如此每个软件开发者都能拥有这样的基础。在我们梦想打造的自组织团队中，每个软件开发者发展成软件架构师是在正确的方向上发展中的理所当然的一步。

\u0026#xD;\n

\u0026#xD;\n

InfoQ：在这篇博文中，你提出了一个反问“敏捷需要架构或架构当真需要敏捷吗？”那么你自己如何回答这一问题。

\u0026#xD;\n

\u0026#xD;\n

Brown：所有的软件项目，不论它有多敏捷，都应该考虑“架构”，因为重要的非功能性需求和限制并未消失。所以答案是肯定的，敏捷项目需要软件架构师角色，但是不幸的是许多项目团队由于迫不及待地采用敏捷而忘记了这一点。而另一方面，传统项目的软件架构也需要从轻量级方法学习很多，而敏捷成功地展示了这一点，它告诉人么不需要为每件事做大量的前期设计。

\u0026#xD;\n

\u0026#xD;\n

InfoQ：你认为从开发者发展成架构师是自然而然的吗，有没有从别的方向发展过来的不同的路径。

\u0026#xD;\n

\u0026#xD;\n

Brown：这又是一个只能回答“看情况”的问题。有一些软件开发者对职业的爱好是受编码驱使的，他们喜欢在这个层面上保持创造力。而另外一些人则喜欢在更广阔的范围内迎接软件设计的挑战。我所认识的最好的架构师都有深厚的技术功底，而且在其成为“技术大牛”之后才转做架构师的。对技术的理解非常关键，而退一步从“全局”去理解软件及其部署环境背后的驱动力同样重要。一个好的软件架构师要二者兼备，这解释了为什么并非每个软件开发者的下一步发展方向都是架构师的问题。另外，还要消除一个神秘观念，事实上，成为软件架构师并不意味着放弃编码。

\u0026#xD;\n

\u0026#xD;\n

InfoQ：你如何在一个组织中“培养”架构师？

\u0026#xD;\n

\u0026#xD;\n

Brown：很不幸，许多公司里都没有这回事。大多数的情况是，软件架构师或者被扔进泥潭任凭他们在那里挣扎，因为他们得不到帮助和支撑，或者他们被推向管理岗位。如果组织鼓励角色间的协作，鼓励已经在架构师职位的人去指导或带领其他人，那么培养软件架构师的技能就变得非常简单。整个软件团队都要采用软件架构，为何不让他们参与进来并影响它呢？此外，组织还可以组织一些内部“架构实战营”，这样人们就可以实践从头开始设计软件。说到底，有多少软件架构师能够这样有系统地实践架构呢？

\u0026#xD;\n

您可以访问http://www.codingthearchitecture.com/2012/01/05/contextualising_just_enough_up_front_design.html 获取更多关于软件架构实践的更多指导。

\u0026#xD;\n

---

查看英文原文：Frustration with the Role and Purpose of Architects on Software Projects