T31-架构设计-感悟

1、需求分析

        1.1、核心：用户诉求，站在用户的角度去思考，用户真正想要的是什么，解决用户的痛点；

        1.2、内容：项目边界（模块的复用、模块的扩展）、用户故事、用户路径（实现功能的步骤、人性化的方案、需求变成产品、化繁为简）；

        1.3、关键技术：辨别伪需求（数据化分析需求合理性、正反案例说明可改进性、推演需求合理性）、权力需求处理（先肯定再分析成本、给出PLAN B 、有根据的提出危害性）

2、问题的分层

        2.1、本源问题——用户问题
        2.2、经营视角——业务问题
        2.3、体系结构——产品问题
        2.4、架构代码——技术问题

3、KISS原则（Keep It Simple and Smile）

        3.1、Simple：架构理念（大道至简、解决问题（扩展性和可维护性、恰到好处、重构周期相对长或稳定））；
        3.2、Smile：协调能力（勇于迎接否定（业务部门——价值问题、成本部门——ROI问题、测试部门——可测试性、技术部门——可行性和工期））；

        设计系统架构时，尽量站在长久的角度去考虑，减少系统重构的风险；同时增强自身的一个协调能力，保持一个良好的心态来迎接各种挑战，这样自己才会不断成长。

4、DRY原则（Don't Repeat Yourself）

        4.1、抽象重复代码（重复代码危害：不一致性、冗余、易出bug）

        写代码时，尽量避免写重复的代码，及时进行抽象、封装，提高的整洁、可维护性。

5、七大设计原则

        5.1、单一职责：要注意编程的好习惯，不要随意在代码中添加和其功能类似的其他代码功能，注意程序的可维护性，注意代码的功能要和代码段标注的名字相一致；
        5.2、里氏代换原则：子可以继承父，但父不能继承子特性；
        5.3、接口隔离原则：接口粒度尽可能小、同一接口方法要强内聚；
        5.4、组合得用原则：不要随便组合，这样会造成接⼝污染问题，组合继承后继承了不应该继承的功能就是接口污染；
        5.5、依赖倒置原则：细节依赖抽象、底层依赖于高层；
        5.6、迪米特原则：互相了解的信息，尽可能的少；
        5.7、开闭原则：扩展开放、修改关闭（保证代码稳定性，通过依赖倒置原则来设计实现）、架购师难点（识别和隔离变化点）；
        5.8、熵增定律：解决办法熵减——即形成开放性；

        在日常开发中严格遵守这七大原则，看见代码中出现违背原则的地方，要及时的纠正，进行重构，养成良好的设计原则。

6、架构

        6.1、什么是架构？        

               6.1.1、 能⼒，不是职位
               6.1.2、是组成+决策
               6.1.3、组成是模块结构+模块关系
               6.1.4、决策是约束+设计原则+演化⽅向

        6.2、架构的⽬的
                6.2.1、确定系统边界
                6.2.2、模块之间的依赖关系与宏观输入和输出
                6.2.3、设计在框架内进行演化
                6.2.4、明确功能性需求（如安全性，可⽤性，可扩展性等）

        6.3、如何画架构图
                架构图：⽔平层⾯的业务模块加上垂直层⾯上的技术模块依赖形成的图
                        要画的架构图的类型
                        确认其中的关键要素
                        梳理关键要求之间的关联
                        输出关联关系清晰的架构图

                架构图的好坏
                        布局：注意还有图层的概念，靠近你的图层⼀定依赖于下⾯的图层
                        颜⾊：可被忽略的元素可以画成灰⾊
                        逻辑：表达出各要素之间的依赖关系

                架构图的分类
                        业务架构:按业务单元进⾏边界划分
                        应⽤架构:按系统的层次来划分,⼀般是垂直依赖型
                        数据架构:存储数据的架构逻辑等
                        技术架构:应⽤架构的技术需求

                传统架构图
                        物理视图:⼀般不画
                        逻辑视图:逻辑结构图
                        开发视图:UML图
                        处理视图:UML图
                        场景视图:⽤UML的⽤例图