Teaser Image

mindwind

十日画一水,五日画一石




「架构从来不是一次性的工作。」

在真正把一个需求、一种想法变成代码之前,有一个过程称之为设计。 一些经验丰富的程序员执行这个设计过程,我们称其为架构,与之对应的程序员身份也就成了架构师。

架构始于需求过程之后,描述系统的抽象构成,在系统抽象构成与现实的物理技术世界之间建立映射。 建立映射的过程其实就是我们常经历的技术选型过程。 在我过去经历的大部分 java web 项目中,技术选型基本就是框架的选择,大部分项目都使用了一些主流的开源框架来实现。 java 中各种开源通用框架的成熟度和使用广泛度都很高,看上去让选择变的简单,架构的技术选型变得更容易了。 其实不然,正是因为各种流行框架的通用和功能覆盖广,选择仅仅是被后移了,焦点不在用什么而是怎么用。

技术选型的落地,才是后续物理设计的开始。 物理设计从结构开始,包括三个方面:模块结构、数据结构、代码结构。 模块结构是为分治与协作而设计。 模块首先表达了系统抽象构成,一个系统如果整体过于复杂,就通过模块划分来达到分治。 复杂的系统将被拆分为边界清晰的模块,单一模块的复杂度将控制在可接受的范围内。 不同的模块可以分由不同的团队成员来完成,只需界定好模块之间的交互关系。

Linus Torvalds 说:“好程序员关心数据结构”。 数据结构是为功能实现而设计,这看起来像是开发过程层面才应考虑的事情? 其实不然,数据结构直接影响代码实现,好的数据结构产生更少更好的代码。 如果不在架构过程去考虑,而推后到开发过程,必然失去全局性和整体性。

代码结构是为维护和演进而设计。 不关心代码设计的架构,很容易成为空中楼阁。 过去经历的很多项目,架构的工作只做到模块层面,但真正的系统实现出来都与架构的愿景相去甚远。 架构文档上清晰的模块边界,交互过程,反应到代码上都变成了一团乱麻,剪不断理还乱。

软件系统不会随着时间推移而耗损腐坏,它只会因为变化而腐坏。 一开始清晰整洁的架构和实现随着需求的变化而不断变得浑浊、混乱。 借用一个物理学的术语“熵”,它表达体系的混乱程度,那么软件系统的熵总是随着每次变化而变得更高。 模块清晰、结构良好、代码整洁无不是为控制“熵”这一目标,需求变化带来的变动总是带来软件系统“熵”值的增长。 软件系统熵有个临界值,当达到并超过临界值后,软件系统的生命也基本到头了。 这时我们爱采取的一个行动就是干脆推倒重来吧,重写一个新的吧。 下图示例了软件系统熵值的生命周期变化。

架构始于系统生命之初,并伴随系统生命周期全程。 每次需求变化带来的变动都应进行一次或大或小的重新架构过程。 架构的焦点在于控制软件系统变动时熵值的变化。 架构的本质让我想起一句软件开发箴言:“少写代码”。 更少的代码,更少的熵。