T31项目Day1

       之前负责项目都是直接听客户需求，整理后就直接动手，所以坑也掉了不少，但今天听完一节关于需求分析及设计的课后，感受最深是那一句话-- 架构是一种能力，而不是一个职位，如果之前自身有一种好的架构能力，感觉之前的有很多的坑都可以避免，例如一些的需求重复进行修改，业务接口代码的功能混乱，造成的后面进行查错和优化的困难。同时，有时在应对用户及领导两方需求不一致时的无助及妥协，到最终进行重复的工作，浪费自己的时间及精力。日后这种情况时，就像孤尽老师所说，不仅要在第一时间响应领导的想法，告诉领导这件事要不要做，实现后造成的利弊，同时尽可能给出可替代的方案，同时，还得在用户提出需求时，了解该需求的用意，有没有实际意义等等，避免造成工作的无效性。但同时希望后面有机会的话，能讲一些关于在项目中如何定义及使用DO、VO、DTO对象。

听课总结：

1. 需求分析是理解和挖掘用户的诉求、以及背后的逻辑，转化成可行性的分析结果。即非结构化->结构化的转变。

2. 需求分析中需要注意三个点：

   边界：在某个点里的需求不能无穷无尽，必须有一个暂停点；

   用户故事：用户使用的情景。

   用户路径：用户如何去用。

P.S. PMF:产品/市场匹配，意味着在一个良好的市场中拥有能够满足该市场的产品。

    产品和市场之间“良好”匹配的3个关键标准：

1. 价值主张：我们的产品解决了客户的问题
2. 渠道：我们的产品可以经济高效地到达客户手中
3. 货币化：我们的客户很乐意为产品支付费用

3. 架构 = 决策 + 组成，组成= 模块结构+ 模块关系， 决策 = 约束 + 设计原则 + 演化方向；架构是一种能力，而不是一个职位。架构师最大的难点：识别和隔离变化点。

    目的：

        1.确定系统的边界（做or不做）。

        2.确定系统里各模块之间的依赖关系与模块的宏观输入/输出。

        3. 让后续的子模块或模块设计在一个既定的框架内和技术方向上继续演变。

        4. 明确非功能性需求，如安全性、可用性、可扩展性等。

4.七大设计原则：

     单一职责：高内聚、低耦合（突出了模块的名称重要性）

     里氏替换原则：子类一定能代替父类的出现的位置；

    接口隔离原则：接口的粒度尽可能小同一接口的方法强内聚于同一特征；

    组合复用原则：组合是一种松散的合作关系，组合产生的对象，方法暴露的少（最常见的实例就 是业务层中类之间的注入使用）；

    开闭原则：对扩展开放，对修改关闭；

    迪米特原则：互相了解的信息，尽可能的少（即只管输入和输出，不关心具体代码实现）；

    依赖倒置原则：细节依赖抽象，底层依赖于高层。

5. 架构图是一种水平面上的业务模块加上垂直面上的技术模块形成的 逻辑业务图。

6. 画架构图关键：

      1. 明确要画的架构图的类型（数据or业务）；

      2. 确定架构图中的关键要素（如产品、技术、服务等）

      3. 梳理关键要素之间的关联：包含、支撑、同级并列等。

      4. 输出关联关系清晰的架构图，特别是图例的正确使用。

7.架构图的好坏判断：布局、颜色、逻辑。

8.类的六大关系：

    泛化关系（继承关系）

    实现关系：实现接口

   聚合关系：业务上整体与部分可分开，是关联关系的特例

   组合关系：业务上整体与部分不可分开，是关联关系的特例

   依赖关系：只要在类中用到对方，就存在依赖关系

   关联关系：体现的是业务逻辑的关系，是依赖关系的特例，具有导航性和多重性。

9. 类图是显示模型的静态结果，特别是模块中存在的类、类的内部结构以及它们与其他类的关系等。

10.时序图是描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它需要注意以下问题：关注正常流程 、不关注逆流程、不关注异常流程、不关注分支判断。