目录
KISS 原则（Keep it simpe and smile）
前言
在我们的日常开发中，可能很多时候都是接到需求就开始编码，有没有同学对产品提出的需求有过疑问，对需求是否有一个自己思考的过程，需求是否合理？需求的价值在哪？能产生多大的利益？包括在自己写代码的时候，有没有思考过系统的架构问题；架构是一种能力，并不是职位，我们每一个人都应该具备这种能力，本文借助跟孤尽老师学习的机会，跟大家简单介绍一下如何分析需求 和 什么是架构。
一、需求分析
需求是什么
需求，用户述求，我们需要用户的述求还原成用户故事，可以理解为 是谁，在什么场景，需要解决什么问题！
- 是谁？用户角色 -- 比如你去买票，那你就是这个谁，谁就是购票人这个角色
- 什么场景？事件发生场景 -- 比如买票时候支付就是一个场景
- 需要解决什么问题？要达到什么意图 -- 购票系统，客户的意图就是买到他想去目的地的票，这里面又可以细分，怎么选票，怎么支付等各种细节需求
为什么要分析需求
需求有需求的边界，客户什么都想要，我们要分析出哪些是应该做的，哪些是不用做的；你付出很多，做出来的功能最后却成了摆设；投入很多，缺只有很少的产出
伪需求：没有调研、没有目标、没有逻辑的需求
权力需求：老板或者是强势业务方的需求
怎么分析需求
理解和挖掘用户的诉求，用户的诉求是我们的出发点，要从客户的角度出发，很多时候，我们走着走着，由于这个客观因素（技术方案、人力成本），变成了KPI的需求，以完成为目的，没考虑客户的问题是否得到解决。
人性是提出需求的本源，分析用户想要达到的意图，是为了提高工作效率，还是为了了解市场等等。
问题分层
- （本源问题）用户问题：“我想支付”
- （经营视角）业务问题：支持一切可以支付的第三方支付工具
- （体系结构）产品问题：支付需要逆向流程、异常流程、对账模块等
- （架构代码）技术问题：高并发、可用性、实现第三方链路
怎么应对需求
- 用数据化结果确认需求的合理性
- 从正反两个角度考虑需求是否有需要改进的地方
- 从客户的角度出发，通过用户路径和触点推演需求的合理性
- 评估需求的价值和实现的成本
- 考虑需求的风险
- 考虑是否还有更好的方案
最后，将需求转化成产品，可以实现的功能
二、设计原则
单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。如果一个类程度的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化产生时，原有的设计就会遭受破坏。
里氏代换原则
父类出现的地方，都能用子类代替，但是子类出现的地方，父类不能代替子类。正是由于子类的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。
接口隔离原则
接口的粒度尽可能的小，同一接口的方法强内聚于同一特征。比如支付接口，里面可以有支付、支付退款，但是不能有审批，审批应该是另外的接口，可以放在管理。它和单一职责原则很像，两者的角度不同，单一职责原则是从自身的角度，接口隔离原则是从调用方的角度。
组合复用原则
- 继承是一种绑定关系，相当于父子关系
- 组合是一种松散的合作关系，相当于谈恋爱
- 组合产生的对象，方法暴露的少
- 继承产生的对象，继承路线上的方法全部会暴露出来（接口污染）
- 增加用户的选择的成本，容易误用
依赖倒置原则
- 低层模块依赖高层模块
- 抽象不应该依赖细节，细节应该依赖抽象
迪米特法则
互相了解的信息，尽可能的少，你只需要关系输入和输出，不关心代码具体的实现。也就是说，一个类包装好自己的 private 状态，不需要别的类知道的字段或行为就不要公开。类之间的耦合越弱，越有利于复用。
开闭原则
对扩展开放，对修改关闭。开发人员应该对程序中呈现出频繁变化的那部分做抽象处理，对于程序的改动通过增加代码进行，而不是修改现有代码
三、架构
架构是什么？
架构是一种能力，而不是一个职位
架构 = 组成 + 决策
组成 = 模块结构 + 模块关系
决策 = 约束 + 设计原则 + 演化方向
为什么要架构？
- 确定系统的边界，在技术层面上做与不做
- 确定系统里各个模块之间的依赖关系和宏观输入与输出
- 使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化
- 明确非功能性需求，非功能性需求指的是安全性、可用性、可扩展性等
如何做好架构
KISS 原则（Keep it simpe and smile）
架构的理念是大道至简：解决问题
- 如何让我们的系统有扩展性和可维护性
- 如何让我们系统能够恰到好处地解决问题
- 如何让我们的系统能稳定持久的运行
DRY原则（Don't Repeat yourself）
一切重复的代码都可以抽象
- 不一致性
- 代码冗余
- 易出BUG
总结
本文简单介绍了什么是需求、有哪些设计原则、什么是架构！什么人在什么场景做了什么事；七大设计原则；架构不是一个职位，是一种能力：组成 + 决策！
期望大家有所收获，与君共勉！
韶光易逝，劝君惜取少年时！
参考文档：
- 孤尽老师的ppt
- 什么是需求，怎么做需求分析 - 知乎
- 《大话设计模式》--程杰