个人 2018 年技术总结 | 掘金年度征文

写文章

2018 年断断续续的写了 10 篇文章，相比 2017 年进步仍是挺大的。一开始只在简书上更新，后来也在掘金上同步更新。果真技术性文章在掘金上的曝光率更高一点。

简书在 2018 年末搞了一个实名认证，原本也很正常，但简书不只要手机号认证同时还要微信认证，并美其名曰国家相关政策。我怎么也想不明白国家为何需经过微信来验证网民身份的。简书这强制填写手机号和微信号的说辞真把我恶心坏了，2019 年决定不在简书更新了。

#每日一记#防止按钮在短期内重复点击 - 掘金

#每日一记#开发微博的 Chrome 插件 快捷键问题 - 掘金

#每日一记#前端与后端交互 数据状态设计 最佳实践 - 掘金

#每日一记#经过 GIF 理解 addEventListener、捕获和冒泡 - 掘金

#每日一记#iOS Safari 没法经过禁止缩放的问题 - 掘金

#每日一记# 1分钟学会如何「便利地」使用 async/await - 掘金

#每日一记# 3分钟从 es6+ 编译成 es5 的代码里学习知识 - 掘金

2017 年开了一个「每日一记」栏目，就是想把一些小的、零碎的知识点拿出来分享一下，当作零食通常让读者在茶余饭后能读个轻松。有些知识点确实帮到了一些读者，真的让人开心。

2018 年底开了一个坑，打算用 Babel 把 ES6+ 的语法编译成 ES5，而后讨论一下如何 Babel 用 ES5 来实现 ES6+ 特性的实现细节，也算是查漏补学、融会贯通。不过刚写 let 时就遇到问题，在一个不经常使用的特性上出了问题，Babel 没有按照规范来编译，因此赶忙提了一个 issue 过去。但出师未捷身先死，这个 bug 不修复第一篇文章就写不下去了（笑。

现在 Babel 已经修复了这个问题，这个断点也要从新开启了。

2019 年「每日一记」的栏目还会继续下去（但并不日更（笑。

#算法 第4版# 2.1.14 扑克牌出列排序 答案 - 掘金

不知道哪里看到一句话「程序员不必定要学算法，但不会算法就难以成为优秀的程序员」，即便像我不会算法我也能理解这句话的意思，要告诉咱们算法不只仅是一种技术实现更是一种编码的思考方式。

但算法对非科班出身的我来讲，一来门槛仍是高了点，二来没有实际的应用场景，单纯学习实为枯燥。2018 年仅以算法写了一篇文章，18年半途而废19年再战。

#Webkit 翻译# Web 检查器中的图层可视化工具 - 掘金

偶尔会翻译一些我认为不错的文章，一来提高单词量二来也能够分享给读者。

2019 年的 JavaScript 新特性学习指南 - 掘金

2018 年都一直稀里糊涂的使用 Babel 编写代码，尤为是 Babel 发布第七个版本后对于 presets 更是没能理解。结果到了年末忽然对 ES 对 Babel 有一种顿悟的感受，冥冥之中不少点慢慢连成了线，就赶忙落以文字。这样白纸黑字就有了上面着一篇万字文章。

对于我来讲有一种爬上一座山崖，乌云拨开闪耀的阳光把眼前开阔的连绵草原映照出昂昂生机的感受，新的一年对于 JS 的学习一定是崭新的开始。

微博助手

微博助手是一款 PC 端 Chrome 插件，帮助用户在浏览微博时简化操做流程、完成批量操做。目前包含了快速归档资源、完成微博账号一键切换等功能。

2016 年 3 月在 Chrome Store 上线了这个插件，2017 年断断续续的维护到如今，2018 年一共发布了 1 个大版本 5 个小版本。

到年初，微博助手终于突破 400 的用户量，用户每周经过插件进行上万次的图片和视频下载，上百次的账号切换操做。

一直以来给本身的目标就是成为真正的独立开发者，或者说是一我的经过编程开发换得的报酬能给本身提供温馨的生活。虽然弱小如我，但 2018 年的数据也让我以为是一个不错的成绩。

2018 年开发插件的过程当中，也不仅是闷头写代码，更多的时候是一种思考。产品方面就会想如何让用户得到更好的使用体验。开发方面就要想怎么组织代码、怎么设计研发流程。

因为微博助手是在现有 Weibo 页面中进行扩展的插件，因此不突兀就是首要的设计重点。在用户须要的时候出现，不须要的时候直接隐藏或者缩小。

虽然张鑫旭吐槽过我这个插件就是简单的 DOM 操做。可是有时候这种简单直接的逻辑就是能解决用户的痛点。相比 Weibo 提供的交互流程，插件自己的做用就是加强细节的体验。站在开发者的角度上，技术可能毫无难度，但站在用户的角度上来讲，就是极为便利的功能。

2018 年在插件开发的过程当中，也在思考如何规范化整个产品设计研发的流程。

过程当中走了很多弯路，尤为是一我的要作产品、设计、开发、测试、运维的时候，怎样创建标准和流程让本身在低频次、长间隔的开发方式中减小错误的产生。

若是流程过于随意就十分容易出问题。在「账号关系」功能开发的过程当中，由于以为功能比较简单就跳过了产品原型和设计的流程，直接进行开发。功能开发完成后发现体验一点都很差，可用性不好。什么是可用性？就是会让用户在使用过程当中目标明确不会产生迷茫。

我以为可用性是开发者特别容易忽略的一点。由于开发者很了解本身开发出来的产品的底层逻辑，因此开发者本身在体验产品时有更大的宽容度。好比按钮点击时页面没有反应，开发就能大概知道是网络延迟或是操做有误或是后端数据问题，而用户对底层的逻辑彻底不了解就会认为产品很难使用。

因此我又从新开始，从产品原型设计功能，设计 UI 界面，从新开发后，用户体验就行了一大截。

开发方面就是要把测试用例和发布流程都写下来。由于功能点愈来愈多，每周只开发几个小时，每次发布都能隔着几个月，不作好记录就很容易遗忘。在 2018 年中的两次功能重构后，就由于凭着记忆测试而产生了 bug，用户提交了反馈后才发现的。

因此这方面使用的 Teambition 来记录开发过程当中的各类东西。本身当本身的测试、运维。

看似是一个很简单的插件，但难的是整理出一套可复用的工做流程，这也是我努力研究的对象。之后不管是再有项目 A 仍是项目 B，都能快速复用。

2018 年插件经历了用户的天然增加，2019 年就要尝试运营领域，尝试推广本身的产品也是一番有趣的尝试。

头发

2018 年感受头发不停的掉，难道变强的代价就是颜值的下跌么。可不能秃噜了了呀！

2019 年祝各位程序员都能有一头茂盛的头发。

罗小黑写写文字

若是喜欢文章 请留下一个赞~

若是喜欢文章 分享给更多人~

在掘金中关注我

自由转载-非商用-非衍生-保持署名（创意共享3.0许可证） 转载时请保留原文连接 以保证可及时获取对文章的订正和修改

掘金年度征文 | 2018 与个人技术之路 征文活动正在进行中......