ConardLi 的 2019 — 尾聲和開始 | 思否年度徵文

時間 2019-12-31

標籤 conardli 尾聲開始年度徵文简体版

原文原文鏈接

2019年，是對我很是重要的一年，比想象中更累的一年，比想象中收穫更多的一年。這一年，真的發生了很是多的事，不管是生活仍是工做學習上，因爲是技術社區的年度徵文，我就從 寫做和積累、技術上的提高、工做上的轉換 這三個方向來總結一下這一年。javascript

寫做和積累

我來思否的時間並不長，發表的文章也不是不少，可是我真的很是喜歡這個社區，個人文章在這裏產生了很是多的閱讀量和點贊，這些數字可以知足個人虛榮心，可是一樣讓我在發表文章的時候變得坐臥不安。文章一旦發出來就會通過衆多目光的檢閱，因此雖然我發表文章的數量並很少，但每篇文章都是通過我反覆修改和優化的，因此一篇原創文章所要花費的時間是很是多的，因爲平時工做比較忙，天天只有有限的時間學習和總結，加上反覆的修改和優化，有時一篇文章要花上一個月的時間。html

這裏關於原創文章我發表一些個人見解，關於原創文章和知識總結是有很是大的區別的，前者是要爲他人提供必定價值，後者是本身作查閱使用。若是文章僅僅停留在知識總結的層面上，那大可沒必要發出來，放在本身的筆記裏就行了，因此一旦是發表在外面的原創文章我必定會保證每篇文章的質量，保證發出來都是對你們有必定價值的。不少同窗問過我，寫好一篇文章的祕訣是什麼，若是真的有祕訣，那就是在寫這篇文章的時候時刻要想着，寫出來的東西不只僅本身要很是明白，並且可以讓其餘閱讀的人也明白，而且爲他們帶來必定價值。前端

下面是我今年在社區發表的一些文章，雖然數量很少，但我儘可能保證每一篇都是精品：java

自檢

這篇文章原本是用於概括總結我本身的知識體系的，沒想到發出來受到不少人的關注，我更但願的仍是你們以個人這篇文章爲例，創建本身的知識體系，而後不斷去自檢和完善。node

一名【合格】前端工程師的自檢清單

工程化

今年下半年的工做主要在前端工程化上，因此我研究和輸出的重心也放到了這上面，這將會是一個很長的系列，將來我會盡量的將我在工程化上的底層研究和最近技術輸出給你們。python

React

關於React我作了不少源碼和原理上的分析，大多數都停留在16版本之前，React17立刻要發佈了，將來我還會繼續在時間切片、異步渲染等最新特性上輸出一些原理分析文章。react

JavaScript

市面上很是多關於JS基礎的文章，我不太喜歡簡單的知識點羅列，我更喜歡在實際的應用中將這些知識點體現出來，將來也是如此，這部分也會有更多的文章。webpack

送你43道JavaScript面試題源於我對開源項目 javascript-questions的翻譯，只發了一篇文章在思否上，很久沒更新了，後面會繼續跟進最近題目。nginx

網絡

一篇很是全面的對 ajax、fetch 原理和應用的分析文章。git

全面分析前端的網絡請求方式

Electron

用JS開發跨平臺桌面應用，從原理到實踐是從【運行原理】到【實際應用】對Electron進行一次系統性的總結，很是全面。

Webgl

看完這篇，你也能夠實現一個360度全景插件

跨端

從移動端適配的基礎概念出發，探究移動端適配各類問題的解決方案和實現原理。

關於移動端適配，你必需要知道的

數據結構和算法

數據結構和算法是我一直在持續練習的，我平時也會分享出一些題目或者一些類型的解題方法出來，不太重要的仍是要掌握解題的思想，因此我整理了開源項目 awesome-coding-js ，而且寫了前端應該如何準備數據結構和算法？這篇文章，但願你們經過這篇文章能系統性的掌握和聯繫數據結構和算法，而僅僅不侷限於某些題目。

新技術

我一直比較喜歡關注業界的最新技術動態以及走向，而且按期總結，今年年尾我開始把我關注的技術動態的東西分享出來，因而我總結成【技術圈】這個專欄，它是我對業界最新技術動態的跟進總結，不只限於前端，將來我會持續更新。

技術上的提高

2019年個人技術關鍵詞應該是 React、數據結構和算法、工程化，固然其餘的技術我也有涉獵，可是主要深挖的仍是這三個方向，

React

這一年關於React我作了不少原理上的分析，讀了 redux、mobx 以及一部分React 源碼。

說實話 React 源碼是我讀過的源碼裏最難讀的一個，我相信不少同窗都有這個想法，若是硬生生的讀很容易半途而廢。這裏我分享一下個人經驗:必定要帶着實際問題去讀源碼，我就是如此，在讀源碼的時候帶着平常開發中常常會遇到的問題：

setState 是同步的仍是異步的？
爲何有時連續屢次 setState 只有一次生效？
React 如何實現本身的事件機制？
爲什麼 React 事件要本身綁定 this ？
...

這樣你在讀源碼的時候就會不斷想去經過源碼找到這些問題的答案，而不是看完源碼再想發現了些什麼，當你從源碼中找到了你想要的答案，那麼說明你的努力是沒有白費的。

由於以前我在生產環境使用的 React 一直是 15.x，因此源碼解析大多數都停留在16版本之前，現在 React17 立刻要發佈了，React 又給咱們帶來了很是多的使人激動的新特性：可中斷渲染、指定加載順序、並行處理多狀態... 將來我還會針對這些新特性對 React 繼續探索。

數據結構和算法

18年立過一個flag，2019年要把從新把數據結構和算法練好，我一直認爲，數據結構和算法對於一個程序員是很是重要的，前端工程師也是同樣的。它能帶給你的不只僅是面試上的收益，更重要的是能夠拓寬你解決問題的思路。

固然你可能會講，有些大佬並無刻意練習數據結構和算法，可是他們同樣很厲害。不得不認可有些人先天就有優點，又或者他們能從其餘途徑領悟這些解決問題的思路，但這並不可否認數據結構和算法可以讓你得到這些思路，並且是屬於比較快捷的途徑。

2019年我作了差很少300道左右題目，輸出了題解60餘篇，困難：中等：簡單比例大概是1:3:3左右，所有都放在個人倉庫 awesome-coding-js 中。

雖然這個數量跟不少大佬比起來不算什麼，可是這些題目基本上覆蓋了常見算法（排序、遞歸、二分、搜索、回溯、動態規劃、貪心）和數據結構（數組、二叉樹、鏈表、棧和隊列、哈希、堆）的各個分類，因爲時間有限，我通常也只會挑這些分類的典型題目，而後針對某一類題目進行總結。我也針對這些題解又作了一個比較全面的系統性的解題指南前端該如何準備數據結構和算法？但願可以幫到你們。

剛開始作算法題目是很是耗時的，有時候一道題要花上幾個小時的時間，個人作題時間通常是晚上下班後睡覺前，作完就睡覺，因此作題時間和睡覺時間是成反比的，這也能激勵我快速的把題目解出來。

固然如今已經好不少了，通過長時間有規律的練習和總結，如今遇到典型的題目我都能很快的解答出來，遇到有點難度的基本上也能夠套用已有的思想慢慢的解出來，不會再有當初毫無頭緒的感受了，不得不說，這真的是一個很是奇妙的過程，強烈建議你們也體驗一下。

工程化

前端工程化就是以工程化方法和工具提升開發生產效率、下降維護難度、把控研發質量。我研究的方向仔細劃分其實還能夠劃分爲研發效率、研發質量、研發安全三個方向。

研發效率

提高研發效率應該是最多見的前端工程化方向了，整個研發流程的各個節點都是能夠進行統一規範和優化的。

從初始化的腳手架，到研發的代碼規範，到開發調試的工具，再到構建打包、自動化CICD，均可以作成一套統一的而且可適配不一樣業務場景的解決方案。這個工做仍是很是有意思而且有必定挑戰性的。

研發質量

研發質量也能夠放到工程化的範疇，研發質量也是能夠從多維度多場景來衡量的。和上面的研發效率相似，研發質量也能夠從研發的全流程，也就是初始化、開發、調試、構建、上線、性能監控、錯誤監控來體現出來。

市面上大部分的監控研發質量的工具都只是針對以上的某一個階段，個人目標是實現一套針對研發質量監控的全流程解決方案。

我以前寫過一篇前端代碼質量-圈複雜度原理和實踐，實際上這隻屬於以上的開發階段的代碼分析階段的一小部分，其中單單代碼分析階段就會有不少不少須要探索的事情。

好比下面的代碼文件耦合度分析:耦合指邏輯層面上有互相關聯和影響的代碼模塊，一般這個能夠經過分析文件的依賴，以及分析一個給定時間分片內，代碼的提交狀況判斷（耦合的模塊一般會在一塊兒提交），耦合是一種常見以及確定會出現的狀況，並不必定是壞事。可是須要可以展示出非必要耦合的能力，例如我在改文件A的時候一般也會修改和文件A看似毫無關聯的B文件，這兩個文件就可能存在須要解耦的必要。

以下圖，紅色部分表明系統內某個時間分片內常常協同修改的文件，即改了A就會改B，這些文件是存在耦合的。經過耦合的檢測和可視化，咱們能夠作到檢測單元測試以及文檔是否在和系統代碼自己同時演進；檢測代碼架構上有問題的部分和模塊間隱藏的設計上的依賴。

下面的協做效率分析，也屬於開發階段的質量監控:有時增長開發者的數量並不能顯著的增長開發效率，若是你的項目有可能成爲布魯克斯定律的受害者，那麼你會發現開發者總數與其產出之間的距離會增長。

布魯克斯法則：指投入更多的人來開發一個緊急的項目只會讓進度更慢。更多並不意味着更好，有些事最好是一我的來幹。

總之這也是一個很複雜而且頗有挑戰性的方向，須要研發全流程的大量數據監控和算法架構的支持。我也期待將來能夠把這個方向作的更好。

研發安全

大部分同窗可能對安全問題還停留在 xss、csrf 等常見問題上，其實安全問題多種多樣，有可能你不經意間一個操做就可能引發一個安全問題，好比你不當心把 source map 文件傳到了線上，吃瓜羣衆就能夠開心的在控制檯看你的源碼了...

固然，安全問題形成的影響不只僅是上面這麼簡單，可能你的日誌打點不當心在某些國家多收集了一些數據，就可能會引發該國家對你啓動國家安全調查（咳咳這裏就不明說了...）。回想以前 Facebook 的用戶信息泄露問題，直接給他帶來50億美圓的鉅額罰款...

這些都有多是你的幾行代碼就可能形成的影響，因此必定要重視代碼安全問題，否則有可能你在不經意間就把公司寫破產了～

大部分安全問題其實都是能夠人爲避免的，而咱們能作的就是從工程化的角度去發現和避免這些問題，這樣的工做對於有必定體量的公司仍是很是重要的。

開源

我玩github的時間並不久，以前只是去github下載項目，偶爾逛逛issues，今年纔開始把本身沉澱的一些東西開源出來。之後會有更多更實用更有意思的東西開源出來。

這一年收穫的star大概有2k左右，這個數字跟衆多上萬star的大佬們真的不能比，可是對我來說已經很知足了，是一個很好的開始。

個人道歉

這裏真的要跟關注和使用我開源項目的同窗說一聲抱歉，首先真的很感謝大家的關注，大家的關注也帶給我持續輸出的動力，可是下半年工做上我真的很是忙（具體緣由下面會闡述），花在博客和開源項目上的時間少了許多，以致於不少問題不能及時修復，下面是我某個項目下的 issues：

下面是個人 github commit 記錄，後半年的提交真的少了不少，這裏真的要跟你們說一聲抱歉。明年我會盡力想辦法更好的去平衡工做和學習時間，來修復這些問題。

項目列表

還有一點就是真的但願有感興趣的同窗來一塊兒來參與項目的共建，我以前也收到過不少同窗的pr，只要是有價值的我都會合並，一個好的開源項目還得須要社區的力量來不斷的完善和優化，下面是個人幾個開源項目：

tpanorama

tpanorama 是一個全景插件，它能夠把一張平面圖轉換爲可操做的全景效果，而且提供自定義標記、平面球面標記互轉功能，個人這篇文章看完這篇，你也能夠實現一個360度全景插件就是對這個全景插件的實現講解。

在功能上它還有許多須要完善的地方，上面我貼的 issues 就是這個項目的，感興趣的同窗能夠一塊兒共建來修復這些問題，或者添加新的功能。

https://github.com/ConardLi/t...

electron-react

electron-react，使用 electron + react + react-router + mobx + webpack 搭建的腳手架工程，集成了開發調試、程序保護、升級、打包構建等功能，另外還對窗口、通訊、菜單、系統、彈框、打印等經常使用功能提供了示例 demo。

https://github.com/ConardLi/e...

awesome-cli

這個項目是我開發的一些有趣實用的命令行工具集合，目前提供代碼掃描、代碼行數統計、代碼複雜度檢測等功能，後面我會繼續完善。

https://github.com/ConardLi/a...

awesome-coding-js

這是一個 markdown 項目，上面已經介紹過了個人算法題解都記錄在這上面，不得不說 github 上的 markdown 項目 star 都挺多的。

https://github.com/ConardLi/a...

工做上的轉換

今年我對於工做的關鍵詞應該是 轉換

由前端到全棧

最近又從新撿起了塵封已久了sql，也開始在nodejs上發力，而且還會寫一些go和python，本身cover整個研發全流程的感受很是好，不再用和後端撕逼了...

由業務到架構

今年上半年以及以前的工做，基本上都是和業務打交道的，按照排期完整需求。而後剩餘的時間就是關心線上監控、對已有的功能進行性能優化、以及爲了提高業務效率而造輪子。

今年的下半年，可能算是我工做的一個轉折點，我開始專一於前端基礎架構方面的工做，主要方向我上面已經提到了，研發效率、研發質量、研發安全。這些東西是我之前從沒有深刻研究過的，對我來說很是有挑戰性，我也很是感興趣。

上面我提到了我下半年很是的忙，這裏我就簡單說明一下，作業務和作架構真的不同。作業務相對來講是見到成效比較快的，而基礎架構不同，須要很長的時間去打磨和優化，短期很難見到成果，作完一件事情以後我會千方百計的去優化，讓它變的更好，並且還有很是多新的事情等着我去作。總之我一直會抱着一種沒有最好只有更好，沒有最完善只有更完善的心態去作，因此下半年我花在開源項目和總結輸出上的時間少了不少。

可是這對我來說並非一個壞事，輸出的時間變少意味着沉澱的時間會更多，經過大量長時間的積累和沉澱才能多輸出一些有價值的東西。也但願將來的我可以繼續沉澱下去，戒驕戒躁、厚積而薄發。