個人 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 與個人技術之路 徵文活動正在進行中......