ExplainThis 全端開發雙週報 #50
資深工程師開會時該提什麼問題?
嗨～ 歡迎閱讀第 50 期的 ExplainThis 全端雙週報。一轉眼雙週報就來到了第 50 期，很高興與讀者們在過去的 50 期一同成長，未來我們也會持續透過雙週報，分享主題內容以及每雙週推薦閱讀的連結。
在進到這期的主題文之前，想分享 ExplainThis 在下週預計會上架《給工程師的 Cursor 工作流 — 透過 AI 代理全方位提升開發生產力》線上課程，希望透過這門課與讀者們分享如何透過 AI 代理，在工程師的工作各面向上，提高生產力與效率。
雖然這門課是以 Cursor 做為主要工具，但課程中講到的概念，都適用其他 AI 驅動的工具 (例如 Windsurf 或 GitHub Copilot)。感興趣的讀者，可以加入 E+ 成長計畫 (連結)。
以上，讓我們進到這期的雙週報主題文吧～
資深工程師開會時該提什麼問題?
先前我們在《工程師在專案不同階段，必問的核心問題》一文中討論了在專案中、面對產品時工程師可以提什麼問題，以及如何透過這些提問來提升自己的思考力。
在這一期雙週報，我們會進一步來討論，當在會議時，可以進一步提哪些問題，讓會議能夠開得有效。
雖然多數工程師偏好實作大於開會，但是一定規模的軟體開發需要靠團隊合作完成，因此會議有時會成為必要之惡。面對這個避不了的存在，最有效的面對方式就是善用它，讓會議所佔據的時間，能夠發揮最大價值。
在會議前
很多團隊往往低估會議的成本，找了很多人進會議，但不是每個人真的都需要。假如一個會議一小時，裡頭有五個沒必要在的人，等於每開一次會就浪費五小時的開發時間，一週要是有三場這類的會議，就浪費十五小時；當團隊越來越大，不去反思與檢視這種狀況，會導致越來越多浪費。身為資深工程師，保護團隊成員不用參加冗余的會議，會很重要。
因此在會議前，推薦可以問以下問題來檢視
期望透過這個會議來達到什麼？會議的目的是否清楚?
會議要討論的議題，真的那麼重要嗎?
我們真的需要開這個會嗎? 有沒有替代方案 (例如用非同步形式討論) ?
每個參與者真的都需要在會議中嗎? 為什麼? 參與者有沒有其他更重要的事情必須做?
假如發起會議的人沒辦法清楚回答當中的其中一個問題，身為資深工程師就該讓對方知道，團隊中的工程師應該把時間花在其他更重要的事情上。
在會議中
身為資深工程師，需要確保會議室有效進行。畢竟會議如果沒有效，那就等於大量浪費了所有參與會議的人的時間。
要評估會議是否有效進行，可以思考以下問題：
討論是否沒有被少數人佔據? 參與的人是否都有機會表達其觀點?
討論是否有效被推進? 還是只是在繞圈子沒有推進?
討論是否有清楚的結論、後續的行動方案?
這些問題通常不會直接問出來，而會是在腦中思考與評估；在評估時，如果這些問題有任何一個是否定的，那就要適時介入。舉例來說，假如會議中一直是某個工程師在發言，把其他人的話都搶走，這時就可以跳出來，主動去問說「其他人怎麼看呢? 是否同意 XXX 剛剛提出的觀點呢?」來介入，確保其他人都可以有效發聲。
會議結束前
在會議結束前，身為資深工程師需要確保會議該有的結論都有獲得，避免大家花那麼多時間參與，結果什麼結果都沒有。
在一般的會議結束前可以問：
會議最開始設定的目標有達到嗎?
有沒有什麼遺留沒討論到的內容，是後續要再持續追蹤的?
有討論到的內容，是否有明確的待辦事項、要完成的時程，以及相對應的負責人?
在產品相關的會議結束前，推薦可以問：
這個會議是否有產出具體且明確的規格、選擇該規格的原因?
關於規格的設計與實作，是否有明確的時程?
有明確的負責人去跟不同的利害關係人 (例如跟上下游團隊) 溝通嗎?
如果上面提到的點，在會議結束前並沒有做到，身為資深工程師，在這個時候務必要跳出來。舉例來說，假如有沒有討論到的內容，在會議結束前可以說「我發現原本有排定要討論的 xxx 並沒有被討論到，也許我們可以拉另一個會議來討論這件事」。
閱讀更多
關於如何有效開會，以及關於成為資深工程師要培養的其他軟實力，我們在 E+ 成長計畫都有更多、更深入的主題文，推薦有興趣的讀者加入閱讀 (連結)。
本期推薦
過去兩週 AI 界有很多重大更新，OpenAI 的 4o 的圖像模型 (連結)、OpenAI 支援 MCP (連結)、Gemini 2.5 推出(連結)。順道一提，這次 Gemini 的更新比起之前 2.0 版本，非常有感回答變好不少
微軟的 Playwright 也推出了官方的 MCP，可以透過 Playwright MCP，搭配 Claude 或 Cursor 等工具，就能夠直接自動化爬蟲、寫 E2E 測試等任務 (連結)
AI 時代究竟該不該學程式? 目前社群中有兩極的觀點，史丹佛大學電腦科學教授 吳恩達的觀點是仍應該繼續學程式(連結)。有趣的是吳恩達教授跟抱持不用學程式的 Replit 合作推出一門免費的 Vibe Coding 課程 (連結)，這個趨勢值得繼續觀察下去
非同步程式，是許多初學程式的人很常搞不清楚的概念，而在實務上同步與非同步程式無法混用的狀況，導致許多套件會同時提供
sync與async的 API。在《Async, Sync, in Between》 一文中，作者提出了一個可以同時混用的Quansync，寫得非常精彩(連結)Liveblock 做了一個開源的表情符號選擇器，對相關元件如何時感興趣的讀者，推薦可看逛逛該專案的程式碼 (連結)
先前有讀者問到「想在工作上爭取使用不同的技術，獨自推進有困難，想瞭解看看在爭取（或說服）的方式、推薦的心態等等」。要在團隊中推動新技術、爭取改變，並不是一件容易的事，但也不會完全不可能《如何有效在團隊導入新技術、新工具?》探討了這個議題 (連結)
許多人會把加入新創公司作為職涯考量，最近讀到 Linear 創辦人寫的《The profitable startup》 一文，談到新創公司是否實現獲利，是非常重要的指標。對於想加入新創公司的讀者，非常推薦一讀 (連結)
文末彩蛋
感謝讀到文末的你，這邊分享前陣子讀到一句很有感的話。是 Bryan Johnson 分享的建議，他提到 FOMO 是種幻覺，與其花時間去擔心，不如把手機關掉，讓自己沈浸在一本書、一次對話，或一場遊戲中。
由於現代資訊科技發達，FOMO 比過往更容易無聲無息地侵蝕自己，但假如能抽離用更客觀、長期的角度看，確實沒有必要用那些幻想出的擔心自我內耗。
當然，這說的容易做得難，而我們覺得最有效的方式之一，是如 Bryan 提到的，在絕多數的時候，把手機關掉、少滑社群媒體，把時間花在那些深度有意義的內容上。
Turn your phone off. Lose yourself in a book, conversation or game. You’ll feel rejuvenated. The feeling of missing out is an illusion and a trick being played on you.
— Bryan Johnson