Web Conf 2023 心得

看到社群上有人發文 【心得】2023 WebConf 為自己留下記錄的參與心得，讓拖延症嚴重的我也想趕緊產出我自己的心得，但還是拖了三週哈哈。

前言

十年

上一次舉辦 Web Conf 已經是 2013 年，距離今年差了十年，不禁也令我回想，未來這個時間差，發生在自己身上，除了時間之外，會有什麼其他的差異，如果再過八年，我仍然是工程師，那我就是有十年經驗的工程師了，在那個階段，我需要會的有什麼？我擁有的項目有什麼？我在工作崗位上會負責什麼工作？

資訊焦慮

想想就覺得蠻有趣的，但也同時會感到焦慮，在資訊爆炸的時代，每次看到技術社群分享一些文章或技術，把它加進自己的待閱讀項目中，甚至都還沒閱讀，越滑就越多要收藏的，一直到收藏清單也爆炸了，也不知道有沒有時間把它消化完，但人生就是這樣，船到橋頭自然直，我想未來用得到的時候，就更容易與這些收藏項目再次認真相視了吧！

感謝主辦單位

感謝主辦單位：五倍紅寶石、六角學院，人稱 5566 舉辦這次的活動，認真說在知識層面有很多吸收、使自己的眼界更大、看到了一些在社群上活躍的人、瞭解別的公司在採用的 pattern、探討軟體職涯心態、討論面向 AI 的應對、資安、創業經驗談、網站特效、前端監測系統。

我覺得從本質上出發很好的重點是，很多人原本都埋首在自己的日常中，能有這樣一個場合，讓我們能把頭抬起來，聽同在這個環境埋首的其他人，互相分享自己的成果與經驗，從實體層面參與了技術社群，而不是只在網路上。

想稱讚此次的吊牌是厚板 + 不用歸還的吊繩 + 背後還有可以註記是否有領取過餐點的地方，兼具功能性與美觀！

還想稱讚此次大會開了 Web Conf 2023 共筆 - HackMD，讓現場幾百人共同編輯一份筆記，實在是太棒了，節省很多人的時間，就可以更專注的聽講者的分享，希望未來參加的 Conference 都可以有這樣的共筆機制。

第一天議程與紀錄

活用 GitHub Copilot 開發 Web 應用程式 - Will保哥

共筆連結

我平時就是 Copilot 使用者，因為透過 AI 自動計算開發者可能想要的結果，並且可以使用 auto complete 的方式來寫 Code 實在是太爽了，有這樣的工具，真的可以省下很多打字的時間。

在保哥的分享中我聽到一些我不知道的事情：

1. CMD + \ -> 觸發生成建議
2. CMD + Option + I -> 選取片段，並使用 Copilot Chat 進行互動

這一點非常棒，因為之前需要透過 Tab 的 Copilot 對話窗，才能進行對話：

使用上仍有一些彆扭，不夠方便，這個快捷鍵可以讓我們更快速的進行對話，包含寫文件、修正、測試等等，並且可以隨時隨地選取片段，進行對話，這樣就不用一直在 Tab 使用了。

3. q + a 小技巧

在編輯器裡面使用這樣的註解，可以讓 Copilot 生成建議

q: 以下這段 code 在寫什麼
a: 說明這段 code 的功能

4. 正體中文較繁體中文更精準

在使用 Copilot 的時候，使用「正體中文」，會得到更接近台灣區用語的建議

5. 版權問題可以透過 Code referencing for GitHub Copilot

因為 Copilot 本身是透過 GitHub 的程式碼來訓練的，又因為各專案的 License 不同，所以可能會有版權問題，所以 GitHub 推出 Code referencing for GitHub Copilot 來解決此問題，透過此功能，可以在 Copilot 生成建議的時候，將原始碼的來源一併顯示出來，讓開發者可以更清楚的知道來源，並知道來源採用的 License 是什麼，讓開發者自己判斷，要不要採用該建議。

WebComponent 的好，用過的都知道 - 奶綠茶

共筆連結

以前從來沒用過 Web Component，這次奶綠茶分享公司內部專案使用 Web Component + petite-vue，主要是因為現今前端框架帶來的 JS 成本太高，遇到一些效能瓶頸的問題，所以才會改回走原生 Web Component 的路線。

Web Component 可以透過 Shadow DOM 來將 HTML 結構、樣式與行為封裝起來，就像是一個安全小屋，即使 class 外部一樣也不會造成衝突，並且可以透過 attachShadow({ mode: 'close' })，close 表示不可以透過頁面內的 JavaScript 來獲得 Shadow DOM，open 則是開啟。

並且可以使用 slot 來做插槽，讓外部可以注入內部的 HTML 結構，這樣就可以讓 Web Component 更具彈性。

加上生命週期函數，來做一些客製化的調度

connectedCallback：当 custom element 首次被插入文档 DOM 时，被调用。

disconnectedCallback：当 custom element 从文档 DOM 中删除时，被调用。

adoptedCallback：当 custom element 被移动到新的文档时，被调用。

attributeChangedCallback: 当 custom element 增加、删除、修改自身属性时，被调用。

另外因為原生的 DOM 操作太過繁瑣，所以使用打包後僅有 6KB 的 petite-vue，依賴輕量版的 Vue（不使用 Virtual DOM），來節省程式碼行數。

成為前端建築師吧！透過 Frontend Infra 為前端應用打造穩健且高效率的開發體驗 - 莫力全(Kyle Mo)

共筆連結

作者紀錄

在去年 MOPCON 2022 就有聽過莫力全分享的 「導入 Lighthouse CI 作為前端應用的效能守門員」，當時就覺得很厲害，能在大型公司裡面建立前端建築，重視複用性、效能、安全性、可監測性，將 LightHouse CI 整合進 CI 中，並把結果都存進 DB，建立公司收集各專案的 console，來監測各專案的效能統計圖。這次分享的內容也是在 Line Taiwan 前端的 Web Frontend Infra 這個基礎上，進一步分享前端建築師的角色。

Frontend Infra 這個詞通常被用來描述為了提升「開發效率」和「產品質量」而導入的一套系統、流程或工具，並且常常包括一些關於如何使用這些工具和系統的最佳實踐或標準。

Web Infra 有幾個目標：

• 統一技術棧
• 共用模組 (Project Generator, Basic GitHub Action config, LightHouse CI basic Integration)
• 統一開發準則 (ESLint, SonarQube, Design System)
• 提升前端應用的可觀測性

動態應用程式安全測試（DAST Dynamic Application Security Test）

指的是透過模擬駭客攻中的手法，由外而內找出 web 應用程式漏洞的過程，例如: SQL Injection、XSS、CSRF、授權缺陷等等。特別不一樣的是 DAST 工具是在動態環境中運行，可檢測出靜態應用程式安全測試（SAST Static Application Security Test）如: SonarQube，在運行中無法識別的缺陷。

在這篇 ZAP 官方發文中，指出可以透過 ZAP Full Scan 在 CI 過程中做動態安全性檢測。

在 CI 流程中加入安全性檢測，使傳統的 DevOps 變成 DevSecOps(Development, Security, Operation)，如

聽完 MOPCON 2022 加上這次的分享，我覺得在公司內有這樣一個 Web Infra 團隊，可以為公司的前端團隊提升效率與品質，真的很棒，也讓我想到了我們公司的前端團隊，我們都有在各自的專案中加入提升 DX、可監控性、複用性的想法，甚至已經有一些共用模組了，但我們還沒有一個專門的團隊來把做這件事情做的完整，希望未來有機會可以加入或是擁有這樣一個團隊，光是用想的就會覺得很有趣且很有意義，因為可以跳脫一般的產品開發流程，探索前端領域的不同面向。

小團隊有小團隊的做法

Frontend Infra 這個詞通常被用來描述為了提升「開發效率」和「產品質量」而導入的一套系統、流程或工具，並且常常包括一些關於如何使用這些工具和系統的最佳實踐或標準。

再次提到 web Infra 的概念是為了提升開發效率與產品質量，但是在小團隊中，可能沒有足夠的人力來做這件事情，所以可以透過一些工具來幫助，例如:

• Renovate: 依賴管理工具，可以設定排程定期更新依賴，可以依據 semver 指定更新的版號，並且可以設定 PR 自動合併。
• Preview URL：使用 Vercel 提供的 Preview URL 功能，在遠端分支有發生變更時，會自動部署到 Preview URL，讓開發者、PM、UI/UX 等等，可以在 PR 尚未合併前，變更後的結果，好處是合併前的 Code Review + 測試很方便，且 Vercel 提供在網站中像 Figma 一樣註解的功能。
• 降低 Docker Image Size: 按照傳統的 Docker 打包方式，會把所有的依賴與未打包的資源都打包進去，但是這樣會造成 Image Size 很大，所以可以透過 multi-stage build 的方式，只將打包後的結果 build 成 image，這樣就可以大幅降低 Image Size。再加上 Next Output Tracing，做到在檔案層級的 Tree Shaking，僅打包使用到的檔案，這樣就可以再大幅降低 Image Size。
• GitHub Action Cache & Artifacts：若依賴的 package.json & package-lock.json 都沒有變動，就可以將 node_modules cache 起來，不用重新 install
• CI/CI Pipeline - Bundle Size Diffing：在 pipeline 中加入打包後體積的比較，並設定一個閾值，若超過閾值就會失敗，這樣就可以在 PR 合併前，去檢查體積變大的原因，並提早優化。
• CI/CI Pipeline Dev Process Optimization：在 CI 過程中自行加上 GitHub Label
• Observability 可監測性：現今 SSR 普及的情況下，越來越多前端的應用中，也有前端自己的 API，或是與其他 Server 溝通的可能性，這些流程若出現問題，會難以追蹤，所以可以在前端的應用中加進 Logging 的流程，通常可以依賴第三方服務，如 Sentry, New Relic，並建議畫出自己前端團隊的流程圖，範例：

在前端架構的領域還有很多很多的事情可以去做，例如 k8s, Serverless, GraphQL, WebAssembly, 微前端, Design System, CI/CD, DevOps, DevSecOps, Observability, DX, Testing, Performance, Security, Accessibility, SEO, Analytics, Monitoring, Logging, Error Tracking, etc...，這些都是可以讓前端團隊更加強大的領域，也是我們可以在未來去探索的領域，原則是：任何你覺得可以幫助提升開發流程、使用者體驗、效率，且適合團隊與專案的方法或工具，都可以是前端架構師的工作事項一環。

結論

• 前端開發者的分類與角色具有多樣性，有切版、做動畫的，有只做專案的，也有為了前端架構而努力的架構師，不一定要將自己侷限在某個角色中，多方體驗與嘗試，才能找到自己的興趣與方向，並提升自己的競爭力。
• 不論團隊規模，都可以討入 Frontend Infra，但跟團隊文化有關，必須要適合。
• Frontend Infra 與 DevOps 可以有緊密的連結，將一些管理的流程自動化，並加入 CI/CD 中，讓開發者可以專注在開發上，也可能更便於管理。
• 最重要的結論，不要過度導入，每間公司、每個團隊、每個專案都沒有最好的方法，只有最適合的做法，過分導入，但體質不適合，反而會造成更多的問題。

建立高效的遠端協作團隊：策略和實踐 - 劉艾霖(AILIN LIOU)

共筆連結

遠距也是我未來想要嘗試的工作方式，在此次的分享當中聽到一些我沒想過的面向，例如遠距工作的團隊因為，跨越距離邊界，可以更容易找到罕見的人才（如 elixir語言人才）；跨越時間邊界，利用時差，團隊可以 24 小時運轉。

在遠距工作的團隊中，也存在一些特性，導致工作的流程與一般在公司上班不太一樣，例如重視「非同步溝通」的概念，溝通優先採用公開「文字」，使用大量的線上工具來管理，重視文件化，並且建立知識庫。例如在 Slack 溝通中，選擇在頻道開一個串「Thread」，並在裡面討論細節的架構或是業務邏輯，或許這會成會一個非常有價值的討論，並且團隊中所有人都可以看到。

新人加入遠距團隊工作中，與一般公司有不同的 Onboard Flow，時間更長，可能會拉到 2 - 4 週，並有小天使制度，頻繁的與新人 pair programming、code review，並在過程中降低新人壓力，避免卡關很久卻沒人發現。

再來就是需要建立一些準則：

1. 溝通準則

• 非同步溝通
• 管道
• 面對面：Team Building or 敏感話題
• 視訊會議：外部人士、概念發想、全公司
• 即時語音：非正式短會議
• 即時通訊平台：沒有明確任務的溝通（不需要追蹤的）
• 電話：緊急、突發事件
• 不適合用文字就用視訊

2. 線上會議準則

• 短會議優於長會議，30 分鐘內結束
• 提前寄出資料，讓與會者有時間做功課
• 確保會議是「雙向溝通」
• 不參加非必要的會議，參加就要全心投入

3. 離線準則

• 共識: 一條訊息多久回覆可以接受

4. 移動準則

這個比較特別，因為福利與保險是屬地主義，另外延伸的事法律相關的，如課稅、合約等等問題，所以會訂定可以在一個國家待幾個月的準則。

5. 休假準則

• 如果會有兩個小時以上聯繫不上，就需要請假，並根據職位評估這個時間

6. 補助準則

• 工作設備補助
• 請款準則

7. 資安準則

• 設備不共用
• 檔案不能離開公司電腦
• 禁止連公開 WiFi
• 特定軟體只能透過 VPN 使用

另外就是可以多參考遠距工作成功的團隊範例，學習一個有效且成功的團隊的運作模式，如：

• wordpress
• ethereum
• buffer
• gitlab
• zapier
• slack
• trello
• atlassian

最後，高層的心態會影響遠端政策成功與否，如馬斯克收購後，即禁止員工遠距上班 馬斯克給推特員工的第一封信：即日起禁止遠端工作

那些理所當然，卻像空氣般重要的小事：談開發流程、程式架構與職涯發展 - PJ (陳柏融)

共筆連結

這次第一次看到 PJ 本人，覺得很新鮮，因為平常都是在社群、部落格上看到他的文章，這次分享的內容比較平常、細碎，且有一些軟體哲學相關的。

如果在團隊中，對某些程式碼有潔癖、想要有規範，在過往的經驗中，可能會一直在 code review 的時候叮嚀，但有時候那種寫法可以運作，不會是一個問題的時候，再去提起，就會讓自己變得像「糾察隊」（這個比喻超好笑，蠻精準的），所以一發現有這種狀況發生的時候，就可以想如何把這種瑣碎、講到爛的東西「自動化」，如在 CI/CD 流程中加上 客製化規格 & Lint 的機制、已經 Review 過的 PR，修改後自動改為需要重新 Review 的狀態、自動加上 PR Label 的機制。

將文字規範當作最不得已的一步，因為文件往往有些缺點，最常見的就是沒人要看，看了容易忘，最後乾脆直接用問的。

什麼是好的、可以維護的程式碼？

接著提出一個問題給觀眾思考，什麼是好的、可以維護的程式碼？

維護程式碼的是人、是團隊，要如何做取決於團隊的習慣和開發經驗

• Declarative? Imperative?
• CoLocation? Modularization?
• DRY? PRY?

這些沒有絕對的答案，只有最適合的答案。

個人成長與職涯

• 影響力 + 選擇 > 實力
• 選擇比努力更重要 (Work smart, Not work hard)
• 不要被角色侷限，將自己定義為 ＯＯＯ 工程師，大家都是團隊中的一份子，或許可以成為提升團隊效率的 10x 工程師

從專業到商業：十年軟體架構變遷 - Ant

共筆連結

坦白說這是我第一次聽架構師的分享，蠻震驚的，因為從他的簡報當中可以看出他對軟體架構、前後端技術、DevOps、等等與軟體相關的內容都有深入的理解，甚至是幾十年間的架構變化，都非常清楚。

內容太多、有深度，我僅紀錄幾點我比較聽得懂的，且方便記錄的

• 國外的 DevOps Conference 沒有在分享技術工具，大部分都在講概念
• 應該思考一下，如果我是面試官，面試者是現在的我與十年後的我，我會錄取哪一種人？這個問題可以幫助我們思考自己的職涯發展，並且思考自己的職涯發展是否有在正確的方向上。
• Micro server（微服務）弄不好，可能會變成 Micro Sorry（微抱歉），因為不適合。什麼樣的公司適合微服務？真正需要水平發展架構的公司，通常流量都非常高。
• 軟體設計進展（以下的設計沒有最好的，只有最適合公司狀態的）
  • 1980 年代
    • ITIL：Design for Robustness 堅實性設計
    • 精心設計
    • 嚴格控管
    • 故障被視為異常處理
  • 2008 年轉型
    • DevOps: Design for Anti-Fragility 抗脆性設計
    • 將開發及維運視為一體
    • 視故障為正常狀態
    • 為故障設計隔離
  • 2014 年
    • SRE: Design for Resilience 彈性、復原性設計
    • 將維運視為工程
    • 最小化人為錯誤
    • 為故障復原至正常狀態 (Rollback)
  • 2019
    • No Deploy: Design for Deployless 無部署設計
    • 將維運視為內嵌
    • 最大化結果（outcome）
    • 為故障復原單一領域
• 選擇重要還是努力重要？
  • 選擇：提高上限（提高薪水上限）
  • 努力：提高下限（提高低薪下限）
• 無視人員、流程，只講技術，是耍自傲
• 架構會影響公司文化、商業擴展，思維要超越程式碼層次
• 要避免沒有大公司的命，得了大公司的病
• 盲目套用別人的架構，不會讓你變得跟他樣好
• 若無法舉出架構的缺陷，代表你還無法掌握
• 沒有完美的架構，只有最適合的架構
• 到一個組織時，可以先畫畫組織圖、流程圖，看看哪一個部分會是 Bottle Neck（瓶頸）

第二天議程與紀錄

鳳‧極意？！ - Paul Li

共筆連結

簡報

• browser 原生 input 提供很多 type，如: email、url、color、file、datetime、search、text、number、range 等等
• 製作 video 客製化 panel 時，進度條的功能就可以直接依賴原生的 type="progress"，使其擁有拖曳、放置的事件，並且可以透過 value 設定進度條的進度
• accent-color 可以用來客製化 type="checkbox" 的樣式
• :invalid 可以用來偽類別來判斷 input 是否通過驗證
• select + optgroup 拿來製作下拉選單的分類
• 客製化 checkbox 時，可以透過 :checked 來判斷是否被選取，將原本的 input 隱藏，使用 :after & :before 畫一個新的
• 使用 inert 來禁止 DOM 元素互動，例如表單提交 Loading 的時候。
• 使用 Form Element checkValidity() 來驗證表單。
• 使用 AbortSignal 來移除 addEventListener 監聽器。
• 使用 closet 來找到最近的父元素（或元素本身）。
• innerText 與 textContent 的差別是，innerText 會忽略隱藏（未渲染）元素，textContent 不會。
• 使用 autocapitalize 來控制虛擬鍵盤上的英文大小寫行為，如: autocapitalize="none"，autocapitalize="sentences"，autocapitalize="words"，autocapitalize="characters"
• 使用 autocorrect 來控制 input 的自動修正，如: autocorrect="off"，autocorrect="on"
• 使用 autocomplete 來允許 User Agent 有權限在填寫表單時提供 input 的自動填入，如: autocomplete="off"，autocomplete="on"
• enterkeyhint 用來調整在虛擬鍵盤上 Enter 的顯示標籤，如 enterkeyhint="go"，Enter 就會變成 Go
• inputmode 來調整虛擬鍵盤的類型，如 inputmode="numeric"，就會變成數字鍵盤。
• 使用 CSS Logic Property
• 使用 CSS :has 偽類別來選取有特定子元素的父元素，如 div:has(#radioB:checked)，選取 div 中有以勾選 radio input 的元素
• details 元素因為具有 Toggle 功能，可以用來顯示或隱藏資訊，非常適合拿在製作 tip 或額外資訊的顯示。
• dialog 元素可以用來製作 Modal
• 展示很多 Paul Li 自己製作的 web component，如：Image Uploader、Input Assistance、Tags Collector

整體來說，學習到非常多東西，甚至都沒有聽過，Paul Li 的內容值得一直複習，或是延伸去查 MDN 文件去學習，也帶來很多啟發，非常優秀，不愧是 Google Developer Expert。

從零打造前端效能監測系統 - Summer Tang

共筆連結

逐字稿

Summer 分享使用 Sentry 來進行前端監測的經驗分享，首先是遇到的問題，如：一個體積很大的資料從後端傳到前端，且前端需要花費成本來進行大量的運算後渲染，會遇到的問題就是，取得資料的時候需要大量的網路傳輸時間，且大量的資料運算，會佔用 main thread 太多時間，導致畫面卡頓，對使用者體驗來說不好，可能會需要 Loading 很久 + 每做一個動作就感覺卡卡的。

有很多方法可以改進，如：把計算的工作量切小，根據 context 做切換，或是丟到 web worker 計算，減少 main thread 的負擔。至於網路傳輸的部分，可以對資源壓縮，或是使用 preload、prefetch、lazy loading 等方式，讓使用者早點看到畫面，然後再用非同步的方式慢慢載入。

這些方式都可以優化效能，但是等遇到問題的時候再來解決，那反應就太慢了。 會發生這些狀況，大概可以總結幾個原因：

• 不知道客戶的資料量這麼大
• 沒有把這個問題在每次 build 的時候做效能測試

希望可以做得更好，預期做到幾點：

• 可以檢測大量資料
• 自動化檢測每個 build
• 可以預知問題 + 通知，讓問題萌芽之時，就可以及早被發現
• 融合日常，足夠簡單

相較於 Lighthouse 和 Chrome DevTools 模擬進行網頁效能衡量，Sentry 或 New Relic 是實地的。

可以透過 Sentry 設定 Threshold，當超過閾值的時候，就會發出通知，例如：LCP 超過 500ms 就發出通知。

後面就是的 GitHub Action + Sentry 的實作說明，詳情可以直接參考 Summer 的部落格。

10 年回顧：打造愛料理開發及營運團隊 - Richard Lee

共筆連結

Richard 十年前在 Web Conf 分享在愛料理團隊中，覺得好的一些做法與值得分享的方法，但十年後的今天，他想重新提出一些想法，從十年後的角度來看當時的好，在現在來看是否還是「好」。

愛料理的成功可以歸功於「主題選得好」，因為全台灣每個家庭幾乎都會需要煮飯，資訊發達的時代，網路上的食譜變成很好搜尋的東西，愛料理的平台變成一種硬需求。甚至在疫情期間，大家無法出門的時候，創下 600 萬月流量的高峰。

總而言之，主題挑對「事半功倍」，主題挑錯「事倍功半」。

急著做 AI 的整合不一定好用，愛料理的 App 整合了 AI 聊天室，但使用率非常低。

換了非常多工具，花了很多時間遷移到新工具上面，但實際上換工具實際效益不高，反而花了很多時間成本在遷移上面。

在公司規模小的時候，正當產品是從 0 - 1 的時候，人人都參與討論是一個高效率的方法，因為不需要花時間同步，且大家都在核心的團隊中貢獻，了解整個產品的 Context 對於討論來說是非常重要的。但是當公司規模變大，這種討論的方式就會變得非常沒效率，因為大家會花很多時間都在討論，做事的時間會減少，所以這時候就需要有人來做決策，並且讓大家去執行，這樣才能提高效率。

堅持開發者體驗是好的，CI/CD 加上 Linter 的流程，保持專案不被污染，是上版的底線。完整的 Git Flow & Pull Request 機制，版空不會亂七八糟。關於監測的工具從早期就投資進去，大量的資料量，可以讓團隊更有信心去做決策。

• 沒有監測的產品不算上線，包含服務穩定度監測（Http 5xx, 4xx 追蹤、Health Check）、效能監測、錯誤追蹤。
• 過早的最佳化通常都是失敗的來源。
• 做程式做產品是兩件事（享受寫程式 v.s. 享受做產品）
• 工程團隊的價值來自於產出商業成果
• 南瓜計畫：該砍則砍，留下的必須要賺錢，包含裁員與任何需要花費的成本

心得

Web Conf 真的辦得很成功，身為一個開發者，覺得在這次的大會當中學習到很多東西，雖然不一定有吸收。但是至少知道有這些東西存在，並且可以在未來的工作中，去嘗試使用，或是在未來的學習路線中，去學習這些東西。每年可以在這個時候拓展自己的眼界，可以讓平常埋首於自己公司專案的我，可以看到更多不同的東西，也可以看到很多平常在社群上活躍的人，覺得很好玩 XDD

再來就是有些乾貨要去啃，例如：

• CSS Logical Properties and Values - MDN
• 看遠端工作團隊是如何成功的，如： wordpress, gitlab, slack, trello, atlassian

很多事情可以嘗試去規劃並執行，例如：

• 公司的流程圖
• 公司前端的工作流程

最後，謝謝主辦單位與所有工作人員！