代码的抽象三原则
2020-01-24#技术#编码规范
原文来自：
代码抽象有三个原则：
•
DRY 原则
•
YAGNI 原则
•
Rules of Three 原则
DRY 原则
DRY 我们都非常熟悉了，Don't Repeat Yourself 的缩写。意思就是不要重复写代码。
If you need it once, build it. If you need it twice, abstract it.
这个原则可能是所有工程师最早接触到的关于抽象的一个技巧。当你的代码重复的时候，那么你就需要考虑抽象成公共的组件、公共的方法、函数等。为的就是不让自己对同一个功能的实现写多遍代码。
YAGNI 原则
YAGNI 是 You aren't gonna need it 的缩写。意思是“你将不需要它”。
YAGNI 是极限编程的一个原则，说的是除非真的有必要，要不然不要添加额外的功能。因为你以为的功能其实你并不需要它。
极限编程的原则提倡尽可能快、尽可能简单的让代码运行起来（do the simplest things that could possibly work, DTSTTCPW）。不要把太多的精力放在抽象上，这样会浪费很多时间，无法实现让软件快速运行起来的目标。
但实际上 YAGNI 和 DRY 这二者存在矛盾。DRY 提倡的是抽象，提取通用的功能、模块。而 YAGNI 则提倡快速运行软件，不要添加额外的功能，不要进行过多的抽象。
所以在这两个规则下，还需要
Rules of Three
Rules of Three 叫做 三次法则。来自于《重构-改善既有代码设计》的重构原则。
当第一次做某件事时只管去做；第二次做类似的事情会产生反感，但无论如何还是可以去做；第三次再做类似的事情，你就应该重构。
这个原则很好的解决了 DRY 和 YAGNI 的冲突。当一个功能重复3次及以上时，才着手进行抽象。
之所以加入 Rules of Three 原则，是有下面几个好处：
1.
方便省事。如果一个功能只有在一两个地方用到，那么就没有必要进行抽象。不仅对于开发者来说省事，对于后面接手的人来说，理解代码也更加方便。毕竟经过抽象后的代码理解起来肯定不如抽象前直观
2.
容易发现共性。多一个东西重复多次后，要发现其共性的地方就更容易了
3.
防止过度冗余。同一个功能写多次代码，管理起来非常麻烦。当需要变更时，需要更改多次，非常不方便。所以实际工作中，代码重复最多允许出现一次，再多就需要抽象了。
所以一开始那句话就应该改成：
If you need something once, build it. If you need something twice, pay attention. If you need it a third time, abstract it.
最后
好的代码并不是一味的抽象，好的代码应该是在可读性、开发成本以及代码冗余之间寻找一个平衡点。
所以我们在对代码进行抽象前，可以参考下代码的抽象三原则。