前端写代码真的有必要封装太好么?

• 作者：陈大鱼头
• github： KRISACHAN (opens new window)

正文

之前在知乎上看到这么一个问题：

前端写代码真的有必要封装太好么? (opens new window)

我的回答

这是鱼头的回答：

我就是那种会统一管理api的人，其实我比较喜欢将功能分类。

例如api放一个文件夹，store放一个文件夹，公共组件放一个文件夹，页面放一个文件夹。

但是封装还是必要的，只是过度封装比不封装后果还惨。

但是怎么封装的合适，这个跟个人功力以及项目情况有关，有的时候不一定能把握好边界。

例如你页面有两个样式差不多的button，而且你的项目只是短期或者跟别的项目相性较差的，就没有封装的必要。

但是如果是这个button可能在很多地方都用得上，这个时候就应该考虑封装。

但是无论是封装还是不封装，首先要明白的一点就是，代码是先给人看再给机器看的。

所以应当力求代码清晰，干净可维护。

过度封装就有可能导致代码看不懂。

其实在npm里，就有很多这种过度封装的毛病，一个Array.isArray都能独立成库，我个人是极其反感这种形式的。

但是对于一些公共的lib来说，例如lodash，他里面也不乏isFunc，isObj等的代码，其实也可以不封装，但是有大量判断的场合，这种if (isFunc)的代码就能让你一下子明白这下面的逻辑是干啥的。

所以封装不封装，封装得好不好也是见仁见智的。

当然从题主的问题来看，封装太好肯定是好的，但是这个“太好”确实一个比较感性的词，是自己觉得好，还是一部分人觉得，还是大部分人觉得好，这就见仁见智了。

不同意见

当然也看到有人给鱼头回复，其中有这样的内容：

『确实 npm 上有不少「一行成库」的模块，而且还很多人用，感觉挺讽刺的。抛开那些纯粹为了好玩，或者「智商税」型的模块，有些模块是因为历史原因留存至今。创立之初作为某个非标准特性的 polyfill，后来特性被标准化了，polyfilll 就变得没必要了。等到兼容性足够之后，作者干脆就把库的实现改成标准语法了。毕竟这些古早的库，新项目未必会再用，但老项目中可能还有依赖，所以也不好直接下掉。』

你的看法？

那么看到本文的各位读者，你们是怎么看待这个问题的呢？

欢迎在下面留言区域回复你的看法，一同交流意见。

后记

如果你喜欢探讨技术，或者对本文有任何的意见或建议，非常欢迎加鱼头微信好友一起探讨，当然，鱼头也非常希望能跟你一起聊生活，聊爱好，谈天说地。 鱼头的微信号是：krisChans95 也可以扫码关注公众号，订阅更多精彩内容。 公众号窗口回复『 前端资料 』，即可获取约 200M 前端面试资料，不要错过。