架构设计的四大思维支柱（上）
极客时间编辑部
讲述：丁婵大小：6.98M时长：05:05
你好，欢迎收听极客视点。
支柱一：整体思维
一、从敏捷说起
敏捷诞生正是为了解决传统软件工程普遍被认为存在的“低效”问题，诸如周期长、不能快速响应需求、成果长期不可见而易导致失败等，因此，敏捷往往给人雷厉风行的印象，而很多时候，敏捷在实操上也确实由于对“速度”和“形式”的片面追求忽视了对整体的合理设计，这样的敏捷并不是真正的敏捷，而是“着急”。
敏捷开发的几位殿堂级大师对设计的重要性有着非常深刻的认知。Martin Fowler 认为敏捷注重的是演进式设计，而不是轻视设计；Sutherland 在“OODA”循环中也强调掌握全景信息而非只从自身视角看问题的重要性，每次 Scrum 结束提出 MVP，都要重走一遍循环，因为 MVP 就是为了获得更多、更全的反馈信息。有了这些信息才能快速决策，快速决策绝非快拍脑袋，是因为有模式加速了对信息的处理速度，这才是敏捷的原动力，也是要总结方法论的原因，“全景信息 + 思维模式 = 快速决策”。
敏捷开发由于其“高效”的特点，在支持快速试错的同时，也支持快速犯错，这是一体两面的，所以，敏捷开发需要有整体思维做指导而不是只关注“速度”。
二、切勿因小失大
所有局部问题的解决都离不开对整体的分析，分析的范围不同，得出的结论也会不同。面向局部的分析和面向整体的分析有很大差别，而现在的企业管理越来越注重提升整体性，因此，B 端软件的架构设计、需求解读都应当有一个全局观，分析范围不同，解决方案也可能不同。过于关注局部，将视野局限在小范围内，很可能会造成“因小失大”。
三、工具支持
基于整体分析的架构设计是一件极其耗费心力的工作，工欲善其事必先利其器。工具不仅仅是软件类工具，方法论、流程管理工具、已有的模型资产、架构管理软件都属于工具的范畴，而所有这些资产中，其实最重要的是方法论和模型资产，这也决定了架构管理软件怎么设计。
除了工具的支持，来自企业的整体支持也很重要。企业的各个部分都应当参与到整体设计中，而整体设计也应当向整个企业传导。走不出架构师的架构设计，没有持久的维持能力；走不出 IT 部门的架构设计，不会凝聚整个企业；走不出企业的架构设计，就无法真正落地企业战略。
支柱二：洞察能力
洞察能力是个老话题，任何架构方法都需要深入实践才能逐渐掌握要领，架构领域没有快餐，更多是需要反复去啃的“硬骨头”。
一、深入理解业务
做软件设计，大家常说要对业务进行深入分析，要抓住需求本质，要有合适的抽象力度，这些都是洞察能力。洞察需要的是深入理解，而不仅仅是对需求的字面理解或者浅层的沟通。
提升洞察能力，就要提升思维穿透能力。但是从企业层面而言，也有相对容易操作的方式，就是加强技术人员与业务人员的深层次沟通。如果二者之间只能具有一个聊聊需求的时间，就急着做产品上线了，那双方的了解深度必然是有限的。技术人员如果能够轮班走到业务人员中间提供实地支持，深入理解工作环境，实际感受业务压力，理解的深度自然会增加。
二、努力推进标准化
如果软件行业整体都具备了洞察能力，那标准化就应当是顺应而生的，农业和工业的发展都是这个历程。
没有标准化能力，软件行业可能无法撑起未来对软件生产的大规模需求。标准化是行业成熟的表现，也是软件行业对自身、对其他行业都具备深刻洞察力的体现，更是设计师在设计时应为之努力的方向。
以上就是今天的内容，受篇幅所限，架构设计的其余两个思维支柱将在下文分享，欢迎持续关注。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
小斧支柱一：整体思维 一、从敏捷说起 二、切勿因小失大 三、工具支持 支柱二：洞察能力 一、深入理解业务 二、努力推进标准化
Rainbow福才整体思考，洞察业务本质
收起评论