前言
在兩年前我寫了這篇一個資淺工程師年末的自我省視，內文主要是檢視自己那年學到的東西以及抒發心得感想，並提出一些對於自己職涯發展上的疑問。
標題之所以是打「資淺」工程師，是因為那時覺得連資深的邊都沾不上，所以用了資淺這個字來形容自己。
兩年過去了，職稱從工程師變成資深工程師，甚至還再往上變成了 Front-end Team Lead。雖然職稱本來就不代表一切，但我認為它至少「代表著什麼」，你到了那個位子就必須負起責任，如果覺得自己能力未及，就必須盡力去追趕，直到自己能擔起那個責任為止。
這篇會先回顧我這兩年來的發展，最後再分享一些自己的心得感想。
在這之前一樣先預祝各位讀者新年快樂！
技術的深度
兩年前我在文中提到自己是一個有廣度沒深度的人，希望自己之後能走得更深一點，把基礎打的更紮實。而這兩年之間的確有朝這個方向邁進，開始發一些比較有深度的技術文章，這些文章的靈感常常來自於工作。
像是在工作時被資安部門警告有 CSRF 漏洞，於是花了點時間研究，並寫下了讓我們來談談 CSRF，也在差不多的時間點發現令我十分不解的 Cookie 問題，誤打誤撞解開後深入研究，理解問題以後寫了我遇過的最難的 Cookie 問題。不同的工作內容也會碰到不同的問題，例如說在做 PWA 時碰到的原來 CORS 沒有我想像中的簡單以及完成 PWA 後的PWA 實戰經驗分享。
除了工作上得到的靈感，自己深深覺得對 JavaScript 的基礎掌握不足，那些常見的面試題我從來沒有搞懂過為什麼。儘管這些在工作上不一定用得到，但如果我想成為資深工程師，我認為那是逃不掉的，是一定要理解的東西。
針對這個部分，我寫的第一篇文章是該來理解 JavaScript 的原型鍊了並且得到滿多好評，再來寫了深入探討 JavaScript 中的參數傳遞：call by value 還是 reference？，把自己對這個議題的意見做了個整理，然後是近期的我知道你懂 hoisting，可是你了解到多深？與所有的函式都是閉包：談 JS 中的作用域與 Closure，把知名的 hoisting 與 closure 都深入研究了一遍。這樣看下來，大概再把 this 寫完（我也有這個計畫要寫）就能把 JavaScript 那些比較常見的基礎給搞定了，再來可能就是型別轉換的一些問題。
除了 JavaScript 以外，也寫了幾篇文章是關於網路跟瀏覽器的，像是給新手看的輕鬆理解 Ajax 與跨來源請求、我以前一直被搞混最後終於弄懂的循序漸進理解 HTTP Cache 機制以及DOM 的事件傳遞機制：捕獲與冒泡，或偶爾研究一下比較新的東西像統一網頁支付介面：Payment Request API。
從 2015 年開始，我的前端開發生涯就一直圍繞著 React 打轉，所以有時候也會寫一些相關的主題像是React 性能優化大挑戰：一次理解 Immutable data 跟 shouldComponentUpdate與淺談 React Fiber 及其對 lifecycles 造成的影響，或是為了要用 redux-observable 而去學 RxJS 最後寫下的希望是最淺顯易懂的 RxJS 教學。
兩年之間寫了二十幾篇文章，要特別感謝 TechBridge 的夥伴們提出一起經營共筆部落格這個 idea，強迫自己一個月一定要寫出一篇文章來。
即使寫了這麼多，我知道還是有很多主題沒有涵蓋到，就算是寫過的主題也不一定已經完全理解，我覺得這是寫作的人要很小心的一個部分（或也可以說是我對自己的提醒），否則一不小心就會變得自大了起來，卻沒意識到這個世界比你想像中大的多。
像是我前幾天看到這篇文章：騰訊前端面試篇（一）分享自己去騰訊面試的心得，裡面問到的有些題目其實我就不會，所以要學的還多著呢。
除了不能自大以外，也要小心不能妄自菲薄，但這超級難，有時候這個點很難抓，要慢慢去找到那個界線。我不會說自己對某個主題理解到百分之百，但也不會說自己完全不理解，畢竟寫了這麼多主題，對寫過的東西還是有一定程度的理解，這點自信還是要有的。
話說還有一個要小心的陷阱，那就是其實很多人都會這些技術，只是沒有 po 文沒有分享而已。我以前曾經認為有些東西找不太到文章是不是沒什麼人會，不是，他們只是沒有分享出來而已，還是有很多人會的。
技術的廣度
兩年前我覺得自己廣度比深度多很多，因此我寫了一大堆文章針對不同的主題深入研究，讓自己對技術的理解變得更深。
那廣度呢？有了深度以後，我對廣度便不是這麼在乎了。我在第一份工作時還沒決定好自己想往哪裡走，因此我用 node.js 寫後端，用 react+redux 寫前端，還用 Java 寫了 Android 的 App。
可是在那之後我變成了專職的前端工程師，因此對後端技術便不是那麼關注，有哪些新的潮流我都不知道，更不用說 mobile 了。還是會維持一些基本的敏感度，例如說知道新出的 Flutter 之類的，但也僅僅知道這個關鍵字而已。
這其實也是我想走的方向，我覺得先廣再深其實是很不錯的一件事，你得先廣才能去找到自己想走的方向，並且也在這段時期累積一些對其他領域的基本理解，接著才走深，去深入理解你選的那個領域。
以我來說，我在廣度時期讓自己理解後端、Mobile 開發或是一點架構層面的東西，這些都對我之後的職涯很有幫助，至少我有基本的概念，不會什麼都不懂。
而現在進入到深度時期，把心力放在 JavaScript、瀏覽器、網路跟 React，其他的便不是那麼關注。
但如果要我挑幾個在這以外想研究一下的主題，我會選 GraphQL 跟 Vue，希望能對這兩個東西有基本的理解。
融會貫通
到了某個時期，會開始能把以前學過的東西融會貫通並且確切的知道其脈絡發展，而我在這兩年間似乎就到了這個時期。
其實以前就有這種能力了，只是在近期變得更明顯而已。掌握了脈絡以後就能夠很清楚地去解釋一項技術的出現以及為什麼要選用這個技術，能夠知道背後的核心思想，經過這樣的思考以後寫出來的東西是不一樣的。
除了技術深度的發展以外，我也會寫一些面向一般大眾的科普文，像是零基礎的小明要如何成為前端工程師？以及跟著小明一起搞懂技術名詞：MVC、SPA 與 SSR，就是自己整理消化以後再產生出來的東西。
我自己認為之所以這些文章底下一片好評，就是因為它有脈絡。技術的發展是有脈絡的，React 會出現一定是為了要解決一些 jQuery 沒辦法解決、Angular 也沒辦法解決的問題，否則我們不需要一個新的技術，而這新技術也不會變得那麼受歡迎。
只要能夠找到那個理由，就能把這些點串起來連成一條線，連多了就變成一個面，成為完整的知識圖譜。
在上面那兩篇文章中我從最陽春的狀態開始一步步往下推，其實就好像數學證明或是邏輯證明那樣，每一步都跟上一步有關，在證明的過程中會變得越來越複雜，但每個步驟都是環環相扣的。
叫一個新手直接去碰 React，就好像直接讓他從證明的第十步開始往下做，他不知道怎麼到這裡來的，也需要花很多時間去研究該怎麼前進到下一步。但如果你讓他從第一步開始，帶他到第二步、第三步這樣一步步證明下去，當到了第十步時，他知道自己為何在這裡，他知道這一步其實是前面十步的累積，這就是有脈絡跟沒有脈絡的差異。
而我的那些文章之所以特別，是因為我帶讀者從第一步開始走，一步步帶著他們到第十步。所以對沒什麼基礎的人來說，不會感到特別困難；對已經有基礎的人來說，會把以前學過的東西全部串起來，有種煥然一新的感覺。
教學
從以前其實就陸陸續續有在做教學，但在今年的一月終於嘗試了自己一直以來想做的事：從零到一培養一個工程師。
總共還做了兩期，計畫詳細內容可參考：程式導師實驗計畫第二期報名簡章，課程大綱也放到了 GitHub 上面，想跟著學的可以自行取用。
目前第二期已經慢慢接近尾聲，但大概要等二月初才比較好評量成效。在教學的過程中我才是學到最多東西的那個人，每次準備教學前我都必須確定自己能完全掌握要講的主題，趁機理解了一些以前很少接觸到的概念，像是資料庫的 View、Stored Procedure 跟 Trigger 以及 ACID。
課綱的部分也是按照我前面所講的脈絡設計而成，但碰到的問題是難度落差有點太大，所以還有滿多需要調整的地方。不過整體而言教的東西我認為是沒什麼問題的，該學的都有學到，而且不只學了工具，也學了原理。
教學是少數我能維持動能並堅持下去的事，雖然是兼職教學，但我自認課程品質不會跟那些全職教學的差到太遠，以一人團隊來說，我覺得做得不錯了。但當然我也不會就停在這裡，畢竟我認為課程永遠都有改善的空間。
教學相關的心得等課程結業後會再寫一篇文，這邊就先簡單帶過了，不然我怕這篇文會變得太長。
溝通
一年前剛接 Front-end Team Lead 的職位時其實戰戰兢兢，那時候主管只是問我有沒有興趣慢慢來試試看，我說可以慢慢試試看，下禮拜我就被拉到這職位了。我原本以為會先跟在主管旁邊見習一下之類的，結果完全沒有。
不過雖然說是 Team Lead，其實更像是 Lead engineer。差異在於前者會更偏向管理職要帶人，後者則是著重在技術面。我覺得以工作內容來說，其實後者更為貼近一點。
我要做的事情就是跟 PM 溝通，每兩週開一次 sprint planning meeting 看要放什麼 ticket 進來。有新的功能時要給 PM 一個大概的時間估計，也要把 ticket 分發給其他同事，決定他們要做哪些事情。
簡單來說我一個人對 PM，其他前端工程師則是負責去解那些 ticket。不過我自己也是要寫 code 啦，但有一部分時間要留給跟 PM 溝通，只要前端有任何問題他們就是找我，我自己認為大概 8 成時間還是寫 code，其他 2 成處理跟專案有關的事情，簡單來說就是要一直溝通。
以前其實就知道自己溝通能力並不差，但這次會覺得緊張是因為要用英文溝通…剛進公司的時候英文能力頗差（現在也沒多好），深怕自己只會一直跳針說：「Sorry, can you repeat again?」。
起初的時候還真的有點溝通問題，但接了這個位子兩三個月以後發現開始慢慢習慣了，開會的時候超級無敵專心聽雖然還是有些單字聽不懂，但一樣抓關鍵字就好了，聽懂七八成基本上就能夠溝通的滿順暢。
除了這個以外，最近幾個月也開始當起面試官。我一直覺得面試對公司來說是一件需要非常注重的事，因為就是公司對外的門面，一場糟糕的面試比一頓難吃的晚餐更為不堪。
對於面試我也還在摸索自己怎樣能夠做得更好，但我謹記前輩說的話，他說面試不是要比誰厲害，而是要去看面試者的優點，去看他是否適合這個位置，是否想要與他共事。如果面試只是想要電人來凸顯自己的優越，那就完全失去意義了。
順帶一提，有些人的履歷真的寫得很不怎麼樣，十年工作經驗卻看不出到底做了什麼事。
所以，我是資深工程師嗎？
好，回顧了這麼多終於回到了標題。
兩年前那篇我提到了這篇很棒的文章：如何才有資格稱為資深工程師，裡面提供了一些指標可以參考，更貼心地提供了反指標讓大家知道走火入魔是什麼樣子。
經過這兩年的磨練，在前公司獨立完成直播網站的開發，也在此期間加深自己對基礎的理解，對開發新功能的理解從：「不知道自己能否做到」轉變為「做得到，可能需要多少時間」，在自信心上面提昇了不少。
在現在的公司也終於有了更多討論與交流的機會，跟另外兩位前端討論要選哪個 library、coding style 怎麼定、檔案命名規則怎麼定等等，也更頻繁地與 PM 交流，對溝通以及專案管理有了進一步的理解。
這一年來負責公司的四個前端專案，對專案的架構或是使用的技術上也有了不同的理解，做不同的專案的時候都可以觀摩一下別人寫的架構跟程式碼，培養了看到爛 code 就會想順手修掉的習慣，對於重構之前看到有人說了一句很棒的話：「很多工程師都只會重建，而不會重構」，重構應該是漸進的，如果想等到有時間再砍掉重練，那永遠等不到。
應該做的是在修 bug 或是寫新功能時就順手修掉一些，例如說今天改一個購買流程的東西，我就會順手把那部分重構一下，不一定要做到你心中完美的樣子，只要確保比以前的程式碼品質更好就行了，這樣就會越來越好。
而工作以外的時間寫寫 Blog 分享心得，偶爾花個六七小時只為了寫一篇技術文章，大部分的時間則花在教學培訓，成功轉職的學生也印證了課綱的價值，透過教學也把自己的基礎打得更紮實了一點。
兩年前，工作經驗一年半，剛進入第二家公司任職，自認程式寫得不差但基礎不好，經驗也不足，配不上資深這個名字，因此以資淺工程師自稱。
兩年過後，我可以把前端出現的各種工具放到脈絡裡去談，去解釋為什麼會出現，解釋帶來的好處是什麼，也可以說明在專案中應該如何使用；對前端工程師的必備技能也有一定的基礎，可以跟你談 JavaScript 的各種奇怪現象，要談網路談瀏覽器也行；對 PM 提出的需求通常不會擔心做不做得出來，因為知道自己一定行，關注的點反而變成要如何實作才能做的漂亮以及完成所需要的時間；知道工程師除了寫程式以外，還有很多重要的事情要做，像是理解需求、溝通以及思考。
是的，我覺得我是資深工程師了。
認同請按讚，喜歡請分享（開玩笑的）。
接下來呢？
當你懂的愈多，也會愈知道自己不足的地方在哪裡，還有很多需要磨練的地方，就算是資深工程師，也有 90 分與 60 分的差異，學無止盡，要學的東西還多著，下面整理出幾個我想加強的方向：
第一，JavaScript 我有一定的基礎但還不夠穩，我希望能把這塊再練的穩一點，希望能穩到看任何 JavaScript 相關的文章都很難感到驚訝的程度。
第二，我在測試這方面弱到爆炸，只有 unit test 的經驗，React 裡面要對 component 做測試的話我還是不知道要測什麼，對 end-to-end testing 也沒什麼經驗。我認為測試是邁向下個階段很重要的關鍵，它可以改變你看程式碼的角度，並且讓品質變得更好。
第三，對使用的工具理解還可以再更深一點，希望能花些時間去研究 Vue、React 跟 Redux 的原始碼，去看一下他們是怎麼做的，除此之外，也能夠從裡面學到很多架構與設計方面的知識。
第四，對於一些「基礎」的理解不足，我這邊指的是瀏覽器跟網路。我大概看過瀏覽器渲染的過程，但我覺得對其中的各個環節還不夠理解，網路的話希望能把 HTTP、HTTP2 或是 TCP/IP 這些東西看熟一點。
第五，computer science 的基礎不足，例如作業系統跟計算機組織還有演算法與資料結構，如果想要再往上，這些也是很重要的一部分，想學習的話比較有效的方式應該是直接去找大學開的課程來看，幫助應該滿大。
技術是工程師的根本，不能忘記這點，也千萬不能讓自己的技術荒廢。是因為有了技術能力，我才能走到現在這個位置。
總結
很慶幸自己在兩年前有寫了那篇文章，幫自己做了一個很好的總結，正是因為有把當時的心得留下來，現在才能夠對照自己以前的樣子。
重看了一遍兩年前的那篇回顧，發現自己在觀念上還是差不多的，還是很注重分享，所以這兩年之間從未間斷。對於「痛過才能理解」還是抱持著一樣的想法，也把這些概念變成文章記錄起來，不然每提到一次就要重新再講一次，很不符合工程師的性格，能重構就應該儘早重構。對於廣度與深度的看法，支持先廣再深，因為那樣走過來的我覺得很有幫助；而小公司與大公司的問題，現在還沒進過大公司所以無法體會，可能要再過好一陣子才能跟大家分享這塊的心得。
其實每次在寫這種回顧的時候，都會先感嘆一下時間就這樣過去了，完全沒有意識到已經過了兩年；不過也就是因為這樣，會更讓人期待自己下一次會變成什麼樣子。
就這樣啦，我們兩年後再見！
評論