一年一次的国庆假期就结束啦，好想在给祖国再过个农历生日哇，但事实却是我已经在搬砖了。哪就国庆发生的一次线上事故和最近编码的体验说点啥吧
归一化
不知道是哪次浏览博客，总感觉自己见过这个词，就最近编码糟糕的体验而言，于是我就想起了这个词语，不知道合适不合适了。
背景：在旧项目中，引用了上古时期的一个日历UI库，我本来就很嫌弃这个日历选择器，又丑操作还不够人性化，你说这就算了，你竟然有bug，而且貌似已经不被维护了。本想借这次机会直接替换掉，可是呢？事情没我想的那么简单。
项目技术是Vue，讲道理Vue是提倡一个组件化声明式的开发方式，但这个UI库，是采用的命令式的使用方式，因此满满的都是jQuery的味道，其实这也啥大的问题，你可以通过组件封装一层，这样大家直接使用这个组件即可，但遗憾的事，估计是前人觉悟还不够，并没有这么做，这样做有一个明显的坏处就是，在每个需要用到时间选择的时候，就会有大量的不美观的重复度极高的坏代码，同时还带来一个我重点要说的问题就是，不利于我替换掉这个日历UI库。因为我简单搜索了一下，实在实在是太多了，如果我替换掉的话，意味着我需要改太多的地方，显然这很让人头疼。
后话：应了破窗理论那句话，我直接通过修改源码解决了这个问题，但是我并不满意。
我觉得这种情况下，通过封装一个专门的日历组件是最棒的选择，大家都直接import组件使用即可，无论是代码的美观，后期的可维护和升级都有大的飞跃，同时也符合目前背景下声明式编程的思想。
目前前端的发展，不再是大而全，而是小而精，我们的项目中可能需要用到大大小小需要的第三方优秀的库
再来继续谈谈归一，就目前前端的发展，今天你觉得很好用库，很可能不久就被替代，比如现在用的最广泛的ajax库axios。我们是否应该直接在业务组件直接引入axios并使用呢。我觉得不是的， 这里我们可以对axios进一步封装成一个ajax函数，针对项目实际情况对外提供通用的功能，这样就做到了对axios的单一，后期替换axios，我们就需要修改一处地方了。
CDN容错
再来说说CDN容错，其实也就是静态资源加载出错的问题，还在回家路上的我，得知线上服务奔溃了，debug后发现是因为bootcdn服务奔溃了，这里就说明容错的重要性了，我们需要对项目提供容错能力，可以表现为服务降级，也远比服务不可用来的重要。比如这次这种情况，我们可以监听onerror事件，同时将资源切换到本地资源或其他cdn地址。
异常监控
除了进行容错之外，异常监控也十分重要。
我相信随着用户的进一步增多，错误监控就来的十分重要了，我们需要做到比用户先一步知道系统异常了，并在造成更大损失之前，及时的进行修复，同时监听错误可以进一步完善系统。
我们可以在系统发生异常时，将错误信息发送到异常监控平台，监控平台可以对异常进行等级划分，对于严重的问题，可以直接发送邮件或短信给相关人也是必要的。