读书笔记好记性不如烂笔头

《架构师修炼之道》读书笔记

     部分截图来源书本，如有侵权，联系删除

如何打造出色软件架构：

1-将大问题拆分位小问题

2-关注的不仅仅是功能

  还有质量属性，项目进度，团队的交付能力

3-指导大家如何协同工作

4-为复杂设计提供基本词汇

5-避免犯重大错误

6-软件如水

设计思维

 设计思维的四大原则

   以人为本

   推迟决策

   善于借鉴

   化虚为实   

思维模式

  理解

    理解需求，了解相关的利益方，换位思考，他们的业务目标和质量属性，也要掌握开发团队的工作风格

  探索

    找到可以达成目标的方法

  展示

    分享自己的设计，验证合理性

  评估

    如何验证自己的设计是合理的，可以进行场景的推演

找到够用的设计 

   将解决方案看成实验

    快速实验自己的解决方案

   设法降低风险

      时刻考虑哪里可能出错，根据风险决定设计

   简化问题

     减少或者增加约束条件，关注问题的子集

     识别常规问题

   快速迭代学习

     失败的越快学习的越快

   同时考虑问题和解决方案

       一边考虑解法，一边定义问题      

根据风险来决定何时关注架构

架构设计在项目中花费的时间决定了项目总工期和返工时间

用风险做导向

   罗列出对系统的担忧和顾虑，对他们进行排序，列出优先级，选择合适的模式降低风险

    

制定设计计划

   结束设计的条件

    设计需要花费多久时间，需求是否可以并行

  必要的设计成果

     交互时序图，uml图，设计文档

   时间节点

      关键设计工作的时间节点，需求评审，设计文档评审，项目启动

   重大风险

     罗列重大风险，在设计阶段进行规避；风险驱动设计方法

  概念架构设计

     草图描述初期想法，思考解决方案，可以更好的定义问题

 只有站在利益相关方角度看问题，才能更好的理解他们的实际需求，理解利益相关方的实际需求，就能增加解决问题的机会

换位思考（同理心）

  找合适的人谈

    利益相关方都需要了解需求

   创建利益相关方关系图

    

 了解业务目标 

     记录业务目标

        可衡量的，有明确的业务标准

         包含：主体，结果，背景 标注目标的重要性，必须有，还是可有可无

     观点填空

      帮助利益相关方表达可衡量的需求

  挖掘关键需求架构

       who  需求方是谁

      what   业务目标是什么

      why。  如何实现

   关键架构需求 asr

   四大类： 约束，质量属性，影响较大的功能需求，其他影响因素。

   技术约束与业务约束

   约束一旦确定，不能讨价还价 区分自己的决策和外界的约束

   

 积极倾听；还要去理解，设置场景，背景，个人生活习惯；提出问题，尝试理解，不去评价

  

设计产品代办列表 记录需求，反馈，关心点，反馈点

发散探索，聚合决策

   探索架构的关键点：

1.      探索元素及其作用，确定架构的结构组成
2.  探索关系及其接口，确定元素的交互方式
3. 探索架构领域，理解架构所处环境
4. 探索技术和框架，提升质量属性
5. 探索构建和部署方法，确保架构可以交付
6. 探索以往的设计，获取启发，指导决策

接受约束

   一定要分清自己选定的约束和外界的约束   

   所有的设计都是已有设计基础之上的重新设计和创建调整

    选择架构关键要看质量属性

运用决策矩阵（权衡滑块）

    第一列是质量属性，其余列是方案对比；对每一项属性的影响；直观比较，设定出 abc等级

元素功能记录表 

   每个元素都是一个独立的功能；相当于对系统进行建模

应变设计 选择合适的决策时间点

推迟决策

   可以为研究和探索争取更多的时间 避免走入死胡同和岐路

   如何判断是否是最佳决策时刻 ：灵魂七问

   收集足够的信息进行决策；把容易变化的东西移除架构

将设计决策移出架构

  solid 设计原则

  s:single responbility。单一职责

  o:open/close 开闭原则

  l：里氏代换

  i:interface segregation 接口隔离

  d:dependency inversion 依赖反转

架构模式

1.    分层模式 层间低耦合，层内高内聚  元素（层），关系(嵌套) ，使用规则
2.  端口适配器模式 
3. 管道过滤器模式 数据分析和数据转换领域 批处理模式；并列
4. 面向服务架构模式
5. 发布订阅模式  
6. 共享数据模式 大数据量和多组件系统
7. 多层模式
8. 能力中心模式 知识孤岛
9. 开源贡献模式
10. 大泥球模式

  避免架构失配

   1-是否满足质量属性

   2-实现技术与架构设计不一致

建立抽象的架构模型

  帮助大家思考和描述系统行为

  构建设计词汇

   引导我们关注更重要的细节

展示架构师的构思

设计元模型

  定义模型中使用的概念和使用规则

分离概念 好奇心循环

选择架构模式作为基础

 保持一致性

 检验模型的方式，先提问，校验模型，调整模型，直到模型可以解决问题

使用统一的架构词汇

组织代码，凸显架构

 花更多时间不一定能产生更好的设计

召开架构设计研讨会

  架构设计研讨会应该充分利用集体的智慧和经验 

   先发散后聚合

   快速 有效 有趣

   激发有价值的，可实现的想法

   可实现的想法

    有待评估的想法

    引发新问题的想法

    启动---创建---分享---批判--创建。。

基于你了解具体的业务目标和关键架构需求，清楚项目背景和研讨目标

 批判围绕设计与目标的关系展开

   为什么设计不满足目标，为什么设计不满足需求，就事论事，实事求是 

架构评估

 发现各种各样的问题

  1-风险 

     条件和结果

 2-信息留白

       盲点；系统如何运转，如何满足关键架构需求

3-麻烦

     要么选择接受它

4-认知偏差

    通过沟通指导解决

5-架构变异

   定期检查代码和文档

6-情景偏移

 不定期回顾业务目标，关键架构，利益相关方提供的材料

传授技能 辅助决策

 

鼓励团队参与架构设计 

  结对设计

   搭建支架