开发者需要知道的有关软件架构的五件事_研发效能_Simon Brown



 写点什么

本文要点：

因为软件系统的分布式特点以及开发团队的分布性，了解软件架构的基础变得越来越重要。

在过度设计和毫无设计之间，我们应该把注意力放在对软件系统有重大影响的决策和权衡上。

好的架构师应该是团队的活跃分子，不仅能够进行代码协作，还能为团队提供技术指导。

软件架构中的沟通环节极具挑战性。C4 模型对软件架构中的沟通环节进行了结构化，从一个上下文图表开始，再逐步深入到系统的各个技术层面。

实际上，可以多花一些时间实现好的架构，好的架构能够带来敏捷。

2010 年，我写了一篇叫作“ Are You a Software Architect? ”的文章，探讨了软件开发者与软件架构师之间的区别，以及如何从一名软件开发者转成一名架构师。8 年过去了，软件行业也在发展，但开发团队仍然面临着类似的问题，特别是与软件架构有关的问题。这些问题比以往任何时候都要来得突出，因为我们现在构建的系统越来越趋于分布式化，开发团队也越来越分布式化。为了解开这些迷思，开发者需要了解以下五个与软件架构有关的事实。

1. 软件架构不只是前期的“大设计”

传统的观点认为，软件架构就是在前期进行“大设计”，然后通过瀑布模型进行交付，架构团队要确保软件的每一个元素在进行编码之前都要考虑妥当。2001 年，“敏捷开发宣言”建议我们“拥抱变化而不是遵循计划”，但这个观点后来却被误读成不应该制定任何计划。结果就是，有些开发团队直接从原先的“大设计”变成了零设计。这两种极端的行为都愚蠢至极，实际上，在某个时候，你会发现前期的设计并非开发出完美软件的必要因素。前期的设计应该只是一个起点，或是作为团队前进方向的指引。

在进行软件设计时需要做出一些设计决策。在谈及软件架构和软件设计之间的区别这个问题时，Grady Booch 说，“架构代表了重要的决策，决策的重要程度通过变更成本来衡量”。换言之，就是看在后续进行变更时那个决策需要付出更大的成本。所以，好的前期设计就是要充分理解什么是“重要的决策”。这些决策通常与技术选型和结构（也就是分解策略、模块化、功能边界等）有关。如果开发的是一个单体系统，那么选择何种编程语言可能就变得尤为重要。如果采用的是微服务架构，那么使用何种编程语言就变得不那么重要，但需要考虑其他方面的因素。类似的，如果采用了六边形架构，虽然可以将业务逻辑与技术选型解耦开来，但仍然需要做出其他方面的权衡。

所以说，前期设计就是要了解影响软件成型的重要决策，而不是具体的技术细节，比如数据库的某个列要设置多大的长度。在现实当中，我会让团队真正去了解他们将要做什么、如何去做以及他们已经设计好的东西是否可行。可以让他们识别出最高优先级的任务，如果有必要可以写出代码。总而言之，前期设计就是一个叠加成功几率的过程。

2. 每个开发团队都需要进行软件架构

上述的内容适用于每一个开发团队，从一个单人团队到数百人的分布式团队。设置起点和方向其实就是要建立技术领导力。如果做不到这一点，就可能出现混乱：结构混乱的代码库（典型的“大泥球”），难以理解，难以维护，质量不达标，如性能、伸缩性或安全性。简而言之，任何一个开发团队都需要技术领导力。

3. 软件架构师要会写代码、指导他人以及参与协作

在大部分人看来，软件架构师就是给开发团队下达指令的人，就像接力赛中跑第一棒的人。但事实不是这样的，现代的架构师喜欢编码、指导他人并参与协作。我所遇见的好架构师也都是好的开发者，他们仍然喜欢编码，最起码他们并不想放弃编码工作。因为变化太快，人们很容易就与技术失之交臂。但我认为软件架构师应该是“建筑大师”，在必要的时候他们仍然可以写代码。作为团队的一份子，编码会让架构师的工作变得更容易一些，因为编码有助于架构师理解系统，而且团队的其他成员会真正把架构师当成是同事。

需要注意的是，软件架构师不一定要指定某个人来担任。刚开始可以这样做，但其实也可以由多个人共同承当这个角色。但要注意，建立协作式的技术领导力并不是件轻而易举的事。软技能本来就不是很轻松就能获得的。我曾经组建 2 到 5 个人的架构师小组，让他们来设计软件系统，但他们在与技术和设计决策方面无法达成共识。在极端情况下，个性冲突会导致小组解散。关键是要了解你的团队，并确保应用了恰到好处的技术领导力。

4. 使用 UML 不是必需的

传统的软件架构通常包含大量的 UML 模型图，试图充分展现软件系统的每一个细节。可惜的是，建模和 UML 在很大程度上与前期“大设计”相耦合，而这些技术在近几年已经过时了。现在完全不懂 UML 的软件开发团队比率在逐步上升。

现如今，大部分人只是“在白板上画几个方块和线条”，并将其作为沟通想法的手段。在过去几年，我参与过的软件架构小组画过大量这样的图表，我把它们拍成照片，有好几个 G。我敢说，从行业角度来讲，我们已经散失了软件架构的沟通能力。我见过不计其数的图表，它们有些是随机着色方块和线条的组合，模糊不清，难以辨认。如果一个团队无法就软件架构进行沟通，那么就无法设置起点和建立技术领导力。

我建议使用“C4 模型”来进行软件架构方面的沟通——上下文（Context）、容器（Containers）、组件（Components）和代码（Code）。其本质是创建一系列结构化、可伸缩的图表来描述软件系统。为每一个软件系统创建一个上下文图表，用于描述软件系统与真实世界之间的关系。然后放大系统边界，让内部的容器突显出来——容器就是可部署、可运行的实体，比如运行在浏览器上的单页应用、服务器端的 Web 应用、微服务、数据库实例，等等。如果有必要，可以再将每个容器放大，让容器内部的组件突显出来。最后，你也可以放大组件，让代码级别的元素（类、接口、函数、对象等）也突显出来。C4 模型独立于具体的表示方法，虽然我倾向于使用简单的“方块和线条”，但使用 UML 来表示也是可以的。

c4model.com 提供了更多的信息、视频、示例图表和工具链接。如果你的团队正纠结于软件架构沟通方面的问题，那么可以看看这些资料。

5. 好的软件架构是敏捷的

现在仍然存在一种误解，认为“架构”和“敏捷”之间是一种竞争和冲突的关系。但其实不是的。相反，好的软件架构也是敏捷的，它有助于应对业务变更，不管是需求变更、业务流程变更还是混合变更。当然，什么才是“好的架构”仍然有待商榷，但我认为，好的架构与好的模块化息息相关。如果你曾经有过在“大泥球”上进行变更的痛苦经历，那么你就会知道，好的代码库结构（好的模块化）是多么的重要。

现如今，很多团队都存在一个很大的问题，他们采用了一种叫作“架构中立的设计”，George Fairbanks 在他的“ Just Enough Software Architecture”一书中对此进行了描述。换句话说，他们采用了一种不需要考虑权衡因素的架构风格。在现实中，开发团队使用微服务架构代替单体代码库。但实际上，他们有可能是创建出了一种“分布式的大泥球”，可见软件设计和分解过程是多么的重要，不管是要构建一个单体还是一个微服务架构的系统。敏捷和好的软件架构不是那么容易就能实现的，它需要一些精巧的设计，也需要作出一些权衡。这也再次说明为什么设置起点和建立技术领导力是如此的重要。