我剛從度假回來，像 99% 的波蘭人一樣，我是在克羅埃西亞度過的。Dobar dan! 🇭🇷
我腦中現在有一篇真的很有趣的文章，但在發表之前還需要做一些研究，所以會在下週推出。這段時間，我們先來聊點比較輕鬆的。
順帶一提，稍微更新一下。 我說 FrontKon 會是我今年最後一場研討會……結果看來我說謊了。😂 當 iJS Munich 找上門時，你就是沒辦法拒絕。尤其是在看過講者陣容之後。基本上那是一場充滿天才的研討會……外加我。😅 所以我會在 10 月底那裡分享 React 中的 WebAssembly 與 WebGPU ，而且我已經興奮到不行了。
如果你剛好口袋裡有一袋多到沒地方放的鈔票 xDDD（或者更現實一點，你們公司剛好還有教育訓練預算），歡迎來打聲招呼！我很期待能親自見到你們中的一些人。😊
總之……我們回到今天的主題。
如同很多人可能知道的，我對 LinkedIn 上那些「大師」以及那種對所有事情都講得信心滿滿的人特別有興趣。你應該懂那種類型：他們的解法永遠是最好的，其他人都錯，而且完全沒有任何取捨。😄
有時候我會覺得，這種自信至少有一部分根本就是直接來自某支 15 分鐘的 YouTube 教學。
不過我們公平一點來說。誰沒看過一支短影片，結束時心想：「對，我完全懂了！」，然後在實作的時候才發現現實……稍微複雜一點？😂
因為我最近大多都在做 JavaScript 和 AI agents，所以大部分例子大概也會來自這些領域。歡迎大家在留言區補充你自己的例子！
1. React / Angular / Vue（把多餘的那個劃掉）是最好的框架
這大概是看完網路上的大師影片後最常見的觀點，尤其是當你自己還沒有形成判斷的時候。
Angular 最好，因為它什麼都有。React 最好，因為大家都在用。Vue 最好，因為……嗯……Vue 的人會告訴你原因。😄
然後你花了幾年做真實專案之後，突然發現這三個都有各自的優點、缺點和適用場景。最後所謂「最好的框架」，通常只是那個最能解決你的問題的框架。
2. LLM 只是自動補完
或者，如果你比較喜歡另一種常見說法：
「它們只是隨機鸚鵡。」
「它們沒有創造力。」
「它們其實什麼都不懂。」
好吧……如果事情真有這麼簡單，那為什麼一整群研究人員和工程師要花好幾年研究它們？為什麼各家公司要燒掉價值數十億美元的 GPU？😄
另一個總是讓我會心一笑的說法是：LLM「沒有創造力」。沒錯，它們大概不會憑空發明某個與人類已知一切完全脫節的東西。
但話說回來……大多數人也不會。
大部分人不會在某個早晨醒來後就發明量子力學，或寫出《魔戒》。創造力通常是把既有概念以有趣的方式重新組合，而 LLM 在這方面其實意外地很強。
3. CQRS（或前端的 Redux）很簡單
當然。然後你一打開程式碼庫，瞬間就像在看一部架構版的恐怖片。
老實說，我什麼都看過。商業邏輯被拆散放在 Redux store 和元件裡。半數狀態全域管理，另一半又在本地管理。Actions 裡面竟然還藏著商業邏輯。Reducers 不知道為什麼突然決定要變成服務。
幾年前，當我比較常面試工程師時，我會問一個很簡單的問題：「我們為什麼 वास्तव上需要 CQRS（或 Redux）？」（順帶一提……並不是每個人都知道這兩者的差別。）接著我會再問一句：「為什麼我們不能用更簡單的方法解決？」
我發誓，出乎意料地多人會這樣回答：
「我不知道……大家本來就是這樣做的。」
4. AI agents 只是個 while 迴圈
公平地說！我的一位好友，也是我以前的技術主管，真的有一場很棒的研討會演講，標題就叫這個。這本來就是故意要挑釁的。
而且我們也得面對事實……這句話其實有不少道理。很多 AI agents 確實就只是「一個 while 迴圈」。
有趣的部分大概是三個星期後才開始。突然之間，你那個小小的 while 迴圈裡有了三個 MCP 伺服器、一個協調框架、重試機制、記憶、工具呼叫等等等等……
但這仍然是我最近做過最有趣的事情之一。
5. WebAssembly 永遠比較快
每次有人這麼說，我都會問同樣的兩個問題：比什麼快？以及在做什麼事情時比較快？
別誤會，WebAssembly 很棒。在很多情境下，它的效能確實能把 JavaScript 打爆，尤其是你在處理運算密集型演算法、模擬或類似工作負載的時候。
但如果你的應用程式大多時間都在等 HTTP 請求完成……WebAssembly 大概不會讓網路變快。
它也不太可能突然把你的儀表板變成 NASA 軟體。😄
6. 單元測試就是我們的金券
尤其是那些由同一個剛剛產生正式程式碼的 LLM 產生的測試。😂 100% 的信心！
或者……也許不是。
這在前端尤其容易誤導，因為單元測試往往只是在驗證那些一開始就最容易寫出來的程式碼。
恭喜你，你成功達成了 100% 測試覆蓋率，以及 0% 的信心！
7. 我們直接加 RAG 吧
對啊……
好像找資料、清理資料、維護資料，以及選出正確文件，才是最簡單的部分一樣。😄
8. 微服務 / 微前端 是唯一好的架構
絕對沒錯！尤其是當你的應用程式只有六個畫面和一個後端服務的時候。😄 或者當你其實有一個健康、而且全團隊都看得懂的單體架構時。
有時候，分散式架構正是你需要的。
有時候，它只是分散式的複雜度。
我大概還可以再舉二十個例子，但我想今天就先到這裡。😂
你呢？你有沒有遇過那種「看過一支 YouTube 影片就自稱大師」的人？
如果你喜歡這篇文章，也歡迎在 LinkedIn 上追蹤我： https://www.linkedin.com/in/sylwia-laskowska-5a8467131/
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
