【心得】2023 WebConf 為自己留下記錄的參與心得
如果十年後我還是跟現在差不多，那絕對不會是我自己期待的樣子，所以今天也想特別留下一點記錄，一方面不要忘記自己這次得到的收穫，另一方面也不斷提醒自己，努力不要成為十年後想起當年會後悔的模樣。
好險我買票了
這次參與了 2023 WebConf，當初看到 FB 和官網在宣傳的時候，就覺得一個 Conference 隔了十年再辦，這背後的動機一定不簡單。所以自從得到資訊之後，我就一直很期待這個 Conference。不過這次的票價也是不便宜，所以「到底值不值得？」這件事情討論度也很高。
為了這件事情我還特別去瞭解一下自己的公司有沒有相關的教育補助和公假可以支持員工參與這樣的活動，所幸公司也有相關的福利，所以毅然決然就下定決心要來參加，畢竟前幾年疫情也沒有機會參與實體的活動，而且看了講者名單也很令人期待。
這次好像總票數是 600 位，盲鳥票就佔了 400 張，雖然票價有點高，但是也是不到幾十分鐘就一掃而空。真是可怕。還好原本就下定決心一定要去，沒有在那邊猶豫半天，所以一開賣就衝進去買了。聽完兩天之後回過頭來想，真的覺得當初真的買對了(雖然還是希望票價能夠低一點🤣)。
十年
2023 年絕對是令人難忘的一年，從各種意義上來看都是這樣的感覺。
今年是 WebConf 第二屆，那第一屆呢？在去年嗎？不，是在十年前，2013 年。今年的許多場次都不斷提到「十年」這個單字，因為有許多講者在第一屆都有上台講過，因此也都分享自己十年前上台的照片，看完真是覺得「哇！」這好有歷史意義。
十年，這是個什麼概念呢？感覺是說短不短，但說長的話，也是稍不注意就一晃眼過去的時間。2013 年好像是我剛考上研究所的那一年，那時候連自己未來的職涯都還沒有方向，也還沒進入 Web 領域。但當年這些前輩們就已經在這個領域耕耘，甚至這次也聽到 Orange 大大說他 2013 年上台分享的時候才大二，真是令人佩服！十年後的今天已經有許多卓越的貢獻，並且是公司的資深資安研究員。
這次坐在台下的我就在思考，十年前我還在混沌當中，那十年後我是什麼呢？雖然我很難想像我十年後會是什麼，但我覺得，如果十年後我還是跟現在差不多，那絕對不會是我自己期待的樣子，所以今天也想特別留下一點記錄，一方面不要忘記自己這次得到的收穫，另一方面也不斷提醒自己，努力不要成為十年後想起當年會後悔的模樣。
議程
這次的講者陣容真的非常的強大，如果可以的話每一場真的都想去聽。但可惜自己還沒學會影分身之術，而且這次主辦單位考量到講者們覺得如果沒有錄影，可以更暢所欲言，所以活動沒有錄影。
因此在這次選擇要去聽哪一場的時候真的非常糾結，雖然幾乎每一場我都非常想要去聽，但也只能乖乖的排課表。以下記錄一下「預計」的課表，雖然我大部分都是按照課表去走，但有時考慮到場次之間休息只有 10 分鐘，一下要跑十樓，一下要跑十一樓，場次轉換的時候也怕自己沒有位置，所以有些就沒有照課表了。
主題心得
主題：活用 GitHub Copilot 開發 Web 應用程式
講者：Will保哥
簡報：https://drive.google.com/file/d/1W7KZ2vwsZyyIC_iMdCxgadXWodWkrU6u/view
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2FT5tQ48y8S5GQkAUx9qlgng
今年 Copilot 正夯，我們公司也是看好未來 AI 的發展，如果員工願意透過使用 ChatGPT 或 Copilot 等 AI 工具，幫助員工提升工作品質及效率，也是支持員工勇於嘗試新工具，也有考慮願意補助這個項目。
也由於公司有表達這個意願，所以我也大膽開始使用 Copilot 在撰寫程式上。因此這次我也是很期待這個主題，畢竟自己對於這個工具還不是很熟練，只是用到一點皮毛。
這次也是我第一次聽保哥現場演講，對我而言也是久仰大名。聽別人演講，除了內容值得學習之外，怎麼演講也是值得學習的一環，這次真的令我大開眼界🤣。
畢竟 Copilot 也問世沒多久，所以看得出來保哥也是還在摸索這個工具，讓我彷彿看到一名老練的牛仔正在馴服這匹桀驁不馴的野馬或是野牛。選擇這個題目來演講也是需要相當的演講經驗和勇氣。這次也是有 Live Demo，當然，也逃不過 Live Demo 魔咒🤣🤣🤣。在家試就好好的，一上台就出乎意料，真不愧是生成式 AI。
如果是我的話，面對這種題目我絕對是不敢 Live Demo，我應該只敢先錄好影片當作投影片素材。但即使面對 Live Demo 魔咒，保哥還是不驚不慌，完全沒有影響他的氣勢和自信，台下大家也是覺得很有趣，畢竟人之常情唄。能夠 Live Demo 當然效果一定是很令人震撼，雖然也有很多漏氣的時候，但瑕不掩瑜。一個經驗豐富的演講者的功力就是在這種時候展現出來，我只能給個讚👍。這種危機處理和臨危不亂的態度也是值得令人學習。
這次演講大概就是分幾個 Copilot 的優缺點來講，然後也鼓勵大家勇於嘗試，分享一下到目前為止的使用經驗和心得這樣。雖然沒有什麼高深的內容，但說到底講者也是一名實踐家、技術探險家。我覺得這也是蠻令人值得效仿的，想要走在時代的尖端就是要勇於去嘗試這些新事物、新工具。他各種 Copilot 相關的工具也都去用用看，使用完之後也清楚的整理出各個面向。所以雖然大家都一起關注和面對這個新的 AI 工具，有些人能夠成為先驅者並掌握他，有些人只能當跟隨者，我想差別就是在這裡吧。
主題：AI 驅動下的開發者體驗
講者：Ruddy老師
簡報：https://1drv.ms/f/s!AtlpfGB0RrJolasV8HV8C470Vwy6yA?e=tpZUiA
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2FTz4XDh74SqGDDZiGcWBaKg
Ruddy 老師這一堂課給我們許多啟發，在 AI 的驅動之下，我們該怎麼去面臨這些改變所帶來的影響？
開發者體驗(Developer Experience)是我過去沒有仔細想過的事情。身為一個工程師，我們平常的工作就是致力去改善使用者體驗，努力排除使用者在操作上的抱怨和困難。
將開發者視為 End user，將工作過程的技術協作與團隊協作看做產品與服務，關注 Developer 開發中的感知與反應，致力消除產品與服務所帶來的摩擦
但在 AI 的驅動之下，開發者體驗確實受到相當大的影響。從今年開始的開發方式將與過往完全不同，我們有 AI 的輔助。但這樣的輔助是助力還是阻力呢？雖然 Copilot 會給予各種提示，非常方便，但尚未熟練開發工具操作時，這些提示反而容易打斷工作流程和開發者的思緒。
至於是助力還是阻力，說到底也是取決於工程師本身。Ruddy 老師這麼說：「專案開始之初，要先看到全貌」。如果你腦袋空空就來寫程式，只想看看 AI 的提示會給你什麼，被 AI 拎著鼻子走，那這也將會是一種阻力，阻擋我們學習、阻擋我們進步。所以「看見全貌最好的方法就是提問」。透過對自己的提問，將這個全貌在腦中建構出來之後，那 AI 將會成為你開發的助力。這真的是非常深刻的一席話。所以，回到那個老問題，AI 到底會不會取代開發者？透過這席話的思考，這個答案將會變得清晰。一個理想的生產力工具要能協助開發者處理掉雜事，讓用戶(指的是開發者)專注在任務上，而不是一直去打斷開發者的思緒和專注度。
「面對 AI，我們應該以學習為中心，而非以獲取知識為中心」。創新的過程 是模仿->轉換->合併。知識吸收再多，沒有化成具體行為、發生改變的話，這叫做囤積知識，沒用。
嬰兒通過模仿成人來學習; 藝術家通過模仿大師來學習; 程式員則透過 copy paste 來學習
最近 AI 出世之後，大家一直在討論「人類會不會被 AI 取代？」。其實我覺得應該換個問題來問，「你想要選擇被取代？還是選擇不被取代？」。面對 AI 生成式的結果，我們知道他是蒐集了全世界巨量的資訊的產出，但我們使用 AI 到目前為止，我們知道這些生成式的結果不一定都是對的。那我們有沒有能力去判斷這些知識的對錯呢？還是我們只是選擇一味的接受？懶得去思考這些事情的人，我想就是選擇被取代的那一方。
最後一個提醒是，我們在某個領域的能力越低，就越可能高估自己的能力。「懂得越少的人，越容易自以為是，而忽略了學習。」因此這邊帶我們思考，「AI 在無知上面能夠做什麼？」。最大的敵人不是無知，而是認識不到無知本身。換句話說就是「不知道自己不知道」，所以自我察覺很重要。當然我們可以透過 AI 的趨勢預測來減少我們對未來的無知，透過對 AI 提問來減少無知，AI 也能幫助工程師發現他們可能未曾意識到的問題和挑戰，並提供解決方案。但回到那句老話，面對 AI 帶給我們的知識的同時，也要對這些部分進行評估和批判，讓自己的思考和意見越來越成熟
主題：WebComponent 的好，用過的都知道
講者：奶綠茶
簡報：https://speakerdeck.com/milkmidi/webcomponent
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2FqY9O-dlVTgWWUbrgsYdf4w
奶綠幫我們回顧一下十年前那些當紅的技術，以及在這十年當中他們是怎麼死的。反思我們現在用的這些當紅的技術，在未來的十年當中是否還能夠存活下來？
這真的是一個很可怕卻也很現實的問題不是嗎？在技術日月異的時代，我們很難對某個技術孤注一擲，並相信他能夠養我們到終老、退休。何況現在老年化社會的加速，加上醫學的進步，退休的年限勢必會再往後延。而且今年 AI 快速崛起，又更快的加速這種技術的迭代。現在大家都在擔心「中年失業」，我相信不久的將來，「老年失業」這個名詞和這種擔心也會逐漸出現，並取代「養老」這個概念。
總之，基於這種擔心的前提，我們必須要提前做些準備，例如學習某個十年後最可能不會被消失的技術。奶綠他下的賭住就是「WebComponent」。
所以主旨就是講一下為何他做出這個選擇？WebComponent 的優勢在哪裡？例如他是一種新的瀏覽器底層 API，意味著我們不用像目前三大框架那樣需要引入函式庫才有辦法被使用。然後他也能有效的解決全域污染、耦合性的問題。當然也有相對應的缺點，和他提出的解決方案。
對我而言的收穫就是，WebComponent 好像蠻值得投資去探索看看(讀書清單又多了一個項目了😅)。當然，除了 WebComponent 之外，基於前面那個思考，應該也要時時關注技術變化的趨勢，真的是要活到老、學到老。最後講者也給了一個提醒：
學習不需要為公司、長官或同事
不需要為別人，只需要為自己
主題：成為前端建築師吧！透過 Frontend Infra 為前端應用打造穩健且高效率的開發體驗
講者：莫力全 Kyle Mo(老莫)
文章：https://oldmo860617.medium.com/成為前端建築師吧-透過-frontend-infra-為前端應用打造穩健且高效率的開發體驗-21566b5c95d3
投影片：https://slides.com/oldmo860617/minimal
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2FcPQikssETpSBS33EgKkQKw
這是我第二次聽老莫演講(第一次在 Dcard)。
老莫也是我很敬佩的開發者之一，透過他的 IG 可以感受到他對知識的掌握非常快速和非常有熱忱，內容也都很有深度，常常也會有比較深刻的反思。
這次的題目著重在他擅長的 Frontend Infra 領域。介紹了什麼是 Frontend Infra？以及 Frontend Infra 解決了什麼問題？
其中有一個最有趣和最核心的部分是他對 Frontend Infra 的使用時機提出了質疑，「只有大規模組織適用 Frontend Infra 嗎？」「如果是小專案或小團隊，還能導入 Frontend Infra 嗎？」。這個問題讓我的眼睛為之一亮，因為畢竟不是每一個人都有機會進入較為有規模的組織。特別是在台灣的軟體環境，鼓勵大家創新及創業，因此絕大部分的公司還是中小型企業，也很多是新創軟體公司。
Frontend Infra 這個詞通常被用來描述為了提升「開發效率」和「產品品質」而導入的一套系統、流程或工具，並且常常包括一些關於如何使用這些工具和系統的最佳實踐或標準。
重點就在於「開發效率」與「產品質量」這兩個要素，老莫認為只要符合這兩個規範，任何嘗試都可以被算在 Frontend Infra 的範疇裡。
老莫也從過往舉自己過往在小專案當中導入 Frontend Infra 的親身實踐案例給我們當參考。我覺得這樣的分享真的非常有幫助，他讓我看見在小型專案中使用 Frontend Infra 的可行性，並且有跡可尋。
如果架構設計脫離了實際業務需求，那就是在瞎忙。調整軟體架構必須深入理解需求，參與需求討論，並透徹理解需求背後的業務本質。
最後還是要提醒我們，核心並不是要我們無腦導入 Frontend Infra，如果專案沒有這方面的需求，只是一味追求很潮很酷，好像你沒有 Frontend Infra 很弱，若陷入這種迷思就急著導入的話，真的比起得到好處，更多的是增加維護成本和成為團隊的負擔。
主題：建立高效的遠端協作團隊：策略和實踐
講者：劉艾霖(Ailin Liou)
簡報：https://docs.google.com/presentation/d/1bNjm5viq2tBsw4u9kFcX5zlL0B6BymFctU8IeqyW4NM/edit
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2F0ay5VmSyQf25vtI8rvRfLA
Ailin 也是我很期待的講者之一，因為我也有加入遠距工作者在台灣 (work remotely in Taiwan)這個 FB 社團(目前1.8萬人)。
我自己也是對於遠距工作很想嘗試也很嚮往。畢竟人也是有嚮往自由的天性。
我每次只要想到我每天要在辦公室要待滿 8 個小時，不斷的產出程式碼，我就覺得自己就像雞舍裡面的雞一樣🐔，每天就是關在那狹小的籠子裡面，不斷的吃飼料和下蛋🥚🥚🥚。
想到這裡就會覺得自己還蠻悲哀的，這是我小時候最不希望自己長大之後變成的樣子，但是沒想到我還是沒有逃離這種命運。這時候就會開始思考自己剩餘的人生以及其意義。就算有人告訴你應該要透過公司做社會貢獻和把自我成長當成自己的目標，還是沒有辦法改變我們嚮往自由的渴望。
如果有一隻雞厭倦了待在籠子裡面下蛋，然後你試著告訴他一些成功學，讓他調整心態，教他調整吃飼料的節奏和姿勢，給他聽莫札特的音樂，教他運動的方法，成為一隻健康強壯的雞，下出品質更好的蛋，也提升下蛋的效率，這樣對這個雞舍和對雞的身心靈都有好處。你會不會覺得這樣的事情非常荒唐？你會去取笑這隻雞嗎？這隻懶惰、不守本分和整天愛做白日夢的雞？可是把主角從雞換成是人的話，你卻會覺得這是很合理的。
以上是我個人的抒發，跟此次演講無關🤣。
遠端工作也不完全只有好沒有壞，我們常常去嚮往這些好處，但卻很少去思考這些壞處，因為有些東西真的是沒有遇過就很難去想像居然還有這種情境。
Ailin 這次的分享我覺得真的很務實，雖然遠端工作有一些缺點和難題，可是這些難題並不是完全沒有解決方案，而是你願不願意想方法去解決這些問題。疫情期間許多公司實施遠端，但疫情一結束，就收回來了。其實真的非常的可惜，其中有許多的理由是因為那些遠端工作的缺點和壞處，但這些公司大多沒有努力嘗試去解決這些問題，反而是更偏好回到原本的舒適圈。我們都知道找理由是無法解決問題的，但為什麼這種處理問題的態度卻不用在面對遠端遇到困難的時候呢？我個人是覺得還蠻雙標的。
遠端工作真的需要公司和員工雙方的努力才有辦法達成。當你克服這些困難的時候，相對應的你就能得到他所帶來的好處。我過往的工作經驗通常是一週有一兩天能夠在家遠端就很不錯了，沒有待過完全遠端的公司。所以這次聽 Ailin 分享也覺得特別有收穫，也打開了眼界。
遠端工作他很彈性，但也不代表他沒有規範。如果沒有基本的共識，會沒有效率，所以還是要有基本的準則存在。透過這些規則，因著遠端所帶來的問題也有可能被解決。例如休假也有休假的準則，有超過兩個小時聯繫不上，就須要請假，畢竟自己的彈性和自由不能影響到工作的進度、影響到其他人。另外在人與人之間的交流也是如此，雖然遠端無法實體見面，好像就失去了一轉頭就能跟同事聊天的優勢，或是可以亂入人家會議室來獲取資訊的優勢，但其實遠端還是有方法可以刻意製造虛擬的茶水間環境、刻意製造透明度，讓這樣的優勢能夠在線上繼續保持下去。
在實行遠端的公司也有許多要注意的地方，有些公司一週遠端幾天，在這種前提下，很容易帶著「過兩天就要見面了，比起花時間寫文件，不如到時候見面講一講比較快」的這個想法，而忽略寫文件的重要性。或者，有些公司會把難得的實體見面機會拿去開會，在 Ailin 看來這些都很可惜，應該要珍惜實體見面機會，遠距就可以做的事不要拿到實體做。我覺得這也是我過去很少去思考過的情境。
最後提到的一點我也很認同，就是要選擇正確的學習對象。例如有些公司收回遠端政策的理由是，因為 Google 也都採取這樣的策略了，他們一定有嚴謹的考量，所以我們應該效法這些知名國際大廠。但事實上，這是一個誤區，我們應該要學習和效仿的，不是那些雖然知名，但不太擅長遠端工作的公司。有些公司打從娘胎開始就是以遠端工作文化起家，他們有完善和良好的制度，也在這方面有豐富的經驗，並不是因為有些國際大廠，因為他的知名度和影響力，就覺得他什麼都是對的，什麼都要效仿他們。
當然，高層的心態對於遠端的政策成功與否也是有重大的影響。而公司的文化與商業策略，也與這個政策息息相關。
主題：那些理所當然，卻像空氣般重要的小事：談開發流程、程式架構與職涯發展
講者：PJ (陳柏融)
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2FGmg_L6YOT-yMko_qZ_pEeg
這個主題原本看的時候有點不太知道是什麼意思，但聽完演講之後再回來看這個主題，就會有一種「這說得實在是太好了」的感覺。
那些理所當然，卻像空氣般重要的小事？到底是什麼事？
我認為這是一位經驗豐富的工程師對於平常被視為理所當然的事情的反思。這樣的思考真的相當的深刻。
當它變成習慣的時候，你就忘了它是個麻煩
這句話貫穿了這個主題的脈絡與核心。這讓我想起以前在看信誓蛋蛋荒野求生的時候，原本我們在文明社會，享受文明社會帶來的方便及美好，這些東西成為我們生活中的一部分，你並沒有覺得他有什麼了不起，並沒有特別珍惜。但是當你只帶了一支小刀就單槍匹馬要在一片荒野叢林裡面求生的時候，原來以前那些習以為常的事情都是一種享受。
所以，什麼是奢侈？在一做荒島上面想喝一口淡水？晚上睡覺能夠不被蚊蟲叮咬？能夠有一個遮風避雨的地方？能夠吃上一口煮熟且有調味的肉？原本在文明社會很微不足道的事情，在此時都成為一種奢侈。
我們進入一個強大的團隊的時候，所有的 Frontend Infra、CI/CD stage 都幫你建好，有完整的開發流程、測試、制度、Eslint 設定、Jira card 下 Label 等等，你完全不需要擔心，只需要專注在開發上面就可以。
但今天如果環境不是如此呢？你就會覺得，怎麼這個也沒有？那個也沒有？這些不是很基本嗎？這些想法就會冒出來。這時候你前面就會出現兩條路，一條路是持續的抱怨，一條路是想辦法去解決他。
PJ 也告訴我們一個很重要的觀念，「你也是團隊的一份子，不要被角色侷限住」。DevOps 相關的建置，一定要由 DevOps 工程師來做嗎？這流程的東西不就是 PM 要處理的，關我什麼事？但如果我們自己放下這些想法上的侷限，或許團隊就會因為我們的付出而變得更好。
你可以不用是做的人，但要能說出來你要的是什麼
這個觀念是，雖然很多事情我們可以主動去做，但或許也不是每一件事情我們都有辦法親自去解決。舉例來說，可能我們曾經用過某個自動化的功能覺得很棒，但現在的團隊裡面沒有，雖然你不知道那是怎麼做的，但或許你可以去找相關專業的同事來討論，這件事情就會在你「說出來你要的是什麼」之後順利被解決，這也是對團隊的正面幫助。
主題：從專業到商業：十年軟體架構變遷
講者：Ant(曾義峰)
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2F00roPb7NQKOEHNoFGT6hig
思維孤島
專業與商業？哪個好？兩個都很好。但是在解決問題的討論的時候，通常會發現這兩種人的思維不太一樣。如果我們只保持自己本身專業上的思維的時候，有時候很難把別人的想法放到我們這邊。如果這樣的思維存在的時候，我們也很難把這樣的想法影響別人，讓別人接納。商業的人可能會覺得專業的人很死腦筋，專業的人會覺得商業的人死愛錢、畫大餅。但並不是說誰好誰不好，而是應該要去瞭解彼此思維上的不同。彼此多一些瞭解，世界也會多一些美好。
十年
假如你是個面試官，今天來面試的一位是現在的你，一位是十年後的你，你會選用哪一個人？
這真的是大哉問，假設今年我們是 24 歲，十年後是 34 歲。34 歲的我們可能已經開始有一些人生規劃，例如結婚、生子、買車買房，因此你對薪資也有更多的期待。但在 24~34 這時年當中，我們多累積了哪些東西？這些東西有沒有辦法讓我們去跟 24 歲的自己拼薪水？透過這樣的想像，讓面試者有辦法站在面試官的角度去思考和一起討論，到底這間公司的文化與求職者有沒有匹配。
十年的期間真的會有很大的轉變，許多公司的興起以及衰落，許多技術的興起以及衰落。回歸到自己身上，瞭解到自己在做什麼也是很重要的，你做的事情的價值是什麼？你做的這個服務，他服務多少人？這些人有沒有得到幸福跟快樂？人生成就感上面也是，我到底退休之後要跟我的孫子講什麼？所以價值體現是很重要的。那我要如何體現我的價值？我要去瞭解我的客戶，不論是開發、維運、資安等等，到底我工作的價值在哪？我為多少人創造了幸福？
聽完 Ant 大大的一席話，真的深刻的感受到前輩功力的深厚，以及對於整個專業和商業思維的瞭解和融會貫通。說實在的，像自己這麼渺小又沒有經驗的人雖然知道前輩講的很有道理，但卻也因為經驗不足所以有點難完全體會。希望今天前輩的一席話，能夠讓十年後的我也能站在更高的高度來看見整體的樣貌，希望那時候更能體會這些話以及背後的想法。
主題：從共憤走向共創：如何拉齊工程師與設計師心中的「品質標準」
講者：Kat (王蓁妮)
簡報：https://www.canva.com/design/DAFoe-vbrqQ/p1xmRii8Ze-0BgUSoY3IDw/view#1
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2FdiYoNrNbQQW0BLLQOm6DeA
就像是 Ant 大大講的那樣，商業與專業兩種人必須要互相理解，才有辦法共創美好。Kat 也是討論同類型的主題，工程師與設計師之間，應該要如何才能夠互相理解、互相溝通，才能夠一起共創高品質的產品？
第一個關鍵是「說共同的語言」。我覺得 Kat 舉的例子真的很生活化也很有趣。「設計師到底要不要學程式語言？」這個問題類比成「我去日本旅遊要不要學日文？」就算你完全不會日文，也能去旅遊，只是可能會產生不少溝通障礙。但如果你學了幾句基本的日文，不只可以讓你旅行得更順利，也能快速拉近跟當地人的距離。反過來，如果有一個外國人來台灣旅遊，跟你問路的時候講中文或講台語，我相信那一定是個令人感到美好的經驗，也能夠拉近彼此的距離。
「設計師常常問：這個做得到嗎？」這個問題真的是工程師和設計師合作時一定會經歷的對話。以工程師自豪的專業來說，要他說出「做不到」真的是太傷自尊心了，不太有人會這麼說。事實上，其實也是這樣，論可行性的話，其實不要太新奇或離奇的規格都可以實現。但其實問題常常不在於他的可行性，而是在乎實現這種東西的時間成本，以及後續維運的考量。
通常對設計師而言，當工程師開始解釋工程的複雜度以及維運上的困難時，就會開始聽不懂和放空，他只想聽到「可以」或「不可以」。說實在話，其實也能夠體諒這種心態，要設計師理解這種東西真的太強人所難了，畢竟工程複雜度和維運的困難對於設計師來說並無法深刻的感受。因為對設計師來說，設計出來的東西能夠被實現是最重要的。
但對工程師來說往往不是這樣，我們學過軟體工程，有許多專業上的考量是設計師和 PM 無法深刻體會和理解的。他們不想聽你廢話解釋那麼多，反正再怎麼困難也是你工程師要想辦法去解決的，你跟我講再多我也幫不了你，我能夠做的就是給你時間，然後三不五時問你好了沒？所以，如果彼此無法把彼此在意的東西放在心上的時候，這樣的合作就會容易破裂。
我記得我經手的專案上面有一些命名問題，有一個名詞，他在與客戶對談的稱呼、和前端的命名、後端的命名、以及使用跨團隊共用元件的命名都不同，但其實是同一個東西，這對工程師來說非常的糟糕，我們很希望這些命名都能夠統一，藉此來避免溝通上的誤解，以及避免未來對於程式碼的誤判。但為了改這個命名，會動到許多專案之外，也需要其他團隊的配合。我們跟 PM 提過幾次這件事，但以他的立場而言，系統能夠穩定運作是最重要的，雖然他知道這件事情對工程師來說有點困擾，但可能他也感受不到這件事情的必要性以及對於工程師來說產生的痛點，對他而言就只是一個名稱上的不一致，並不影響系統的運作和使用，也不緊急，而且未來可能也有些不確定性，最後決策就是只能一直擺著。所以，對於同一件事情，因為立場不同，考量的角度也不同，所以在彼此心中重要的程度也會不同。
另一個常遇到的是關於元件的共用。設計師也知道不要重複造輪子這句話，所以他也希望改一個元件樣式的時候，其他所有看起來「長得像」的元件都應該要同步被修改，所以只要有一個地方他覺得應該要被改的沒改到，可能就會覺得你工程師沒有共用元件，程式碼寫得不好。
另一方面，很多設計師也希望元件能夠保持有彈性，因為有些地方他想要客製化。但事實上，共用跟保持彈性，是兩個互相拉扯的端點，對於程式比較沒有概念的設計師來說很難去掌握這件事情，只能從視覺上面憑感覺，而且「長得像」並不絕對代表他有辦法共用。你想想看，馬桶跟洗手台是不是長得很像？都是一個盆子的形狀，裡面可以裝水，也可以把裡面的水排掉，而且都常常會被一起放在廁所，他有什麼不能被共用的理由嗎？牙刷跟馬桶刷也都是一根把子配上刷子，都是用來清潔的，是不是也很適合共用？難道你會這樣想嗎？
而且要做到「有彈性」這件事情是必需要事先規劃的，所以後來才被設計出來的元件要跟原本既有的元件共用又保持客製化的彈性，很容易就破壞原本程式設計的結構，那如果你要在不打掉他的前提之下共用他，很可能他就是疊床架屋的起點。這也常是工程師和設計師彼此溝通上困難的地方。
除了設計師如果願意學一點程式語言和邏輯這件事情很棒之外，工程師也應該要是著去理解美感和商業思維。我也常常聽到工程師說「真搞不懂差那 1px 是有什麼差，連這樣都要開 bug，浪費時間」。在顏色方面也是如此，設計師就是要在 hover 的時候有這個色號，但工程師可能貪圖方便就讓 hover 的時候加上一個透明度就了事，反正他覺得只要顏色有變化，看得出來是 hover 就好。我覺得這都是沒有尊重彼此在意的事情的一種體現。對設計師而言，視覺的呈現就是他的職責，差 1px 就是有差。換作是工程師，JS 在結尾有時候有分號有時候沒分號，你會覺得沒差嗎？反正使用者也看不到，程式也會動，你覺得這種理由合適嗎？不然幹嘛要設定 Eslint rules？所以我覺得真的是要將心比心。
第二個關鍵是「設定共同目標」。Kat 提到一個很重要的點，要對齊彼此想法的目標來做事，而不是只是指令式的要求對方。
如果你想造一艘船，不要號召工人收集木頭，發號施令，分配工作。
反而要教導他們，對一望無際的大海心生嚮往。–《小王子》
舉的例子是請工程師把圖片調大一點。如果彼此想法沒有對齊，就只是會覺得對方在對自己發號施令，這種對話的感覺會讓彼此感到不舒服，那當然也就無法順利合作。所以透過更多的說明和對話來對齊彼此的想法和目標，例「如把圖片調大是為了提升餐點購買率，如果餐點圖片太小，就難以讓消費者看得清楚餐點細節，影響購買意願」。這時，工程師在執行任務時，他做的工作就不只是調整圖片，而是變成幫助提升購買意願。這也呼應到 Ant 大大講的，這能夠讓工程師體現他自己在做這分工作的價值。
主題：鳳 ‧ 極意？！
講者：Paul Li
簡報：https://blog.lalacube.com/mei/Reveal_phoenix_the_gokui.php?page=1
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2FSVsZ1haXR-2bUhfcf_OYnA
我只能說，感謝 Paul 大大的分享，這場分享在技術上面真的受益良多。算是我在 WebConf 這兩天當中，覺得最值得的演講其中之一。
但因為技術的部分佔大多數，就不做特別的舉例了。心得就是，原來原生的 form 和 form element 能夠幫我們做到那麼多事，讓我們更體會他的美好優良之處，在這個分享面前，就是覺得自己非常的渺小，整個被洗禮了一番，哈哈。不過也因為如此，更得到了想要前進的動力。
主題：從零打造前端效能監控系統
講者：Summer
文章：https://www.cythilya.tw/2023/08/12/build-front-end-performance-monitoring-mechanism-from-scratch-webconf-tw-2023
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2FCZTO4WGbRcuCcQfWgGkuig
相信前端效能是大家都很感興趣的話題。這次會議室安排在相對小間的會議室，但看來主辦單位是錯估了 Summer 大大的人氣，直接整個大爆滿，現場座無虛席，場面非常的壯觀。
這次 Summer 大大為大家帶來的這個題目非常實務，希望能夠打造一個：
- 可以檢測大量資料
- 自動檢測每一個 build
- 有點預知能力，能提早發現問題
- 方法足夠簡單、容易實作
的效能監測系統。
相信上面這幾個點都有打中大家的痛點。
並且這次 Summer 大大也從自己的專案當中實現這個效能監測系統的做法，也很佛心的提供了 repo。直接展示了這個方法的可行性以及他驚人的效果。令人覺得非常印象深刻。
我覺得從這個系統設計的思維當中，也能夠看出一位資深工程師他專業的態度。以我自己的專案來說，通常我都是等到人家告訴我這裡效能不好，需要改善，我們才會去追查問題，然後針對問題來解決。
但是 Summer 大大的思維是完全不同的，他希望在讓使用者發現有問題之前就先把這個效能問題發掘出來並且解決，使用者不會知道他的貢獻以及在這系統背後所花的心思，使用者只會單純覺得這個好用的系統很理所當然。
身為工程師，我們真的非常敬佩這樣的精神和思維。透過這場演講，我們除了瞭解如何快速使用現成的工具建置一個效能監測系統之外，我們也看見一個資深工程師細膩的思維，我覺得值得令人學習也敬佩。
主題：從 2013 到 2023: Web Security 十年之進化與趨勢!
講者：Orange Tsai
文章：http://blog.orange.tw/2023/08/2023-webconf-the-evolution-of-web-security.html
Security 是我最近很想接觸的領域之一，當然也是我最不擅長的領域之一。
這次四大主題是架構、底層、不一致、跨應用，當然還有隱藏的第五大主題是前端安全。Orange 從這幾個主題當中舉幾個攻擊的手法以及例子，說實在的，真的令人目瞪口呆。有一種就算我全身穿滿了衣服，但在資安專家面前還是會覺得一絲不掛的感覺。原來我們的網站這麼容易就能夠被人家完全遠端控制，就好像在跑自家廚房和廁所一樣容易。
十年了，Web 在資安領域真的進步了嗎？
雖然各個框架都有基本的防範，但攻擊手法也是日新月異，就好像流水一樣，只要有一點點漏洞就能夠鑽過去攻擊。隨著架構變成複雜，新的架構組合也變成新的攻擊手法。
唯一的心得就是，永遠不要覺得自己很安全。然後，比起恐慌，更應該去瞭解和關注這些資安的最新資訊和攻擊手法，雖然很難做到百分百，但至少努力過了，不要擺爛。就算我有機會被你攻擊，我也要讓你想破腦袋才有辦法攻擊我。
主題：酷！玩！啥鬼CSS！
講者：Amos(李建杭)
共筆：https://hackmd.io/@webconf/BkImQ0Ds3/%2F-mWY8npJSIaaxLrYaQ0Nvg
我也是從開始參加鐵人賽之後就有開始關注 Amos 老師。今天終於有機會聽到本人實體的演講！最殘念的就是今天忘記帶老師出版的兩本書來給老師簽名，我兩本書都有的說……😭。
這次的演講也真的很有老師的風格。一開始就先聊聊他最近在玩釣魚的事情🤣。其實我覺得這也是蠻有意思的，雖然我不太懂釣魚，也沒有什麼釣魚經驗，但我很喜歡看那些釣魚的人的 Youtube，像是鵝大人的那個釣魚頻道。不知道為什麼一看下去就會很著迷🤣。還有我也喜歡看萍哥，哈哈哈！
明朝張岱有句名言：「人無癖不可與交，以其無深情也。人無疵不可與交，以其無真氣也。」意思是說一個人，沒點嗜好，此人無深情；沒有缺點，此人太虛假。我覺得真的是這樣，一個人如果沒有什麼嗜好，一輩子就是按照世俗定義的那樣按部就班過日子，對於工作賺錢汲汲營營，卻沒有自己的嗜好和生活，覺得那些都是浪費時間，那生活真的是非常的無趣。但或許對那些人來說，度過這種生活就是他的嗜好也說不定吧！所以或許我也應該改變我的想法，換個角度來看這些事情。
回到正題，Amos 老師這次也跟我們炫耀他做過的專案，或者說是瘋狂事蹟！？他說想要挑戰「用最少的 HTML 產出畫面效果」，然後做出一些你沒辦法相信居然是純用 HTML & CSS 做出來的作品，看他沾沾自喜的模樣我也覺得很有趣。雖然在世俗的眼光中那只是普通的 CSS，實務上好像也並不是很有用，面試也不會考，但是在這種事情上面玩到極致的話也是能夠成為專家！這個是我很佩服 Amos 老師的地方，也是一種童心未泯。我想起我小時候很沉迷於玩 Windows 小畫家，把他當作 Photoshop 來玩，把自己喜歡的卡通、動漫角色一個 pixel 一個 pixel 在那邊用橡皮擦慢慢去背，搞了一整個禮拜就是為了讓自己有一張看起來與眾不同的桌面畫面，洛克人X各代裝甲和傑洛大戰黃金音速小子之類的🤣，我覺得那種心情大概就是這樣吧！沒有什麼實際的用處，但是做出來就覺得很爽！我們長大之後，是否還有事情是能夠讓我們保留這種童心？這也是值得我反思的地方。
最後 Amos 老師也提到 2023 年那些值得被關注的 CSS 屬性，例如利用邏輯屬性隨著語言書寫方向來適應性調整 style，還有三角函數、父層選取器、內容查詢等等，幫我們整理這些部分我覺得非常的用心！也很有收穫！
雖然時間有限，但透過這些精要的提點也能幫助自己找到能夠去關注和研究的項目。最後就是下次一定要記得帶書來給老師簽名🤣。
結語
這次能夠參與 2023 WebConf 真的非常值得，也非常過癮。身而為人，如果想要進步的話，就是需要常常這樣被洗禮一番。
這次大家都在回顧這十年來的轉變，也因著今年 AI 技術的突破和 ChatGPT 的問世，未來的十年更是難以令人預測。要怎麼樣在未來的十年當中，利用 AI 發展的當代優勢，能夠創造更美好更嶄新的未來，相信是我們這時刻所要面臨的課題。
這次也非常感謝各位前輩和大神的無私分享，這些分享給了我們許多的反思和啟發，能夠有這樣的社群活動，讓彼此能夠交流，彼此刺激，未來台灣軟體一定會越來越耀眼。
希望從今天起成為一個自己的里程碑，在未來的十年當中，也能夠有嶄新的突破，能夠找到屬於自己的領域！
Ref:
- [HackMD] WebConf Taiwan 2023 共筆文件
- [Youtube] 2023 WebConf Taiwan 準備好了！
- 活動網址
