說起來這是我真正開始工作的第一年，實習不算，從一個學生要轉變成為一個職場人，說實話，我的感覺不是那麼強烈，可能是我們團隊的氛圍比較好，我沒有感受到那麼多有的沒的，今年是非常重要的一年，我自己是這麼覺得的，從思維上要從學生的思維轉變成在公司裡如何解決問題的思維方式，當然了，2019 年，我認為對於我自己來說可能會是一個轉折點，至於為什麼這麼說，其實也是自己內心的一股強烈的感覺吧。

慢談 2018

2018 年對於我來說，分為上半場和下半場，上下半場對於我來說都有著不小的收穫，上半場的我關注點在於如何做好基礎設施，如何做框架，為公司的各位研發老哥提供最有力的支援；而下半場我的關注點在業務，理解業務為首要任務，以及如何以最合適的技術去實現功能。

全場概述

熱點追蹤

React 又爆新聞啦，今年可是看到不少的這樣的文章，今年 React 也是出了不少的新的功能。

1. 新的生命週期

   在 React 進入到 16.3 之後，新增了兩個生命週期，以及將原有生命週期中的 componentWillMount、componentWillReceiveProps、componentWillUpdate 的三個生命週期標記為 unsafe，這三個生命週期在 16 版本還能繼續使用，但是這三個生命週期將會在下一個大版本移除，值得注意的是你不能在一個元件裡同時使用新的和舊的生命週期，至於為什麼要這麼做，可以去看一下 React 新的架構模式。

2. 新的 Context

   React 中的 Context API 相信大家都瞭解，在之前，React 不建議使用 Context，這是一個實驗性的 API，但現在它又回來了，成為了一個非常棒的 API，至於為什麼我們需要這個 API，以及如何使用，可以看看以前的文章，比如這個。

3. lazy、Suspense、memo

   React.memo 主要是用於函式式元件，作為 PureComponent 的替代解決方案。而 React.lazy 則是配合 Suspense 進行程式碼分割。

4. Hooks

   在最近幾個月，關於 Hooks 的文章也挺多的，得到了很多的反饋，也有很多的開發者喜歡這個東西。它能夠讓你不需要使用類就能使用 React。那麼為什麼要引入 Hooks 呢？官方給出的答案是，Hooks 解決了 React 中各種看似不相關的問題，這些問題是我們在開發和維護數以萬計的元件時遇到的。

Babel 7 以及 Webpack 4 的釋出，最近又瞭解到 AMP，雖然沒有做移動端，但是還是瞭解了一波。

這一年的熱點一件一件的說其實還真不少，也就不贅述水文了，但是我們以什麼姿勢去了解這些東西，我覺得是比較重要的，從我個人來說，我將這些新的知識分成幾塊，用不同的標籤去對應這些知識，其實看起來就是一個象限，當然了，這也是我個人的看法，也不一定適合大家。

1. 領域相關並且我十分有興趣的，優先順序拔高，優先學習，寫 demo 鑽研一下
2. 領域相關但是沒什麼興趣的，當然還是要學，畢竟要恰飯
3. 領域不相關但是有興趣的，利用週末的空閒時間看看
4. 領域不相關並且沒有興趣的，可能我就不怎麼會關注了，可能讓我學我也沒興趣去搞

貫穿全場的學習

幹程式設計師這行，不管是興趣也好，被迫也罷，學習二字貫穿整個職業生涯，也就是說我們要定期的為自己的知識資產進行投資。

那麼今年我的學習目標是什麼呢？基礎、基礎、基礎，重要的事情說三遍，在繁榮的技術圈，基礎才是立身之本，近來，我更是覺得這種觀點是對的。

在真正的開發過程中，我相信很多人的體驗是按照當前專案已有的程式碼架構與模式，把自己的程式碼加進去就可以了，就如同蓋房子一樣，設計師把圖紙弄好，計量人員把哪一塊用多少料都搞得清清楚楚，剩下的需要做什麼呢？把磚什麼的堆上去就 ok 了是麼？當然了，也有可能在修的過程中遇到了一些難題，根據我們的思考、多年的經驗解決了這個問題，但是誰不想去當那個設計師呢？

所以我覺得，今年我的思考方向，就是從怎麼寫好功能，轉變為 如何運用我所學的知識去組織出受過培訓的人就能夠很容易編寫和維護的程式碼。

所以我的學習方向是什麼呢？今年的學習在這些方面，設計模式、基礎演算法以及資料結構，以及如何寫出易維護的程式碼。

React Fiber

除了上面說到的這些，在查閱各種資料的時候，對 Fiber 十分有興趣的我也學習了一波 Fiber，感謝司徒正美等大神對 Fiber 的剖析，結合他們的剖析以及對原始碼的研究也算是對其有所理解。

這是一些資料：

• React16.2的fiber架構
• React16.2的fiber架構(2)
• React16.2的fiber架構詳解(3)
• React Fiber架構

原始碼閱讀

說到這裡，不得不說，在閱讀原始碼的體驗上，我個人覺得在 React 上的體驗不如 Vue 的好，也可能是我不太習慣 React 的原始碼組織方式，讀起來有點難受。

對於 Vue 原始碼的學習，學到了不少的東西，包括資料驅動、響應式原理、元件化、編譯等等，Vue 原始碼的可讀性還是不錯的，大家閱讀的話可以結合思維導圖，以及斷點除錯來學習，個人覺得不錯。

當然了，關於 React 相關的閱讀都沒有關注在 React 本身，而是聚焦於 React 周邊的各類常用庫。

比如，redux 的學習，在其中你可以看到 redux 的中介軟體機制，如何建立 store 等等。配合 redux-thunk 食用更佳，你可以瞭解到，為什麼 thunk 支援非同步，這能夠幫助你更好的學習 redux。

以及結合 react-redux、react-router 等庫的原始碼你能夠學到高階元件、Context API 等等的學習，可以去看一波，還是有所收穫。

好了，下面就來說說上半場吧。

上半場

對於基礎設施來說，我覺得比較重要的幾個點，大家可以注意一下。

第一，就是要做一個非常有原則的人，尤其是在程式碼上，我個人覺得斤斤計較也不是個什麼壞事，做基礎設施一定要注意原則。

第二，要建立自己的知識庫，不僅僅是如何使用這個基礎框架的文件，更重要的是自己內部要有一套關於這個框架的知識庫，避免因為人員流失等原因造成知識丟失，後面維護這一塊的程式碼就相當困難。

第三，一定要有測試，這個東西，相當重要，能夠充分的保證我們的程式碼質量。

構建高效的開發流程

談到基礎設施搭建，我們就不得不說說構建開發流程了，我們要做到程式碼規範、持續整合、測試等等，我們一個一個來說。

1. 程式碼規範，說到程式碼規範我們能想到什麼？ESlint、stylelint、Prettier、commitlint 等等，關於程式碼規範的部分我會在下面談到。
2. 測試，好的測試能夠在我們後期對程式碼進行維護修改的時候，將傷害降到最低。這一塊我其實也沒有做到位，檢討一分鐘，我使用了 Jest 來進行測試，但是在測試方面，我們可用的東西其實非常多，比如說 Mocha、Jest、Jasmine、AVA 等等，當然了我們還擁有像 puppeteer、nightwatch 來做 e2e 的測試。
3. 持續整合，在版本管理方面使用了 lerna，這是一個非常強大的工具，它能夠幫助我們進行版本管理、changelog 生成的工作，當然在後面還有持續部署的問題，這個地方涉及到 docker、Jenkins 等等知識了，這裡就不展開了。
4. 文件，Docusaurus 是一個非常優秀的文件管理工具了，當然了，現在也出現了非常多優秀的文件工具了，工具不是關鍵，關鍵是你的知識的留存。

優雅的提交 commit

上面說到關於這個開發流程，那麼我們如何在提交時避免這些問題的發生呢？我們不能只在 CI 流程做 lint 等操作，這樣的話，我們的反饋鏈太長了，所以我們將著一系列操作放到了本地。

我們需要的基本操作是哪些呢？對 commit-msg 的校驗、lint、prettier 等等操作。

關於這一部分，我就不多 BB 了，下面有一些資料：

• 用 husky 和 lint-staged 構建超溜的程式碼檢查工作流
• 使用 ESlint、lint-staged 半自動提升專案程式碼質量
• git commit 提交規範 & 規範校驗

下半場

下半場更多的感悟其實不是純技術上的，雖然也有技術相關的東西，但是我覺得對於我來說這幾點非常重要。

工作中的思考

下半場在專案裡進行了幾個月的開發，在開發的過程中，我也有不少的心得體會，雖然不知對不對，分享給大家，共勉。

第一、交流，交流真的非常重要，我記得我組長看過的一本書 《非暴力溝通》，書非常好，推薦給大家，我們在溝通中少了不少爭執，溝通的效率就不一樣了。

第二、不要一路狂奔，停下來思考思考。我不知道大家有沒有和我一樣的感受，專案比較緊張的時候可能就全身心的投入到功能開發、bug 修復上去了，都沒有時間來想想自己的工作，進行復盤、評估，造成的結果是，等一段時間過去後，再回首已然一片狼藉，再想要把專案拉回正軌要耗費非常多的時間，所以我的想法是，就算再忙也要停下來想一想，避免給自己以後挖坑。

其實還有不少的想法，但是篇幅有限，我就列了兩個我覺得非常重要的點。

破窗戶

這是《程式設計師修煉之道–從小工到專家》中的一段，這是一本非常經典的書，推薦。

說的是，這個理論是認為一個環境中的不良現象如果被放任存在，那麼就會誘導人效仿，甚至變本加厲。在程式碼中，這一點尤為常見，當第一段不好的程式碼出現在你倉庫裡，就可能打開了潘多拉魔盒，這也就是為什麼我說做基礎設施的一定要謹慎，要較真，如果你的程式碼規範執行的很徹底，那麼相信誰也不會想去當提交第一段爛程式碼的人。

知識丟失

知識丟失對於一個專案來說非常的致命，會造成我們的專案失控。什麼情況下會造成知識丟失呢？

只是提交了程式碼，忘記了保留知識，包括註釋、文件等等，又或者是做這個模組的同學離職了，又或者是掉到其他崗位去了，一旦沒有把知識傳遞到位，造成的結果就是知識丟失，新接手的同學看不懂、不敢刪、不敢改，就像一個泥潭一樣，讓人越陷越深，最後變成讓人感到絕望的祖傳程式碼。

對於這個問題，我想優秀的程式碼規範、有跡可循的註釋與文件可能可以解決一部分，但是到底該如何解決這樣的問題，我也沒有找到什麼方案，不知道各位有什麼有效的方法。

厲害了我的 2019

好了，大概說完了 2018，就要說說這個厲害的 2019 了。

整理一下我自己的單子：

• linux 命令：只瞭解 ls、cd、lsof 等基本常用命令，其他命令還得現查現用，比如我討厭的 tar，我一定要征服它
• webAssembly：準備學習一波，但是優先順序可能不是那麼高
• Node：會用，會寫，但是不深入，用大神的話來說，你很不錯，仍需努力
• 演算法：好像在很多人眼裡，前端和演算法好像關係不大，但是在我的認知裡，演算法、資料結構等等就是一個程式設計師的內功，決定了你的武功能練到哪種層次，所以要紮實，明年重點
• GraphQL：今年的遺憾可能就是沒有用 GraphQL 去試試水，在我看來它非常合適某些專案
• TypeScript：明年準備上到專案，所以是個重點，優先順序極高
• Electron：聽過，玩過 Hello World，挺有興趣，明年可能會玩一玩的玩具

我想到的大概就這麼多，畢竟明年啥樣我現在也沒法預測，前端圈瞬息萬變，我就靜觀其變，打好基礎，迎接時代的衝擊吧！

立個 Flag

喜聞樂見的 flag 環節，當然了，這是在給明年的總結留打臉證據的。

• 讀 20 本書，並且以文字的形式輸出
• DIY 一個玩具，React 元件庫（多方參考，只為學習）
• 演算法和資料結構的 flag 一定要立，希望邊學習邊輸出
• 能有一個自己的公眾號，堅持輸出

其他的 flag 也就不立了，感覺說的有點雜，有點多，就當我跟大家嘮嘮嗑吧，祝大家新年快樂，新年新氣象，升職加薪，走上人生巔峰。

偷偷在下面立個小 flag，女朋友說我瘦到 140，她才和我結婚，這個 flag 悄悄的立，你們就當沒看見好了。