陈惠超的博客Github

代码的抽象三原则

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.
最后
好的代码并不是一味的抽象,好的代码应该是在可读性、开发成本以及代码冗余之间寻找一个平衡点。
所以我们在对代码进行抽象前,可以参考下代码的抽象三原则。