每个开发人员应该知道的关于软件架构的五件事

1.软件架构并不是关于大型设计

传统上，软件架构与大型设计和瀑布式交付相关联，团队可以确保在编写任何代码之前考虑软件设计的每一个最后元素。在2001年，“敏捷软件开发宣言”提出，我们应该重视“按照计划应对变化”，当面值被误解为意味着我们不应该计划。最终的结果，我已经看到了第一手，就是一些软件开发团队从前期做大设计到事先没有做设计。两个极端都是愚蠢的，如果你愿意考虑前期设计不一定是创造一个完美的最终状态，那么在某个地方就有一个相对容易发现的甜蜜点。代替，将前期设计视为创建起点并为团队设定方向。这种常常错过的步骤可以通过鼓励他们理解他们将要构建的内容以及是否会发挥作用，从而为团队增加巨大的价值。

为了达到软件设计，您需要做出一些设计决策。在讨论架构与设计之间的差异时，Grady Booch告诉我们“架构代表重大决策，其重要性由变化成本衡量。” 换句话说，哪个决定在以后的日子里变化很昂贵？继此之后，考虑前期设计的一个好方法就是确保您已经制定并理解了与“重大决策”相关的权衡。这些重大决策通常与技术选择和结构（即分解策略，模块化，功能边界等）相关。如果您正在构建一个单一的软件系统，由于多种原因，编程语言的选择可能很重要。采用微服务架构可能会降低您选择的编程语言的重要性，但会引入需要思考的其他权衡。同样，采用六边形架构可以让您将业务逻辑与技术选择分离开来，但同样存在权衡。

因此，前期设计过程应该是了解影响软件系统形状的重要决策，而不是理解数据库中每列的长度。实际上，我希望团队真正理解他们将要构建的内容，他们将如何构建它（无论如何都是高层次的），以及他们设计的内容是否有很好的实际工作机会。这可以通过确定最高优先级的风险并酌情减轻风险来实现，必要时编写代码。总之，前期设计应该是将成功的可能性叠加在你的青睐之上。

2.每个软件团队都需要考虑软件架构

我刚刚描述的内容适用于每个软件团队; 从在车库里建立一家初创公司的1人团队，到拥有数百名开发人员的全球分布团队。创建起点和方向提供技术领导。如果不这样做，往往会导致混乱 – 结构不完整，内部不一致的代码库（定型的“大泥球”）难以理解，难以维护并且可能无法满足一个或多个重要的质量属性如性能，可伸缩性或安全性。总之，每个团队都需要技术领导。

3.软件架构角色是关于编码，指导和协作

许多人拥有软件架构师的形象都是传统的“象牙塔”软件架构师向不知情的开发团队口授指令，就像第一名跑步者将在接力赛中传递接力棒一样。尽管如此，它并不需要这样，许多现代软件架构师更喜欢采用有利于编码，指导和协作设计的方法。我遇到的大多数优秀的软件架构师都是优秀的开发人员，他们仍然喜欢编码，而放弃这些并不一定是他们想要做的事情。考虑到它变化的速度，人们也很容易失去与技术联系。我喜欢认为软件架构师应该是“主要建设者”，其含义是他们可以并且尽可能将代码编写为团队的一部分。

还值得一提的是，软件架构角色不一定需要由一个人来完成。这通常是一个开始的好地方，但这个角色可以是许多人共同的合作努力。尽管如此，还是谨慎一些。警惕建议说协作技术领导很容易。这不是，软技能很难。我经常运行软件架构katas，2-5人被要求设计一个软件系统，而且我目睹了其中一些团队无法就有关设计和技术选择的决定达成共识。在极端情况下，群体因自我和人格冲突而分裂。关键是要了解你拥有的团队，然后确保你应用适当的技术领导的数量和风格。

4.你不需要使用UML

软件体系结构的传统观点经常让人联想到巨大的UML（统一建模语言）模型的图像，这些模型试图捕捉每一滴细节。不幸的是，建模和UML与前敏捷时代的“大型设计预先”实践相结合，而这些都是近年来团队抛弃的结果。在我遍布全球的旅行中，我遇到的团队中没有人知道UML的软件开发团队的比例正在增加。

近来很多人的共同建议是“仅仅在白板上使用框和线”作为交流意见的方式。多年来，我从我的软件体系结构katas中获得了千兆字节的照片，并且我可以在一定程度上相信，作为一个行业，我们已经失去了交流软件体系结构的能力。我已经看到你可以想象的每一个可能的图表; 从难以辨认的随机彩色方框和线条的集合到图表，字面上告诉你什么都没有解决方案。无法沟通软件架构的团队将无法创建我之前描述的起点和方向。

我的解决方案是一种交流软件体系结构的抽象优先方法，我称之为“C4模型” – 上下文，容器，组件和代码。它主要是为了创建一组分层的，可缩放的地图来描述一个软件系统。对于任何给定的软件系统，您可以创建一个系统环境图，描述系统如何适应周围的环境。然后，您可以放大系统边界以显示其中的容器 – 容器是可部署的，可运行的东西，例如在Web浏览器中运行的单页应用程序，服务器端Web应用程序，微服务，数据库模式，等等。如果有用，您可以进一步放大每个容器以显示其中的组件。最后，还可以选择放大每个组件以显示代码级别元素（类，接口，函数，对象等）它是由…组成的。C4模型独立于符 ，虽然我倾向于使用简单的“框和线”符 ，但您也可以使用UML。

您可以在c4model.com上找到更多信息，视频，示例图表和工具链接 ，如果您的团队努力沟通软件架构，并且您的白板/维基页面上的图表没有意义，那么肯定值得一看。

5.良好的软件架构可以提高敏捷性

“架构”和“敏捷”是相互竞争的力量，它们之间存在冲突，但仍存在一个普遍的误解。尽管如此，情况并非如此。相反，良好的软件架构可以提高敏捷性，帮助您接受并实施变更; 无论是来自需求变化，业务流程，合并等等。被认为是“好架构”的东西仍然值得争论，但无论如何，对我而言，好架构的核心特征与通过适当分解达到的良好模块性相关战略。如果你已经经历了对现有的大规模泥浆的重大改变的痛苦，那么看起来没有连接的代码库部分会崩溃，那么你会明白，有一个结构良好的代码库（良好的模块化）是非常重要的。