设计原则
SOLID原则：
-
S： 单一职责原则
- 每个模块或者类只负责完成一项功能；
-
O： 开闭原则
- 指的是一个软件实体应该保证“对扩展开放，对修改关闭”，也就是最低的代码侵入实现功能的扩展
-
L： 里式替换原则
- 子类不能违背父类的行为约定；（包括父类规定的输入，输出，异常，功能，甚至是注释中罗列的特殊说明）
-
I: 接口隔离原则
- 将 一些特殊的接口隔离出来，单独给部分调用者使用（比如某些接口只能给后台管理员使用）；或者将一个函数分成粒度更细的多个函数，让不同的调用者调用不同的函数
-
D： 依赖反转原则
- 控制反转：程序流程的控制由程序员交给框架来完成
- 依赖注入：不通过new（）的方式在类的内部创建依赖对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数的方式传递或者注入给类使用
- 调用者不依赖于被调用者
KISS原则：
- 尽量保持代码简单，用简单的代码解决复杂的问题，或者用复杂的代码解决复杂的问题。
YAGNI原则：
- 不要做不需要或者是暂时不需要的操作，比如提前引包就是一个很好的例子
DRY原则：
- 不要写重复得代码；
迪米特法则：
- 不要有依赖关系的对象就不要强行依赖，有依赖关系的就尽量暴露接口依赖
需求分析：分析需要实现的功能以及实现的途径
系统设计：聚焦架构层，针对模块设计，以及模块之间的交互；模块交互的方式有两种，同步调用，以及通过消息中间件异步调用（解耦效果更好），对于具有上下层关系的模块推荐使用同步调用，对于同层模块建议使用异步调用
1. 怎么做接口设计： 1. 满足单一职责实际原则，但是不要过于单一，过于单一可能会引发性能问题（多次调用），或者是分布式事务一致性问题。可以在单一职责的设计原则之上封装一层粗粒度的外部接口 2. 怎么做数据库设计：通过需求表来设计 3. 业务模型设计：MVC设计，可以采用传统的贫血型开发模式或者是充血型DDD开发模式。 1. 为什么要用MVC三层架构？ 1. 分层能起到代码复用的效果：持久层的一段代码可能会被多个service层来调用，而service层的代码也可能同时被多个controller层调用。 2. 分层能起到隔离变化的作用：分层是一种封装复用的设计思想，持久层提供的只是对于数据库访问操作的接口，是一种基于接口而非实现编程，service层并不关系持久层如何跟数据库交互，也不需要去知道交互的是哪个数据库，一旦持久层变化，我们只需要修改持久层的代码，而不会影响service的操作 3. 分层能起到隔离关注点的作用：控制层只关注和外界打交道，而service层只负责业务逻辑，持久层也只关心数据源的操作。这样分层之后职责分明，符合单一职责的设计原则，代码的内聚性更好 4. 分层能提高代码的可测试性： 5. 分层能应对系统的复杂性：应对一个复杂系统最好的办法就是做拆分，拆分有两种方式，一种你是垂直拆分，一种是水平拆分。水平拆分指的是基于业务做拆分，将业务模块化，各个模块相互独立，提供相应的接口进行调用；而垂直拆分就是基于流程拆分，也就是分层设计。面对整个系统流程分成多个层次，层次之间相互调用。
面向对象分析
面向对象设计：设计一个类，以及类与类之间的关系
如何提高代码的可测试性？
尽量少用静态函数，因为静态函数过度依赖类，而如果普通方法就需要手动创建对象，然后注入依赖，这样，在测试的时候方便mock这个对象。
代码重构
异常的处理
异常的处理有三种方式，try -catch直接吞下、原样抛出、封装后抛出
究竟怎么抛出要看具体的业务：
如果该异常外面不关系，可修复，那么可以直接吞下；
如果外面关心这个异常，而且上一层的代码业务和该业务功能类似，我们可以直接抛出。
如果是跨层抛出或者外面的业务功能和当前不符合，需要封装抛出；这样做是为了不暴露底层的实现细节
判空
如果一个方法是类中的私有方法，可以不对参数做判空处理，因为他只服务于一个内部函数，不会暴露给其他调用者，我们可在本类中就做好空值处理。如果是一个公共方法，那么需要做空值处理，防止异常的发生。
返回错误、空值、错误码、空对象
返回错误码不能直观体现发生的异常或者操作的结果。
返回空值会产生大量的空值处理，容易造成空指针异常。
返回错误也会造成代码繁琐。
个人认为空对象仍然需要外部判断。和null一样，这个返回对象，可能对后续操作没有意义。
所以要看具体场景，尽量统一风格，所有人统一使用一种风格。
