设计架构架构师

需求、想法变成代码前的过程 > 设计

一些经验丰富的程序员执行这个设计过程 > 架构

与之对应的程序员身份 > 架构师

架构始于需求之后，描述系统的抽象构成，在系统抽象构成与现实的物理技术世界之间建立映射

建立映射的过程其实就是技术选型过程

大部分 java web 项目，技术选型基本就是框架的选择

各种开源通用框架的成熟度和使用广泛度都很高，看上去让选择变的简单，架构的技术选型变得更容易了

其实不然，正是因为各种流行框架的通用和功能覆盖广，选择仅仅是被后移了，焦点不在用什么而是怎么用

技术选型的落地，才是后续物理设计的开始

物理设计从结构开始

模块结构

为分治与协作而设计

模块首先表达了系统抽象构成，一个系统如果整体过于复杂，就通过模块划分来达到分治

复杂的系统将被拆分为边界清晰的模块，单一模块的复杂度将控制在可接受的范围内

不同的模块可以分由不同的团队成员来完成，只需界定好模块之间的交互关系

Linus Torvalds 说：“好程序员关心数据结构”

为功能实现而设计，看起来像是开发过程层面才应考虑的事情？

其实不然，数据结构直接影响代码实现，好的数据结构产生更少更好的代码

如果不在架构过程去考虑，而推后到开发过程，必然失去全局性和整体性

为维护和演进而设计

不关心代码设计的架构，很容易成为空中楼阁

过去经历的很多项目，架构的工作只做到模块层面，但真正的系统实现出来都与架构的愿景相去甚远

架构文档上清晰的模块边界，交互过程，反应到代码上都变成了一团乱麻，剪不断理还乱

软件系统不会随着时间推移而耗损腐坏，只会因为变化而腐坏

一开始清晰整洁的架构和实现随着需求的变化而不断变得浑浊、混乱

物理学术语“熵”，表达体系的混乱程度，软件系统的熵总是随着每次变化而变得更高

模块清晰、结构良好、代码整洁无不是为控制“熵”这一目标，需求变化带来的变动总是带来软件系统“熵”值的增长软件系统熵有个临界值，当达到并超过临界值后，软件系统的生命也基本到头了

这时我们爱采取的一个行动就是干脆推倒重来吧，重写一个新的吧

架构始于系统生命之初，并伴随系统生命周期全程

每次需求变化带来的变动都应进行一次或大或小的重新架构过程

架构的焦点在于控制软件系统变动时熵值的变化

架构的本质让我想起一句软件开发箴言：“少写代码” 更少的代码，更少的熵