《架构整洁之道》第 2 章 两个价值维度
1 / 0 / 创建于 1年前 /
巴啦啦 的个人博客
均为原创，读架构整洁之道的笔记。
包含了部分自己的理解，包含了原书中至少 70% 的知识点。
完整笔记，各位老哥友链加起来吧。
我的博客地址：www.yuque.com/_huangkuan
该篇提出了一个问题：系统行为和系统架构的灵活性，哪个更重要？即系统正常工作更重要，还是系统易于修改更重要。**分别对应了软件系统的两个价值维度。**
对于业务人员来说，是系统行为和正常工作更重要，而开发通常跟随采取这种态度。这种态度是错误的。
理由如下：
- 如果程序可以正常工作，但是无法修改，当需求变更时，即使正常工作的程序，也会变得不正常。
- 如果程序不可以正常工作，但是容易修改，那么将其修复增改是能够轻松做到的事。
艾森豪威尔矩阵
将矩阵中的事件按价值排序如下：
| 1. 重要且紧急 | 2. 重要不紧急 |
|---|---|
| 3. 不重要但紧急 | 4. 不重要且不紧急 |
我有两种难题：紧急的和重要的，而紧急的难题永远不是重要的，重要的难题永远是不进击的。
将上述两个价值维度代入到这种难题中：
系统行为：是紧急的，但是并不总是特别重要。
系统架构：是重要的，但是并不总是特别紧急。
可以看出，系统架构这个价值维度，占据了该矩阵中的**前两名**。即都重要。
而业务部门和开发部门常常犯的错误就是将排名第三的，不重要但紧急的事情，放在第一优先级去做。
其次就是业务部门原本就没有能力去评估系统架构的重要性，这应当是开发部门的职责。
所以开发部门有义务和责任，将系统架构的重要性放在第一位。
为好的软件架构而持续斗争
为了做好上述的职责，开发部门需要做好长期斗争的准备，必须要为公司的长远利益出发，和其他业务部门做抗争。公司雇佣你来做软件开发的原因就是需要你把这个角色做好。
如果你是软件架构师，那么这项工作就更重要了。如果系统变得越来越难以维护，则说明软件开发团队没有和需求方做足够的斗争，没有完成自己应尽的职责。
本作品采用《CC 协议》，转载必须注明作者和本文链接
关于 LearnKu
粤公网安备 44030502004330号