再见2019，你好2020 鼠年的春节已经过去了，然而在这时候却赶上了“新型冠状病毒肺炎”，全国几乎进入到了静止模式。没事儿的时候，上下一片祥和，有事儿的时候，各种妖魔鬼怪在人间。这里我也是对自己刚过去的 2019 年做下总结，整装待发开始 2020 年。 1. 工作 # 去年的一整年里，感觉一直在忙，上半年在忙红包中心和极速版的福利中心，也是在使用过 vue 后，首次尝试 react+typescript，其实我在 Vue 中就已经使用了 typescript，但 Vue 对 ts 的支持不是很好，在 react 中才发挥了更大的威力。下半年主要是在做抢金达人活动，为了减少首页加载的时间，我也进一步尝试了 nodejs 在项目中的使用，使用同构直出渲染方案来实现这个项目。在项目实现的过程中，我加深了对 nodejs 的认知，不再把它单单作为一个小工具来实现，可以来实现更多的功能。我们也通过自动构建工具，将我们的项目部署到 stke 上，实现了完全自动化的构建和部署流程。有着项目上线的期限，还有在实践 nodejs 过程中的一步步踩坑，同时还要准备晋级答辩。导致那段时间特别忙，博客的时间线上也出现了 3 个月的空白期。到 9 月份了，才开始了重新写博客。同时，在下半年，我也提升了自己的分享欲望，在还没有轮到我进行分享的时候，我就已经想好了好几个主题进行选择，不过因为分享机制的原因，最终也仅仅有 2 次的分享。从 12 月中旬到春节前的这段时间，也是特别地忙，一个人要同时支撑好几个项目的上线，同时其他项目还有零星的小需求要支持。最多的时候，同时有 4 个需求在排队等着，直到回家前一天的晚上，才把所有的项目进行收尾。在去年的一整年里，总共写了 28 篇博客文章，差不多相当于每两周 1 篇的频率。在新的一年里，期望能有更多分享的主题，争取能达到 40 篇的目标。 2. 生活 # 我们在 10 月份去了趟动物园，当时本来以为那天会很冷，周末开始忽然气温回升，阳光明媚，去动物园看了不少的动物。其实，我也是第一次看到真实的大熊猫。几年没去动物园，动物园现在在现场也可以扫码购票了，不用再排上长长的队伍。孩子着实是害怕那些大型动物，例如一些非洲象/亚洲象，老虎等，虽然隔着铁栅栏和玻璃窗，他们也是偷偷地看两眼后，想着赶紧离开这个地方。当时我的新年愿望是：在新的一年里不要加班，不要996，不要任何形式上的加班。没想到春节就发生了“新冠肺炎”这件事儿，还这么严重。为那些奋斗在一线的医护人员致敬。在读书这方面，确实很惭愧，经典的四大名著，我也是在2018年才看完《三国演义》，在2019年看了《西游记》，还剩下2本，争取今年能看完一本。 3. 总结 # 在新的一年里，希望自己能够更进一步。技术上，在nodejs、react等发发力，对里面深层次的东西，做更进一步的了解；生活上也能开开心心地每一天。 nodejs的加密模块/Buffer模块等； reactjs的diff原理/虚拟dom等； leetcode上的题目能够达到250道题（目前已157道题）； 公众号的粉丝争取上1000； 编写一个简单的微信小程序； 其实很可惜地在2018年的年底没有写年终总结，今年怎么说也得给不上。年终总结不是任务，只是让自己总结去年的得失，能够在新的一年整装待发。

震惊！数据被删了，怎么办？ 微盟这个公司的名声相信比之前大了很多，然而这并不是什么好的名声，而是运维人员删除了数据库中的所有数据。删库跑路本来是我们程序员调侃的一个梗，但若真因为公司惹你生气，删库跑路了，你也是要承受牢狱之灾的。 1. 微盟被删库 # 资料显示，微盟成立于 2013 年 4 月，有员工超 3200 人，渠道代理商超 1600 家，注册商户超 300 万。是中小企业云端商业及营销解决方案提供商，同时也是腾讯社交网络服务平台中小企业精准营销服务提供商。我们先来回顾下时间线： 2020.2.23 日 18:56，员工远程登入服务器并实施破坏。 2020.2.23 日 19 时，系统监控报告故障并启动应急方案。 2020.2.24 日 微盟公司向警方报案。 2020.2.25 日 7 时，恢复部分生产环境和数据，并预计到凌晨 0 点能完成恢复，并向新用户恢复业务，但老用户预计还要到 2 月 28 日晚上才能恢复。 目前来看，老用户的数据恢复依然比较困难，就看微盟数据的备份情况了。不过就微盟而言，这一次也不会倒下的。同时，这已经不是第一次删库跑路的情况了。2018 年 9 月，顺丰工程师手误删除线上系统的一个库； 2018 年 6 月初，前任管理人员删光其公司云主机厂商的所有客户数据； 2017 年 3 月，因不满被公司辞退，使用定时脚本每日执行删除操作，造成今麦郎的终端管理系统瘫痪； 2017 年 2 月，荷兰的数据库管理在数据库复制过程中，意外地删除了一个目录，导致 300GB 的生产数据丢失，并无法恢复。 2. 员工对公司的不满 # 大部分删库的情况，都是员工不满公司对自己的态度，比如疯狂加班、辞退没有补偿、想加薪被拒绝等等。然而，对公司的不满，并不能成为你删库跑路报复公司的原因。若公司对你不公，你可以申请仲裁，或者去法院告它。虽说流程长点，但这才是你保障自身权益的合法手段。删库跑路时虽然很爽，但你也终究是逃脱不了法律的制裁。有的人觉得写个定时脚本，在自己离职后，脚本才删除数据，然后再删除自己。可是，只要你做了这件事儿，必然会留下痕迹的，不要想着能干干净净地跑路。还有就是无意操作导致的，比如在数据迁移过程中没有做好备份和回滚，导致中间出错后，无法恢复数据。这种就是属于操作不规范。 3. 如何防范被删库 # 很多删库的行为，其实是可以避免的。 3.1 对员工的关怀 # 大部分删除跑路都是因为员工对公司不满，这里也提倡公司能够对员工的身心更加关心一些，即使员工要离职了，也是能够感谢在公司的这段岁月没，而不是心里一直怨恨公司。我也是跳过两次槽，但都是好聚好散。无论是员工自己、还是公司，都建议能够互相体谅。毕竟公司的体量更大，也有很多的法务和hr是专门负责这些事情，员工对公司而言仅仅是个小小的职员，但公司却也是员工维持生计仅有的选择。 3.2 权限 # 有的小公司在人手不够时，或者有的公司为了省事儿，通常会让一人独揽大权，所有的操作均是一个人在操作。同一个人开发，同一个人上线，同一个人审批，这就是权限不分，这样就很危险了，只要一个人，就能完成任何的操作。所以，不同的人员要进行不同的权限管理，在进行上线和维护修改时，上线和审批权限进行分开管理。区分业务运维、系统运维、网络运维、DBA等多重角色，每个角色都只能接触自己所负责的那票业务服务器，以及相应可执行的权限。 3.3 备份 # 备份、备份、备份。一定要做好备份，无论是代码还是数据，都要及时地备份，是每天备份还是每小时备份，就看业务的体量了，如果数据更新快，备份的频率就快一些。同时，备份的手段也要多一些： 异地备份，同时这两地需要不同的人员权限进行管理； 本地备份，在发布到线上后，本地要预留一份； 多云备份，例如你的业务部署在A云上，可以同步到B云上备份； 多重备份，都要设置不同的权限，当线上数据被破坏后，都可以从其他备份的数据进行恢复。 4. 总结 # 其实写博客也是一样的，无论是在博客平台，还是自有博客，若你的账号被封，或者他的博客平台出现问题，都可能会造成你博客文章的丢失。不论他们平台做了什么措施，至少自己这里也是要备份的。

代码管理：请立即删除你不用的代码 我们码农工程师在项目长期的维护过程中，经常会遇到一些目前暂时用不到的代码，然后我们习惯会注释掉这些代码，或者干脆另起一个文件重新编写。在什么情况下会留存代码呢？ 业务需求发生变动，想着以后可能还会用上； 之前临时支撑的业务已结束，产品说后面还会有类似的活动； 通常我们留下的死代码规模有大有小，小的可能就是某个if-else分支，大的可能到支撑了一套完整的业务。现有的代码不整理，只会让代码越来越多，项目的规模越来越大。到最后，自己也不知道这些代码是否还用的到。注意：现在用不到的死代码，请果断地立即删除，而不是注释掉。为什么是直接删除呢？ 你现在用不到的代码，以后也用不到了； 版本管理，即使以后用到了，也可以通过版本管理找回之前的代码； 之前若是支撑临时业务的代码，也请果断地删除。产品通常会说下次圣诞和元旦时，还会用到的。但，相信我，后面的需求肯定用不上现在的代码了。其实这就类似“破窗户理论”，一扇破窗户，只要有那么一段时间不修理，就回渐渐给建筑的居民带来一种废弃感——一种任何人都不关心这座建筑的感觉。于是又一扇窗户破了。人们开始乱扔垃圾。出现了乱涂乱画，严重的结构损坏开始了。在一段时间后，废弃感就变成了现实。当我们留下的死代码越来越多，我们也就越不在乎这些代码，最后导致整体都无法维护了。

腾讯抢金达人中倒计时的实现与改进 我们通过之前的《前端中的事件循环 eventloop 机制》中也能知道，setTimeout和setInterval的计时器并不是准确的，因为有其他任务的执行，会推迟定时器的执行。这对一些相对比较严格计时器来说，倒计时的时间越长，误差就会越大。倒计时通常有 2 种，一种是固定差值的倒计时，例如我们抢金达人中每题的答题时间是 10s；还有一种是固定时间点的倒计时，比如凌晨 0 点开始抢购。但这两种实现的方式都差不多。我们以抢金达人中的固定差值倒计时为例，来用几种方法实现这个倒计时。这种固定差值的倒计时，无所谓从什么时间点开始，我只需要有 10 秒钟的时间即可。 1. 计数器 # 最开始，我们在倒计时的过程中，为了增加用户的紧张心理，加了一个小数位，最简单的倒计时就实现了，每 100ms 减去 0.1，当进度减为 0 时，则结束：this.timer = setInterval(() => { const progress = this.state.progress; const _progress = (progress * 10 - 1) / 10; this.setState({ progress: _progress }); if (_progress 0) { setTimeout(() => { countdown(); }, delay - diff); // 每次进行校准 } } setTimeout(() => { countdown(); }, delay); 2. requestAnimationFrame # 与 setTimeout 相比，requestAnimationFrame 最大的优势是由系统来决定回调函数的执行时机。具体一点讲，如果屏幕刷新率是 60Hz,那么回调函数就每 16.7ms 被执行一次，如果刷新率是 75Hz，那么这个时间间隔就变成了 1000/75=13.3ms，换句话说就是，requestAnimationFrame 的步伐跟着系统的刷新步伐走。它能保证回调函数在屏幕每一次的刷新间隔中只被执行一次，这样就不会引起丢帧现象，也不会导致动画出现卡顿的问题 3. 固定时间点的倒计时 # 以上两种方案都存在着一个问题，若当前标签页不可见时，或者在移动端被置于后台时，计时器均会被挂起或者变慢，导致重新回来后的计时器出错。比如当用户正在答题倒计时的过程中，当用户把 app 收到后台，倒计时就会停止，重新回到 app 后，倒计时接着之前的继续执行，这样是不对的。这里我就对之前使用的倒计时进行了改进，不再用计数器来计算当前剩余的时间，而是利用固定时间点的倒计时方式进行计算。每当要开始倒计时器之前，都先计算出结束时的时间戳是多少。然后每次渲染时就获取下当前时间戳与结束时间戳之间的差值。这样就即使是切换 tab，或者将 app 收到后台，都是没有影响的。但如果用户要修改它的本地时间，那就没办法了。我们也只是从精准度上进行考虑，同时后端也加上对时间的校验，即使修改了前端时间，后端也是校验不通过的。const CountDown = () => { const endTime = useMemo(() => Date.now() + 1000 * 10, []); // 持续10s的时间 const [leftTime, setLeftTime] = useState(0); useEffect(() => { const count = () => { let now = Date.now(); const diff = endTime - now; if (diff >= 0) { setLeftTime((diff / 1000).toFixed(2)); requestAnimationFrame(count); } else { setLeftTime(0); } }; count(); }, [endTime]); return {leftTime}; }; 可以点击链接查看简单的 demo。当然，这只是很简单的功能，我们可以再添加几个配置，再完善下这个倒计时组件： 倒计时持续的时间或者结束时间点； 展示的倒计时格式； 频率，是每 100ms，还是每 1000ms 执行一次； 倒计时改变时的回调函数； 倒计时结束时的回调函数； 这里我们定义组件接收的参数类型为：interface CountDownProps { total?: number; // 倒计时的时间，单位毫秒 endTime?: number; // 结束的时间点，与 total 二选一，且优先级更高，单位毫秒 format: string | ((progress: number) => string); // 要展示的时间格式，可以是字符串或者函数 diff?: number; // 频率，单位毫秒ms onStart?: () => void; // 开始时的回调 onStep?: (step: number) => void; // 每次更新时执行的回调 onEnd?: () => void; // 结束时的回调 } 一个完整的组件在在于组件的健壮性和扩展性，我们这里也对外提供几个参数，方便调用。 format 接收两种类型：如果是字符串，则直接按照字符串要求的进行格式化；若是函数，调用方可以自己处理时间戳，并返回即可； 提供了 3 个关键时间点的回调函数，让调用方可以进行一些额外的处理，例如想在倒计时结束时进行弹窗等； 我们的频率字段 diff，在设定的值小于 17ms 时，直接使用 requestAnimationFrame 来代替进行页面刷新； 完整的代码可以访问 GitHub 仓库：react-countdown。调用方式： 'wenzi ' + progress} diff={10} onStep={(step) => console.log(step)} onEnd={() => console.log('end')} /> 还有更多的 demo 可以链接查看：react-countdown 的样例。 4. 总结 # 倒计时在我们日常项目应用地非常广泛，这里也是总结了下倒计时的用法，并形成一个通用的组件，当然，其中还有很多的不足，依然还需要进一步的完善。

同构直出项目中如何实现多终端的接口请求 抢金达人活动采用的是同构直出渲染方案，同时，主要是在新闻客户端和微信里运行。每个终端请求接口的方式都不一样，如何保证这些终端均能正常的进行接口请求呢？还能让开发者在 PC 端开发调试的过程中，也比较方便呢。 1. 面临的挑战 # 我们的项目，主要会从以下几个终端发起接口请求：首先我们应该梳理每个终端请求接口的特点，然后才能有效的改进。在表格中，即使都是新闻客户端，Android 新闻客户端和 iOS 新闻客户端，请求接口的 jsapi 调用方式也不一样。 终端 数据请求方式 node 服务端 透传 cookie/ua 等信息 Android 客户端 jsapi-postData 方法 iOS 客户端 jsapi-post 方法 微信、手 Q 端 http 的 get 请求 手机浏览器 http 的 get 请求 PC 浏览器 方便调试 2. 改进方案 # 针对各个终端请求的不同特点，我这里也对请求接口的方式进行了封装。封装的原则是： 先根据 proces.browser 或者 typeof window 来判断当前是服务端还是客户端，若是服务端，则使用request 发起接口接口，并将传过来的 header 信息透传给接口；若是客户端，则通过 ua 来判断是在哪个终端中； 若在新闻客户端里或者极速版里，则再判断当前是 Android 系统还是 iOS 系统，分别调用对应的jsapi来发起请求； 若在微信、手 Q 端或者其他移动端浏览器，则使用前端的 fetch 或者XMLHttpRequest发起请求，跨域的话就使用 jsonp 的方式； 在 PC 浏览器上开发调试的时候，则使用前后端协作的方式；更多详细的内容可以查看【腾讯抢金达人项目中的前后端协作】 同时我还为接口的请求添加上了请求量、耗时、错误率等监控信息，当接口发生异常时，方便协调后端同学一起定位问题。 3. 总结 # 我在这里对数据请求的方式，进行了组件化的封装。对外提供统一而稳定的调用方式，业务层无需关心当前的请求从哪个终端发起。所有的逻辑判断全部在数据请求组件内部进行处理。