ExplainThis 全端開發雙週報 #9
做 To B 與 To C 的前端開發有什麼不同、從蛋糕店的例子學習軟體系統設計 (中)、找工程師工作該選新創或大公司
[前端工程] 做 To B 與 To C 的前端開發有什麼不同?
前端工程是一個很廣泛的名詞，很可能都是做前端工程師，但你的工作內容跟另一個人完全不同。雖然都是前端開發，產品開發、多媒體開發、設計系統、前端架構，這幾個類別會有非常不同的工作內容。進一步說，光是做產品開發的前端，To C 的產品與 To B 的產品，就有很不同的側重點。讓我們在這一期聊聊他們的區別。
先來談 To C 跟 To B 是什麼，所謂的 To C 是指 To Consumer (對消費者)，而 To B 則是 To Business (對企業)。一般你直接在網路上免費或付費使用的軟體，多半屬於 To C 範疇；而做給企業使用，或是通過企業採購的軟體，多半是 To B 的範疇。
當然這定義沒有很絕對，因為有些產品同時是做給 To C 與 To B，或是某個產品有 To C 的面向，同時又有 To B 的面向。舉個常見的例子，以電商來說，一般人會逛的亞馬遜 (Amazon) 或樂天 (Rakuten)，都是 To C 的面向；然而亞馬遜跟樂天都有配合的商家，商家要上架、管理商品資訊的頁面則會是 To B 的面向。
To C 的產品特性是使用者量大、邏輯不複雜。以電商來說，龍頭電商都是上億使用者規模，同時面對使用者那端的都要盡力求做的簡單易用，不然使用者就容易不繼續用。在這樣的特性下，To C 的前端會相對更重視效能，因為加載多一秒，都是代表極大量的使用者流失。同時 To C 更強調使用者體驗，例如對於不同螢幕尺寸的 RWD 要求、對於各類瀏覽器兼容的要求。上億使用者的產品，即使只有 1% 也是百萬人。
接著來說 To B，這類產品的特性是，量級小、邏輯複雜。以電商來說，上億使用者的電商，可能裡頭的商家僅有數十萬，規模量極差幾百倍。但是不同類型的商家，往往會有不同的需求，導致在產品設計上，To B 產品邏輯會變比較複雜。因此 To B 產品相對更重視程式碼的可維護性。這不代表 To C 的產品就不重視可維護性。主要是當商業邏輯相對沒那麼複雜時，前端程式碼不要寫太爛，基本上都不會太難維護。
總的來說，同樣是以產品開發導向的前端工程師，選擇 To B 與 To C 會有很不一樣的職涯體驗。選了自己比較不喜歡的，可能會做得痛苦。舉例來說，之前有認識在保險科技 (InsurTech) 公司任職的朋友，負責 To B 的保險產品，曾說過在工作上要學一堆保險相關知識與名詞，才能確保功能寫得正確，因為對保險沒興趣，搞那些商業邏輯讓自己很痛苦。後來他換工作去做 To C 的產品，著重在他更喜歡的使用體驗上，工作起來更加愉快許多。
希望這個簡單的分野，能讓大家更清楚不同的前端職涯。當然，必須再次強調，這是比較概略性的劃分。在選擇要接受哪一份 offer 時，還是需要更詳細打聽職缺實際的內容，才能選到對自己更理想的工作。
[系統設計] 從蛋糕店的例子，輕鬆學習軟體系統設計 (中)
在上一期的雙週報，我們用蛋糕店作為舉例，來談軟體系統設計。上週談到，蛋糕店要從一個人單打獨鬥，進而擴展到一間能接更多訂單的大店，需要招聘更多的人，並且有負責管理這些人的機制，來確保招聘進來的人不會太操也不會太閒。對比到軟體系統設計上，當要把系統擴展來承載更高的流量，我們可以用更多的伺服器，並透過平衡負載器來分配流量。
然而，要規模化蛋糕店的事業，還有很多面向要顧及。舉例來說，假如要把服務的客人從原本在某個縣市，拓展到全國，就會遇到一些問題。有些蛋糕店是不開分店，堅持要由本店製作再外送到全國各地，但是這會導致在比較遠的客人，總是需要等很久才能收到訂購的蛋糕。要解決這問題，可以在各地開分店，先把中央工廠做好的蛋糕送到分店，這樣客人要訂購時，就近把蛋糕送給在當地的客人。在系統設計上，(cache) 也是扮演相似的角色，在客戶端要拿資料時，就近跟快取拿，而不用跟資料庫拿，就能加快響應時間。
當蛋糕店生意越做越好，可能會想要多角化服務，像是許多蛋糕店現在也會同時賣飲料。而飲料是要現點現做的，當現場客人多的時候，就會遇到客人要等的狀況。但在做手搖飲的現場通常混亂，要如何有效分派哪個工讀生泡哪杯飲料呢? 很簡單，現在許多手搖飲店，會依照客人點飲料的順序，把要製作飲料的單號按照先來後到的順序貼在成一排，先貼的單號會先被有空擋的工讀生拿下來開始製作。只要該工讀生一泡完手上那杯，就再去拿目前最前面的待做飲料。
在系統設計中，隊列 (queue) 的機制，也是類似的方式。所謂的隊列是先進先出，就像飲料店的做，先點的客人的單子會先被處理。在隊列的機制下，就可以有效讓多個 workers 去處理在隊列中的任務，先放到隊列的任務先被處理。而處理完手邊任務的 worker，就去處理目前在隊列中最前面的那個任務。透過隊列的機制，讓管理工讀生們變得輕鬆許多。
在導入了許多機制後，蛋糕店運作相當順利。然而很多時候意外是不可預知的，例如某個地區的店突然遇到店面被閃電打到，以至於電力系統出問題沒辦法正常營業。這時來店的客人就會撲空買不到蛋糕。總店為了解決這問題，導入一個即時監控與通報機制，當某間店有意外出現時，趕緊調派人手到現場把客人引導去鄰近分店，讓客人還是能就近買到蛋糕。在軟體系統中，也會需要有觀測 (observability) 平台，來做即時記錄 (logging)，以及指標 (metrics) 監控，還有警報 (alarm) 發出，確保系統的整體穩定度，不會因為單一個服務掛掉而導致客戶端請求沒辦法被處理。
有了監控報警系統，蛋糕店創始人對於整個品牌的穩定度感到放心許多，似乎可以好好退居幕後了。當然事情沒那麼簡單，身為蛋糕店經營者，在運營蛋糕店時有非常多決策考量。在下一期雙週報，我們將繼續用蛋糕店的例子，進一步從決策者的角度，來談在真實世界的系統設計，有哪些重要的考量點。
[軟體業職涯] 找工程師工作的萬年問題，該選新創或大公司?
上週看到一個推文 (詳見此)，是在講幾年前，有一張賈伯斯當年在 NeXT 時發出的 offer，並在該 offer 最下面寫的簽名處上方寫了「我接受這個超棒的工作機會！！！ 」。當初收到這個工作機會的人是 David Nagy，那時的他並沒有接受這個工作機會。
而根據估算，如果當時他有接受這個工作機會，並且把拿到的選擇權都存著一路放到今天，那些選擇權會值超過一億美元 (因為後來 NeXT 被蘋果收購，賈伯斯重返蘋果，這個估算是基於那時的收購價與蘋果股價計算)。換句話說，從今天的角度看，當年這個工作機會，是待遇高達一億美元的工作。這是新創公司獨有的潛力。基本上在大公司，股價能翻倍已經不容易，但在新創公司，種子輪到上市可能估值成長上萬倍，原本五千元的期權能長成五千萬的價值。因此很多人會說，David Nagy 沒有接受該工作，真是虧大了。
不只是 NeXT，加入對的新創公司很可能讓人賺到當上班族一輩子也賺不到的財富 (前提是有拿股票，沒發股票的新創都是無良的，千萬不要去)。舉例來說，先前有個 28 歲從字節跳動退休的工程師，在社群掀起很大的討論，他在字節跳動那六年，公司估值翻了超過千倍，他拿的五十萬期權直接變五億。
假如你是 David Nagy，你會接受賈伯斯提供的這個超棒工作機會嗎? David Nagy 曾在他的 LinkedIn 上發文回應說，他其實沒有很後悔。雖然沒有接受那個後來變成一億美元的工作機會，David 職涯的路上仍是很精彩，一步步往上爬的他，後來陸續在多家科技公司擔任到副總的職務。
更重要地是，他說他在原本的工作中，做得很愉快。當年的賈伯斯出名難相處，他不認為自己在那個環境下能夠愉快地工作。這是職涯選擇中很重要的一環，在選擇工作時，不該只看財務上的報酬，而是該全方位的考量，包含自己是否能做的快樂、有成就感、工作與生活平衡。因此，回到「新創與大公司」這個職涯選擇上，沒有絕對的哪個比較好，即使錯過某個超棒的工作機會，也不代表你選擇的不是個好職涯。
本期推薦
哈佛大學 CS50 課程正式推出 AI 程式家教 CS50 ddb，以「引導思考」的方式教你如何解決某個程式問題，而非直接讓 AI 告訴你答案。這個 AI 程式家教不只能解決你修 CS50 遇到的問題，基本上各類程式問題都可以。現在全世界最頂尖的教育機構，做出一個你能隨時隨地問問題的程式家教，大家真的沒理由說程式學不好了 [連結]
現代的前端專案動輒會有十來個 config 檔案，例如 tsconfig、eslintrc、Dockerfile 等等，這是因為 Node.js 設計的緣故。Deno 是 Node.js 創作者打造的新 JavaScript 執行環境。在《Node.js's Config Hell Problem》一文中，Deno 團隊分享 Deno 如何重新設計來解決這問題。
Google Chrome 的 DX 負責人，也是十年前寫了那本有名的《JavaScript Design Patterns》的作者 Addy Osimani，最近推出了一本集結他在 Google 十年經驗的《Software Engineering - The Soft Parts》。這本書是專注在軟體工程師應該具備的軟實力，推薦給想在軟體工程師職涯持續往上爬的人。電子書連結可以在這篇文章看到 [連結]
最近在社群看到，學術專長為演算法的吳邦一教授，退休後開始撰寫 《Python-LeetCode 581》。對於要入門學演算法的人，非常推薦這系列。吳教授用風趣的文筆，介紹了解 LeetCode 時常見的思路與技巧，非常感謝他無私的分享。
閉包 (Closure) 一直是讓許多人感到困惑的程式語言概念。如果用的好，有很多好處 (見此)，但是用不好也容易出現預料外的 bug。《Fantastic closures and how to find them in React》一文詳細頗析在 React 中常出現的閉包，如果你對閉包概念不熟，非常推薦讀這篇。
比起 Meta 或 TikTok 這類更重產品的公司，Google 一直以來是以工程要求度高聞名。其中一個差別是，在程式碼審查 (Code Review) 時，會有專門看「可讀性 Read」的人。 Google 的資深工程師 Brian Kihoon Lee 寫的《Readability: Google's Temple to Engineering Excellence》介紹了這個讓 Google 工程品質維持高水準的制度。與此同時，他不認為所有公司都該按照 Google 的作法，並提出了他認為可行的替代方案
最新一屆 Vite Conf 將在 10 月初舉行，Vite 幾乎是現在前端界最熱門的建構工具之一，真的非常期待這次的各個講座。這次 Vite Conf 線上是可以免費參加的，大家快去報名吧 [連結]。假如你不知道 Vite 是做什麼的，可參考先前我們寫的摘要文 [連結]。
🎉《ChatGPT 指令大全與創新應用》電子書上市
最後，假如你有興趣全面性了解 ChatGPT，並且學習如何實作基於 ChatGPT 的應用程式，千萬不要錯過了 《ChatGPT 指令大全與創新應用》目前電子書也全面上市，之前有私訊詢問電子書的朋友，千萬別錯過了 (博客來購買連結在此) 😊