跟着感觉走 threejs 第一篇

引言

在实际开发的过程中，你是否经常遇到这样一种情形。需要用到一个组件，这个组件你抑或者其他小伙伴之前已经实现了，你内心窃喜，又可以使出拿来主义大法了。打开一看，发现之前的组件代码其中包含了很多强耦合的代码逻辑，导致不能够完全为你所用，不香不臭，弃之可惜食之无味。

这个时候，聪明的你，很快的想到了使出必杀技copy大法。但过来人的我相信，你内心深处是处于极度抗拒的，一方面又想赶快实现业务功能开发，另一方面又在质疑自己，为啥不能认真写出一个完美兼容所有场景的组件。你一边质疑自己，一边嘴上说着真香，画面最终定格在了control+v…

这篇文章，会从一个很简单的场景进行发散，逐渐延伸出如何写出高复用、低耦合的代码。同时这也是面试过程中，面试官喜欢提及的高频词汇，莫非其中暗藏玄机？

背景

最近在开发一个我司的后台功能需求，用的技术栈就是react+antd。在开发的过程中，涉及到一个select选择器，其中的选项是通过接口返回的，并且是要具备分页逻辑的。可以想象，这是一个很常见的业务场景。

最初的想法

由于该业务场景不是第一次出现了，所以别的功能中，肯定有类似的业务逻辑。最简单的做法就是直接把别的功能中的该部分代码粘贴过来，修修补补即可，这样还可以快点回家陪孩子玩～

就在我按下复制按钮的那一刹那，我在想，难道这就是我最终的归途吗？下次遇到同样的功能模块，依然这样做？这样一想，我不禁打了个冷颤。如果这样下去，那和咸鱼又有什么区别呢？你说你工作了多年，莫非只会copy大法…

这个时候，可能有不少同学已经在心里暗暗喷我了。因为本身就是个简单的功能，antd又这么好用，已经为我们封装了select组件，直接拿过来，再加上点自己的业务逻辑不就行了？还能玩出什么花样来？

带着上面提到的一堆疑惑，我们一一来看。在这之前，我们先大致画出组件大概的模样

从该图中我们可以得出以下几点重要信息

• 可支持搜索，也就是根据你的搜索关键字，需要去调用后端接口，获取返回值进行回显
• 每一个option中，除了文案外，颜色的小方块是该选项的头像
• 需要支持自定义placeholder
• 可能在某些场景下需要支持多选
• …

理解

如果我们从事编程工作，那么一定听过我在前面提到的低耦合、高复用的概念。

对于它们，我是这样理解的：

将我们的常用业务模块，封装成一个组件，其中做了很多思考与实现࿰