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

正文

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

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

https://fish-pond-1253945200.cos.ap-guangzhou.myqcloud.com/img/others/package/1.png

我的回答

这是鱼头的回答:

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

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

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

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

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

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

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

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

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

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

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

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

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

不同意见

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

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

你的看法?

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

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

后记

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

加入前端鱼塘 扫描二维码回复 加群 学习