架构师修炼之道-读书笔记-十一、十二、十三章
十一、描述架构
架构描述的重要性
1、组织有序 展示组件是如何组织在一起的
2、在开发人员和业务相关方建立通用语
3、突出质量属性
4、理清思路
5、创建可评估的媒介
6、展示架构
软件架构描述文档 SAD
创建和查找模板
1、引言和导读信息
2、文档综述和简介
3、利益相关方诉求、业务目标和关键需求概述
4、系统情景图
5、相关视图
6、风险、未解决问题即后续工作
7、附录
编写文档时需要明白文档受众，并且用受众熟悉的语言来描述，提高可理解性。
阐述设计决策的逻辑依据
描述未选择的决策以及不选择的原因
十二、架构评估
架构评估需要回答两个问题
架构有多好，好在哪里
1、评估对象
2、评估标准 指标（待评估的架构属性）和评分（指标的打分）
3、评估结果
举办评估研讨会
开展活动来帮助评估者发现设计缺陷和潜在风险
给问题排优先级
发现架构问题
1、风险 未来可能发生的糟糕的饰器 包括条件和后果
2、信息空白 缺少足够信息判断架构是否满足关键架构需求 多提问
3、麻烦 已经出现的问题 即技术债务
4、认知偏差
5、架构变异
7、情景偏移
十三、鼓励团队参与架构设计
向团队成员传授知识和技能，让团队成员帮助自己探索想法，发散思维。辅助我们决策。
创建实践机会
举办交流会
设计下方
七级权限
1、告知 由你做决策，告知团队结果 需要展示你的设计
2、贯彻 由你做决策，向团队说明这样设计的理由
3、咨询 做决策之前质询团队意见，最终由你做决策
4、商定 团队合作，就设计决策达成共识。
5、建议 通过观点、见解影响团队。但是由团队其他成员做出设计决策
6、审查 由团队做决策 请他们解释为什么这么设计
7、委托 委托另一位成员做决策 他对结果负全责 你作为辅助成员，帮助团队收集信息
风险高，建议采用前三级
等团队有了一定经验后再考虑下放权限。
