最近的需求是写一个轮播，其中包括一些细节要求，比如循环播放（播放到最后一张图后下一帧为第一张图）、支持预览（可见的轮播图为3个）、中间的轮播图异形（中间的图略大，包括其它一些样式不同于其它图）。
这次需求之前，我的观念里，业务侧的东西只有自己手写出来，那才有所进步，有所收益。所以接到需求我就开始设计算法，构思布局等一系列事情，只为纯手撸这次业务，以求自己的“进步”。
但是在我根据自己的设计，代码写了七七八八的时候，发现自己的方案并不能很好的达到预期的效果，我去请教了舒总（字节前辈），他给了我使用Swiper去实现的建议，还有一句话让我触动很大——“不要重复造轮子”，最终我用Swiper轻松实现了本次需求，经过这次我心中不免产生疑惑：事事躬行真的是实现业务需求的正确方式么？
最终我的答案：在造轮子的优点是显而易见的——深刻理解实现原理，提升编码水平，缺点也是明显的——需要学习成本，降低开发效率，所以这就需要我们进行取舍了，昨天听心圆哥上课说道关于源码阅读的观点，❤️⭕️的话大概是这样的 “看源码本身不是重要的，重要的是有看源码的能力，能够通过看源码解决问题” ，我觉着和是不是做业务要自己造轮子是同一个道理——我们所做的一切终究是服务于业务，通过造轮子，目的是提升自己攻坚克难的能力，在没有轮子的时候有能力去创造轮子。 所以今后，我会适当做出转变，通过使用现有的轮子加快自己的研发效率，对于一些普通的需求，不再刻意去学习如何实现，毕竟东西是学不完的，不再陷入啥都追求自己写的误区，把时间用在其他更有意义的地方。
