这个问题已经是老生常谈了，比较官方的说法是看时间和人力综合成本，如果能造轮子，那自然是造轮子，如果没那么多可观资源成本的话，那还是用框架。
这个问题我应该是2019年1月4号再次思考的。目前方案的最初是X让我们做一套拖拽可配置的大屏适配解决方案，给了一个原型和设计稿。我刚加入团队，很多东西也没那么熟悉，最后分配任务的时候，给我的是实时监控和计划排行榜。粗略一看好像很简单，与开始我也是这么想的。两类图，那就一个用D3原生画SVG，另一个用echarts直接套用，应该就可以。这个图也确实搞出来了，大体还算可以，大概一共花了4天时间吧。排行榜其实就是一排矩形框，实时监控就是 bar和line的混合图。
Bar-line mix chart：觉得echart那个观感不太好，就自己找代码实现的。柱状图 --- 平滑折线图 --- 颜色渐变。数据变化之后平滑过渡。这一些个效果实现之后，觉得好像可以给人看了，然而！！需求稿上还有一个需求 --- 超出部分拖动显示。漏看了一交互，哇，真的是。。设计是参照echart说下面加个滑块，直接用滑块控制。我就找了类似的图，套用了一下，感觉有点难，就那时候实现的效果很差，很难达到预期。这个探索过程花了一天。下午还是决定用echarts吧，还是推翻了之前的代码，重新用echarts实现。之间花了2天吧，代码集成和功能实现，只能说E
charts在实现基本图表还是比较不错的，前提是功能他有，马马虎虎将就能用吧。
Rect chart：对排行榜是不太满意的，觉得可以加入首屏动效，于是就去找了之前faast做的地球图，还真有可以实现的---- 从右边滑入，直接抄了代码，假装实现了，就暂时搁置了。看了下需求，排行榜还有一个轮播动效，哇，怎么又漏一个点。。用定时器循环滚动滑块，手动把第一个挪到最后一个的位置，循环播放。由于用的d3动画，会有一个变化的过程，第一个消失的动画太生硬，上移 -- 下降，产品觉得太生硬，就加了缓动延时，明显平滑多了。但引出了一些bug：1. 首屏载入会跑偏 2 会出现偏离制定区域的情况。
跑偏是因为首屏进入的时候被鼠标等阻隔，到时动画没完成，采取了最简单粗暴的办法 --- 滑动动效改成渐显。偏移位置不变，这样就不会发生水平方向的偏移。
跑出限定区域这个问题看了很久，都没找到问题所在。监测了 y偏移量和 差值 计算的结果，只能说我看的时候一直没问题，没看一直有问题，神奇的不行。有几次出问题的时候，发现y的值不是矩形的整数倍，觉得可能在计算后值的时候，y其实已经发生了一些偏移，所以在计算的时候，位置计算就不准确，时间累积之后，位置就发生比较大的偏移。于是就对偏移进行整除计算，限定偏移只能是矩形高度的整数倍，这样一定程度上保证了位置的正确。
这次的感悟是觉得造轮子和用框架本身就不是一个对立面，没有完全绝对的说法。在时间充裕的情况下，造轮子还是一个提升自己认知的过程，这样才有可能提升自己能力。用框架谁都会用啊，那程序员之间的差异就只是对API的熟练度么，并不是这样吧。个人认为程序员的价值在于用双手成就自己的梦想，而不仅仅停留在表面。当然，做东西之前对需求的理解一定要到位，在这次需求中，没完全理解产品需求，一开始就没考虑构思好整个东西怎么搞，导致后面有返工的情况，以后得引以为戒，极其影响工作效率。老胡他们直接套用框架，直接用现成组件，开发完了就可以优化其他方面。怎么说呢，一切以完成需求为前提，后续可以不断更新迭代优化吧，工作就是工作，寓乐于工作，自然是最好的，完成任务优先，毕竟代码本身就是为了提升工作效率，提升用户体验，其他的都是空谈，先有面包才有梦想。
网友评论