JSDC 2020 的前端反思

October 28th, 2020

前言

今年是個特別的一年,有惱人的疫情不能出國,還在人生職涯的道路上耍了點任性 😳,算是給這一年多來所發生的許多事情一個沈澱的機會,也很慶幸自己能夠在這樣的狀態下有另一半的支持,並且從中更了解自己的情緒與缺點,並為自己充電、精進。

而在朋友的介紹之下,也在今年參與了 ALPHA Camp 助教團隊,也從中獲得了許多不同於以往的純工程師生活,展開了許多程式的交流互動與教學經驗的分享。ALPHA Camp 也很貼心地準備了 JSDC 2020 的票券給緊密合作的助教們,也很榮幸能夠有這樣的機會取得票券,觀賞這一年一度的前端盛會! 🥳

JSDC 2020🎉

今年因為疫情的關係🧛,所以整場研討會都是透過 YouTube 直播 📹,以遠距進行議程討論。其實在觀看的體驗上還挺滿足的,一方面愛地球,二來除了可以看到當前的議程,也能對過去議程進行回播!方便、快速、有效果!🙌

對於整場會議,我覺得可以分為因應環境變化的工作心法前端技術產品開發思維,以及工程師職涯發展的四個面向做一個個人的整合紀錄。

因應環境變化的工作心法

會把標題下成 「因應環境變化」的主要原因,是個人認為裡面所討論的心法,其實感覺可以廣泛用於一般開發者在協作交互的應對之上,所以用一個可以包含遠端協作與一般協作的說法🤪。

議程討論中,在工程師面對環境變化的應對上,給予了很多的看法討論。尤其在 面對遠端議題上 許多講者也給出了很多不錯的結論。從 TonyQ 與 邱弘毅 的命題內容,其實主要可以感受到工程師在彼此之間對於共同目標的認知,需要用更謹慎、細膩的態度去面對,雖然這些議題背後是從遠端協作所衍生而出,但我認為平常對於面對面的協作更要多多自我檢視、嘗試導入這些面向,來讓自己與團隊的溝通更精實,也可以無形中形塑自己的無形資產。以下是我從 TonyQ 與 邱弘毅 的講題內容中抓取我認為重要心法,並分為 個人與他人互動環境 三個廣度下的紀錄:

個人

  1. 不懂就要問!
  2. 不要將任務 tickets 塞滿,要適當地交錯不同難易度的任務(防止可能不如預期的任務交付),或是重要與不重要的(防止團隊相互 blocking)。
  3. 對當前需求目標的實踐過程中,相互 Blocking 的狀態要嘗試溝通出解決方案(Do Blockers first!~)。
  4. 培養容忍心與同理心,去看待在遠端協作下團隊認知容易不對等的問題,並嘗試解決。

與他人互動上

  1. 在明訂的時間區間中,持續讓團隊知道你還活著(Keep Alive)
  2. 自己要重視對於團隊工時的掌握,知道在每個人工時時差之間的委派運作,也就是什麼時間、遇到什麼事情、需要找什麼人的運作邏輯。
  3. 反覆確認彼此對於需求目標的認知是否對等。
  4. 面對 SOS 狀態要遵守流程,如果與自己不相干則不要過於雞婆,以防止團隊溝通成本增加;而針對 SOS 的管理機制要掌握 事前抑制、事後獎勵 的作業機制。

環境

廢話不多說,我覺得最重要的就是 Tony Q 後面說到的:

團隊之間要能夠掌握協作環境,並且管理者要以能夠達成每一季的目標管理為目的,做管理工具的選擇與規劃。

前端技術

這次在前端技術上的討論,覺得可以以程式寫作為核心由內部到外部分為:

程式面的觀念
  • 多執行序 -- PJCHENder;
  • API mocking 的工具分享 -- Huli;
  • JS or TS 的選用 -- Jeremy Lu / 保哥。
框架的討論
  • AMP -- Paul Li、
  • React Hooks 的使用手法與概念初探 -- Mindy Tai;
  • React Native 跨平台開發的經驗討論 -- Bingo。
跨專案管理架構討論
  • Lerna(Mono Repo) 的跨專案管理建構 -- Fong。

以下我就針對我有所感的議題進行個人單方面的紀錄!

程式面的觀念

在非同步的議題中,PJCHENder 有探討到同步、非同步、並發運算、平行運算的概念釐清,並且說明普遍前端開發上對於 JS 利用非同步語法時的誤解:

複雜的運算採用非同步語法執行時,並不會因此得到平行運算的效果。因為非同步操作仍舊會被擺入 Event Loop 的運作架構中,並在某個時機點回到主執行緒中執行,服務依舊會被卡住。

雖然自己知道這樣的運作模式,但有時在直覺上,也非常容易會對非同步語法有過於期待的思維 XD,而我們如果要在 Node.js 做到平行運算(parallelism),則是要嘗試導入 worker_threads 的實作! 而自己也另外查了一下,在 Browser 端則有 Web Workers API 可以提供網頁在背景執行其他的 thread,而不影響使用者在網頁上的操作處理。

突然想到,這邊無形中可以跟 Huli 所提到的 MSW 背後運用的 Service Worker API 做串連,雖然實現的功能不同,可是背後都是運用 Web Workers 來實現的!🥳

而這邊對於這樣的架構,讓我想起在 Web Audio API 中的 AudioWorklet 也有類似的實現,主要是希望能夠解決前端在實作客製化的聲音處理演算實作時,能夠透過實作 AudioWorkletProcessor 去生成其他的 thread 去拆分實作,來減少對於主執行緒的效能減損。

在 Huli 提到的前端 mocking data 部分,則是展示了 MSWMirageJS 的基本運作介紹,可以說充分展現前端的 任性(韌性)!並且在韌性(mocking data)的基礎上還能夠做後續的測試,讓前後端的接口可以運作得更順暢!想想當初剛出社會不畏虎,那些自己硬幹假資料的日子真的不堪回首🤐。時至今日,前端的技術日新月異,測試驅動、自動化的操作越來越興盛,如何讓自己的開發流程可以趨於架構化,也是我要一直不斷去追求的理想!

再來提到 TS or JS 的選用的討論,因為自己同時有使用過 React 與 Angular 經驗,加上在 React 專案中也有使用過 TS,所以個人認為在 TS or JS 的選用上會覺得不是一個絕對的答案,而是要針對專案的需求去取得最佳的選擇策略。Jeremy 在結論也有提出「降維打擊,導入FP、狀態機」的初步建議,這勾起我對 XState 的記憶,回想當初第一次聽到 XState,是在某個研討會中所邀請到的 David Khourshid 的演講之中,好東西果然會被名留青史🕶️;保哥也有說到,如果痛點出現,則導入 TypeScript 能夠透過 TS 的型別推論給予程式寫作上的引導作用,對於 data 的定義會相對有所輔助。這兩個面向其實結合起來就是「進可攻、退可守」思維結論,沒有必要針對都能解決問題的工具進行定調,而是要:

正視自己的使用的工具能否符合需求的規模,並把握降維打擊、漸進式地導入 TS 也不遲,並且對它的缺陷有所意識。

當然自己在實作 TS 經驗中,對於框架以外的開發實作,相對於純 JS 開發真的會如 Jeremy 所說,會花費了很多時間在定義 interfaces 或 types,或是解決不匹配的指向問題,而我們是否真的要花費這樣的時間在定義介面、型別?還是我們應該選用更好的工具去減輕定義、快速開發?這樣的 trade-off 是我認為蠻值得去思考與持續歸納經驗、心法的事情。

前端技術總結:技能樹,點起來!

框架的討論

因為本身有在使用 React Hooks,所以對於它的特性就不再贅述 🤫。

而對於 Paul 在 AMP 的議題討論上,讓我滿驚艷的部分是,Google 對於文字與多媒體搜尋的優化真的不遺餘力,並且也提出許多 AMP 的網頁開發標準來供我們依循,並且提出許多輕量的組件切分、載入的策略,來讓開發者可以漸進式導入 AMP 標準,從而得到 Core Web Vitals 評分優化的目標。

當然議程中也有討論到許多 AMP 所提出的概念,如:Remote SD Fetching 建構搜尋結果與頁面資訊的無縫關聯、Payment Request API 加速付款流程的 UX 架構、amp-img 中已內建 Lazy load 功能、app-list 在 infinite scroll 的優化表現等,都激起我對 AMP 正向的學習動機!且 Paul 也有提到未來不排除 AMP 會列入 Desktop search 的結果之中,這意味著 AMP 在 SEO 的未來趨勢上,勢必佔有一定的比重。

跨專案管理架構討論

這部分的議題主要是 Fong 所分享的工具 - Lerna ,它是一個利用 Mono Repo 架構管理多 packages 的 JS 專案的工具。Mono Repo 架構主要能夠解決跨專案開發流程之間許多的耦合問題(重複性的程式碼、強耦合、難以追蹤錯誤程式),並且進一步達成跨專案之間一致性開發流程、隔離的環境環境下執行 Repo 的一系列開發流程 、CI/CD Pipeline 設定等等的優點(微微手癢 XD)。而 Mono Repo 在子專案設定彈性、專案權限設置的機制上還是存在著問題,不過確實可以看得出它的潛力,或許未來有機會可以來初嚐一下它的魔力 🔮。

產品開發思維

雖然 Bingo 所討論的 React Native 跨平台開發命題,應該要放在文章的 框架的討論 中,不過其中的心得分享我個人認為很適合拆成一個主題,來時常提醒自己 😇 😇。

在 Bingo 討論 React Native 跨平台開發上,除了分享許多 React Native 在跨平台開發問題上的各種解法外,最終所歸結的心得實是整場 JSDC 中我感觸蠻深的部分,並且也非常認同,他提到心得大致的意思如下:

現今跨平台開發相對來說依舊是難的...

而在採用了跨平台框架後,不同平台在面對需求開發時的問題依然會存在。所以我們應該要做的不是去尋求不同平台之間在需求開發上的差異化,而是要嘗試將需求做收斂,盡可能地讓需求達到跨平台共用性的目標,並讓它們在跨平台開發中最大化,才能夠降低開發成本、便於版控與維護。

雖然這個結論是有關跨平台開發面向,但在許多純 Web 的 SPA 產品上,也時常會遇到這樣的問題。就我的經驗來說,我曾在公司內部開發 SPA 產品,並且希望產品的功能在不同的裝置上會有不同的功能呈現,當時我們時常會將使用端根據裝置的不同來做需求拆分,然後進一步去思考不同裝置之間需要的呈現,或是思考如何解決不同裝置之間在面對需求不對等的情況時,要如何透過介面改善?

然而當我們圈出這些問題的同時,往往都是一切變異的開始...

這些問題其實相對於剛剛上述所歸結的心得,是相對發散的開發策略,這也會使我們在跨平台開發上,會面臨到平台差異化越來越顯著的窘境。這也不外乎會影響我們的程式架構、介面操作邏輯、狀態機制的管理,甚至無形中導致版控困難(一般情況底下,除非有良好的版控機制,如:Git Flow,否則通常都會有一定的版控歷史共業與限制),形成一顆不定時炸彈。

所以適當地將需求收斂,將會對開發團隊、開發時程上,取得一個相對聚焦的目標進行開發,當然這樣的論點也要所有團隊的成員,甚至是 BX(Boss Experience) 去取得認同與支持,也或許身為開發者的我們也要用更積極的態度去介入、爭取這樣的共識。

這邊也順勢分享一下 Airbnb 在面對跨平台 UI 設計 的文章,裡面也提到他們如何在跨平台的條件下去優化使用者介面,確保畫面一致性所帶來的優勢。另外這是我的好友所分享的文章:UI/UX|跳脫 iOS/Android 的限制,為「使用者」做設計吧,內容主要是在說明在平台差異化底下回歸使用者體驗的反思,值得細細品味,對我收穫良多 😊 😊。

工程師職涯發展

這邊想要特別紀錄 Rex Chen 對於工程師在面對職涯上的一些哲理分享:

  • 每次去一個新的工作,都要設定好自己來這裡的目標;並在離開時,去檢視自己是否有達成這個目標。
  • 時常去發現生活中的問題,並培養黑客松精神去解決這些問題。
  • 比起選公司,選擇對的老闆更重要,他會影響你的學習歷程與視野。
  • 薪水對於一個重視職涯發展的工程師來說,永遠不是最關鍵的選擇。
  • 工程師的學習永遠是最重要的,對於新技術往往會有如過去馬雲對於機會所提到的特徵:

    很多人輸就輸在,對於新興事物,第一看不見,第二看不起,第三看不懂,第四來不及。
    --- 馬雲

  • 要多方認識自己、了解自己,才能做出不讓自己後悔的選擇。

結論

以上就是我個人整理今年在 JSDC 2020 所得到的心得,雖然寫得冗長,但主要是希望自己能夠更有架構地去以這樣的脈絡為參考,勉勵自己在前端道路上持續精進。

這次研討會所探討的議題面向全面、深入淺出,從前端程式寫作到各種框架的探討,甚至後期的測試部署、外部的職涯分享,理性與感性面都給予我許多建議與參考,也讓我在前端學習道路上更有方向,且學無止境(攤)、永不無聊 😜

最後,書到用時方恨少,只能警惕自己要多多接觸新的事物,並且將目標擺在 🏔️🏔️ 正確理解、彈性應用 🏔️🏔️,才能夠在環境多變的狀態下去適當地改變自己的寫扣姿勢!

延伸閱讀紀錄