当软件行业的人们谈论“架构”时，他们指的是一个模糊定义的概念，即软件系统内部设计中最重要的方面。良好的架构非常重要，否则将来添加新功能的成本和时间都会增加。像软件界的许多人一样，我长期以来一直对“架构”这一术语持谨慎态度，因为它通常暗示与编程的分离以及一种不健康的自负。但我通过强调良好的架构是支持自身演变的，并与编程深深交织在一起，来化解我的担忧。我职业生涯的大部分时间都围绕什么是良好的架构、团队如何创建它以及如何在我们的开发组织中培养架构思维等问题展开。此页面概述了我对软件架构的看法，并指向网站上有关架构的更多材料。 2019年8月1日 什么是架构？软件领域的人们长期以来对架构的定义争论不休。对某些人来说，它就像一个系统的基本组织，或最高级组件的连接方式。我的这一思考源于与拉尔夫·约翰逊的一封电子邮件交流，他质疑了这一表述，认为没有客观的方法来定义什么是基础或高级，并且更好的架构观点是专家开发者对系统设计的共享理解。拉尔夫·约翰逊在QCon大会上发言。 另一种常见的架构定义风格是“在项目早期需要做出的设计决策”，但拉尔夫对此也表示不满，称这更像是你希望在项目早期能做对的决策。他的结论是“架构是关于重要的东西，无论那是什么。”乍看之下，这听起来很陈词滥调，但我发现这蕴含着丰富的内涵。这意味着，以架构的思维来考虑软件的核心在于决定什么是重要的（即什么是架构），然后将精力花在保持这些架构要素良好状态上。要成为架构师，开发者需要能够识别哪些要素是重要的，并意识到哪些要素如果得不到控制可能会导致严重问题。拉尔夫的电子邮件构成了我为IEEE软件撰写的专栏的核心，讨论了软件架构的意义以及架构师的角色。 为什么架构很重要？架构对软件产品的客户和用户来说是一个棘手的话题，因为它不是他们立即能察觉到的东西。但劣质架构是导致代码杂乱的主要因素——这些软件元素妨碍开发者理解软件的能力。包含大量杂乱的代码的软件更难以修改，导致功能的交付更慢且缺陷更多。这种情况与我们的普遍经验相反。我们习惯于“高质量”的东西通常成本更高。对于某些软件方面，例如用户体验，这可能是正确的。但就架构和其他内部质量方面而言，这一关系则被颠倒。高内部质量会加快新功能的交付，因为杂乱减少了干扰。虽然在短期内我们确实可以为更快的交付牺牲质量，在杂乱产生影响之前，但人们低估了杂乱带来整体交付速度减慢的速度。虽然这不是可以客观衡量的，但有经验的开发者认为，对内部质量的关注能在几周内得到回报，而不是几个月。 阅读更多……在2015年的OSCON大会上，我作了一个关于架构及其重要性的简短演讲（14分钟）。 应用架构 软件开发中重要的决策会随我们思考的上下文规模而变化。一种常见的规模是应用程序，因此有了“应用架构”。定义应用架构的第一个问题是，没有清晰的定义什么是应用程序。我的观点是应用程序是一种社会构造：由开发者视为单个单元的代码体；由商业客户视为单个单元的功能组；由资金提供者视为单个预算的倡议。如此宽松的定义导致应用程序的潜在规模各异，从几个到数百人的开发团队。你会注意到我从参与人员的数量来衡量规模，这在我看来是评估此类事物最有用的方式。 这与企业架构的关键区别在于，社会构造周围存在着显著程度的统一目标。 应用边界 软件开发中未决定的问题之一是…