阅读 192

我的 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 与我的技术之路 征文活动正在进行中......

关注下面的标签,发现更多相似文章
评论