复杂的代码（Complex Code）

过多的代码行

模代码中的类、函数、属性等没有经过合理的组织，只是堆砌而成；随着代码规模的增长而逐渐变成bug温床。

举例：

- 过长的函数

- 过大的类

- 过长的参数列

太长的参数列难以理解，太多的参数会造成前后不一致、不容易使用，而且一旦你需要更多数据，就不得不修改它。如果将对象传递给函数，大多数修改都将没有必要。

- 数据泥团

不同功能的数据捆绑/封装在一起；一个修改也需要取出一个比较大的数据对象。

超长的类

重复/相似

包含复制相似的类，函数等。当被复制的或者重复的代码出现问题，或需要修改的时候，往往需要更改多处，而且容易出现遗漏。

相似的类，没有继承关系，只是拷贝复制

耦合/分散

系统中的类或函数随意相互引用；一个类引用另外一个类，但是在使用时需要了解被使用类的细节，否则就容易出现问题。如果一个变化，需要更改过多的类，那么说明代码太过分散，往往很难定位修改范围，或者造成遗漏。

超级类

引用超级类

最终导致杂乱与无序，难于维护

杂乱无序

重构/设计（Refactoring or designing code）

就是拨乱反正；就是为了解决混乱，低效等难题。

重构/设计后

方法

如何提升代码质量，首先要重视代码质量，提升对自我的要求，积极收集，总结分析。其次，讲求方法。每个成功与失败的解决方案，都会经历几个步骤：分析，设计，反馈/总结，打磨/迭代。反馈，一般是从测试或者生产环境中收集得来。打磨，说明是个不断优化的过程，也既迭代。再有，形成适合领域的解决方案。固化不变的（避免重复，规避风险），找到容易变化的，降低变化的影响面（依赖接口，相对灵活），设计/封装变化的。最后，传承。形成必要的知识库，用于分享与传承，利于整个团队的代码质量稳定提升。

设计，找到变化的，封装它们，隔离他们

什么在变化

目标对象结构会变化，规格在变化（数量，类型，外观），行为在变化（操作，流程）

结构变化：如何解决一个对象变化，不会影响关联的对象？如何解决不断新增加的对象问题？如何解决用户方便使用的问题？将对象的创建与使用分离

规格变化：如果创建不同规格的对象？将类或对象按某种布局组成更大的结构

行为变化：做什么，如何分离等等。对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责

封装

封装该解决方案的核心，或者说算法、结构的核心内容。

隔离

外部知道的越少，内部的变化对外界的影响才最小。或者将该解决方案不关心的非核心部分，隔离出去。

时机

需要考虑成本，收益等因素。

如代码规模较大，生命周期还很长，有比较大的团队在其上工作，则可以在开发过程中实时的，渐进的演化。

磨刀不误砍柴工

设计模式

一些铺垫

函数/方法

尽量短小，职责单一或在一个抽象层级，参数尽量不超过三个，不要有副作用（不要做隐藏的事情，有依赖时序或顺序依赖）

重复

重复是软件中问题的根源，很多原则都是为了消除重复

惯用法

惯用法更关注于特定编程语言的技术。考虑在特定技术或平台的上下文重新评估设计中应用原则的方式，这个过程中叫做惯用设计。比如C++，Pimpl，CRTP（The Curiously Recurring Template Pattern，如基类是一个模板类；派生类在继承该基类时，将派生类自身作为模板参数传递给基类），copy/move-swap。C语言中，struct模拟class，macro实现通用算法等。Java与C#的try with resource，foreach等等。

设计模式

软件开发人员在软件开发过程中面临的一般问题的解决方案。比较著名的23个设计模式。设计模式4元素：名称，问题，方案，效果。

架构模式

软件设计中的高层决策，用来构建软件体系结构的，比如层，C/S，主从，代理，事件/消息总线，P2P，管道和过滤器，黑板，解释器，MVC，表示-抽象-控制，微核，微服务，映像（Reflection）等，

一些原则

应当遵守的原则，也是各种设计模式的基础(即：设计模式为什么这样设计的依据)

不只是SOLID

单一职责，开闭原则，里式替换，接口隔离，依赖反转... 总之，这样原则可以让我们的代码：可重用；可扩展，有足够的灵活性，可以应对未来的变化；可靠性，能对外保持接口稳定；高内聚低耦合，能最小化修改的范围等

设计原则

GOF收录的模式

GOF模式分类

GOF模式形象比喻

GOF模式适用场景

其他模式

并发模式举例

future模式

是多线程开发中常见的模式，可以理解为对回调的一种线程安全的封装。当我们发起异步请求后，可以同步等待，也可以在需要时查询，待状态允许时，同步获取结果。

Future模式

map-reduce模式

核心思想就是分而治之，汇总统计。小到设计模式，大到计算框架，都是常见的一种并行运算解决方案。

map-reduce

actor模式

Actor是一个计算和状态独立的单元。Actors完全彼此隔离，它们永远不会共享内存。Actors 使用消息相互通信。当一个Actor 收到消息时，它可以更改其内部状态，并将消息发送到其他 (可能是新的) Actors。

Actor 类似于一个“黑盒”对象，封装了自己的状态和行为，使得其他 Actor 无法直接观察到它的状态，调用它的行为。多个 Actor 之间通过消息进行通信，这种消息类似于电子邮箱中的邮件。Actor 接收到消息之后，才会根据消息去执行计算操作。相互独立才能各行其是。

actor

游戏行业可能的模式

AOI

封装算法的核心，具体算法可以策略化（九宫格，十字链表，四叉树等），并且对可视单元的内部结构不敏感，可以用观察者模式。

工会，组队，家族

该类型结构有很多相似的代码，可以尝试使用结构模式来构建他们；还可以将申请，加入，退出，删除等抽象为接口，来适应不同的应用场景。

网络层

是否可以实现协议无关，tcp/udp无关，可选合批，压缩，加解密等等作为filter。

各种池

还有很多

源于总结，抽象，封装，打磨...

收集封装打磨

This document only shows some well-known patterns. Each domain has its own relatively mature models and solutions, which need to be collected and summarized by everyone..