开发者需要知道的有关软件架构的五件事

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

本文文字及图片出自 InfoQ

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注