现在的位置: 首页 > 综合 > 正文

架构的焦点

2018年03月30日 ⁄ 综合 ⁄ 共 1136字 ⁄ 字号 评论关闭

作者:mindwind


"架构从来不是一次性的工作“


------------------------

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


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


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


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


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


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

下图示例了软件系统熵值的生命周期变化。

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

抱歉!评论已关闭.