[{"data":1,"prerenderedAt":263},["ShallowReactive",2],{"essays-\u002Fessays\u002Flazy-and-opportunistic":3},{"id":4,"title":5,"body":6,"date":251,"description":252,"draft":253,"extension":254,"meta":255,"navigation":256,"path":257,"seo":258,"stem":259,"tags":260,"__hash__":262},"essays\u002Fessays\u002Flazy-and-opportunistic.md","我懶，所以我投機取巧",{"type":7,"value":8,"toc":244},"minimark",[9,13,25,28,31,34,37,42,45,50,61,67,73,77,80,83,86,89,92,95,98,101,104,107,123,126,143,146,149,155,161,167,170,173,176,180,183,186,189,192,195,198,201,204,207,210,213,216,219,222,225,228,231,234,237,240],[10,11,12],"p",{},"某次在YT上刷到的脫口秀裡聽到一個段子（請恕我真想不起出處是哪了）：「三思而後行」，在暗諷職場的甩鍋文化。",[14,15,16,19,22],"blockquote",{},[10,17,18],{},"一思：能不能不做？",[10,20,21],{},"再思：能不能晚點做？",[10,23,24],{},"三思：能不能讓別人做？",[10,26,27],{},"台下笑成一片。",[10,29,30],{},"我也笑了，而且笑得有點心虛，因為畢竟誰都想當薪水小偷。",[10,32,33],{},"後來經歷的一些事，沉澱反思後，我忽然意識到這是一個最高級的行動準則！",[10,35,36],{},"我懶，我投機取巧，我大方承認且理直氣壯，因為我很清楚一件事：時間是最貴的成本，花掉了就拿不回來。",[38,39,41],"h2",{"id":40},"一笑聲背後的機會成本","一、笑聲背後的機會成本",[10,43,44],{},"脫口秀好笑，是因為它戳中了大家心照不宣的偷懶念頭。但現實是，組織裡那個有求必應、什麼都接的「好人」，才可能是整個團隊效率不彰的老鼠屎。\n而且他還很冤的要扛著做到流汗，嫌到流瀾的罵名，甚至主管可能完全沒有意識到這是最可怕的經費黑洞（加班費）。",[14,46,47],{},[10,48,49],{},"一起把段子裡的調侃剝開，剩下的是資源分配和邊界管理哲學。",[10,51,52,56,57,60],{},[53,54,55],"strong",{},"一思：能不能不做：先審需求。","\n很多臨時起意的事，或是客戶看到新功能的想法發散，有時只要冷靜問一句： ",[53,58,59],{},"「不做會怎樣？它真的解決了什麼問題？」"," 多半就自己消失了。不懂得拒絕的人，不是比較負責，而是沒把自己有限的時間當成成本。在他的帳本上，時間是免費的，所以什麼都可以接。可是時間偏偏是最貴的那一項。\n工程師的時間，就是寶貴的產能。",[10,62,63,66],{},[53,64,65],{},"再思：能不能晚點做：讓時間幫你過濾。","\n不少被包裝成十萬火急的需求，其實只是需求方當下的焦慮，或是還沒想清楚的半成品。第一時間衝上去做，很可能陪著對方改了好幾版，最後全部推翻。晚一點回應，讓子彈飛一會兒，是成本最低的過濾方式。\n工程師們開發功能很像急診室，講求的是檢傷分類，不是先來後到，或是誰比較大聲（當然在工程師這邊可以用錢插隊....急診不行）",[10,68,69,72],{},[53,70,71],{},"三思：能不能讓別人做：找到最適合的人或工具。","\n什麼都自己來，產出的上限就是一天的工時。把工作交給更適合的工具、流程或夥伴才能提高團隊效率，或是你要叫它甩鍋也行，我不爭辯。重點是，鍋甩給更適合的人，整體的成本就降下來了。\n用對的人與工具，才會是最有效率的辦法。",[38,74,76],{"id":75},"二實際經歷懶出來的架構","二、實際經歷：懶出來的架構",[10,78,79],{},"從心虛到理直氣壯，我自己就經歷過一次。",[10,81,82],{},"我負責的是遊戲後台的報告畫面。需求很簡單：根據後端傳來的資料，用捲動的方式產生列表。每個遊戲是一個產品，各有自己的後端。",[10,84,85],{},"一開始走的是最直覺的一對一：一個產品一個前端站，前端直接把後端的位置寫死在程式裡。我意識到這樣做會碰到幾個問題：",[10,87,88],{},"第一是跨域，瀏覽器擋下前端打到另一個網域的請求，得處理 CORS。（前端一定都撞過這個從前端是無解的問題）",[10,90,91],{},"第二是後端的位置直接寫在前端，誰打開瀏覽器的開發者工具都看得到。（等著被 DDoS）",[10,93,94],{},"第三是後端一動，前端就得跟著動（甚至有的時候我根本不知道後端改了，還需要定期去「輪詢」確認後端位置）。維運有時候會改網域，我就得改程式、重新部署。而且一個產品不只一套環境，DEV、SIT、UAT、PROD 各有各的後端位置，改一次就是改好幾份。(工讀生等級的維護...沒啥技術含量，但就是需要花時間做手工藝，還容易出錯)",[10,96,97],{},"我是真的懶得處理跨域，因為這是瀏覽器限制，有些後端根本不知道這是啥玩意，所以我根據我不務正業時學到的Nginx知識，請維運幫我做反向代理（關公面前耍大刀...當下很抖）。前端只打同一個網域的路徑，由 NGINX 轉給後端。跨域的問題沒了，後端的位置藏起來了，維運要換網域，也是他改他的設定，前端完全不用動。",[10,99,100],{},"本來只是為了偷懶，後來我卻忽然意識到：既然轉發是由反向代理路由決定的，那一個前端，不就可以根據路由接 N 個後端嗎？",[10,102,103],{},"於是我換了做法。報告畫面根據網址判斷現在是哪個產品，動態組出對應的 API 路由，反向代理再依路由轉發到該產品的後端。",[10,105,106],{},"從此要新增一個產品時：",[108,109,110,117],"ul",{},[111,112,113,116],"li",{},[53,114,115],{},"維運","：在反向代理加一行，指到新的後端。連那個後端的位置，都是維運自己配的",[111,118,119,122],{},[53,120,121],{},"前端","：不用架新站，也不用重新部署，只要把新產品要用的圖片放上去",[10,124,125],{},"在 NGINX 裡，大概就是多這麼一行（示意）：",[127,128,133],"pre",{"className":129,"code":130,"language":131,"meta":132,"style":132},"language-nginx shiki shiki-themes github-dark","location \u002Fapi\u002Fproduct-c\u002F { proxy_pass http:\u002F\u002F\u003C維運配的後端位置>\u002F; }\n","nginx","",[134,135,136],"code",{"__ignoreMap":132},[137,138,141],"span",{"class":139,"line":140},"line",1,[137,142,130],{},[10,144,145],{},"一開始請維運加設定時，我心裡其實有點過意不去：「明明是我這邊要支援新產品，怎麼變成維運要動手？我是不是把工作推給別人？」",[10,147,148],{},"後來我才發現，我根本沒有多推什麼給他，說不定還幫他省了事。",[10,150,151,154],{},[53,152,153],{},"第一，那一行本來就省不掉。","\n就算維持一對一，為了閃過跨域、藏起後端，每個站本來就需要反向代理，每個前端專案各有一份設定檔，各自寫著自己的後端在哪裡。每多一個產品，維運就要多顧一個站：申請網域、處理憑證、安排部署，一樣都少不了。解耦之後，這些設定集中到同一個專案裡，一個產品一行。網域、憑證、部署全部省掉，要查、要改也只看一個地方。維運的工作不但沒有變多，反而少了一大截，而且省下的都是實實在在的真金白銀與時間。",[10,156,157,160],{},[53,158,159],{},"第二，讓最適合的節點做最適合的事。","\n「哪個路由轉到哪個後端」本來就是反向代理的強項。放在 NGINX，改一行設定就生效。放在前端，就是改程式、打包、部署，每次都走完整的上線流程。",[10,162,163,166],{},[53,164,165],{},"第三，產品越多，省得越多。","\n我曾經認真想像過，如果一直維持一對一會變成什麼樣子：假如產品成長到十個（遊戲換個皮就算一個新產品，十個其實很快），每個產品要分 DEV、SIT、UAT、PROD 四套環境，就是四十份要維護的程式碼。維運改一次網域，我就要翻遍四十份，找出該改的地方，再一份一份重新部署。",[10,168,169],{},"只要是人做的，就一定會改錯、會漏改。差別只在於，是在測試環境被發現，還是上線之後才被使用者發現。",[10,171,172],{},"那是我能預想到的地獄。（我不要）",[10,174,175],{},"解耦之後，新增產品的成本被壓到兩件小事：維運在各環境的設定加一行，前端放幾張圖。產品再多，前端始終只有一份程式碼要顧，維運始終只有一份設定要管。",[38,177,179],{"id":178},"三do-smart-not-hard","三、Do smart, not hard",[10,181,182],{},"英文常說「Work smart, not hard」。但我更喜歡把 work 換成 do：「Do smart, not hard」。work 談的是工作的手段，do 談的是行動的選擇，先決定做什麼、不做什麼，再談怎麼做。",[10,184,185],{},"用力過猛的人，做事像一個單體架構：什麼都往自己身上堆，靠意志力硬扛所有流量。遇到問題，第一個念頭是「我要怎麼加班把它寫出來？」。累了，就告訴自己：「我很累，所以我很負責。」花掉的是一去不回的工時和精力。",[10,187,188],{},"做得聰明的人，做事像解耦之後的系統：先畫清楚邊界，再把負載分給最適合的節點。遇到問題，第一個念頭是「這件事一定要存在嗎？誰來做成本最低？」。做完了，他想的是：「這套流程跑順了，我隨時可以走開。」他花的力氣，最後變成可以重複使用的工具、架構和自動化。",[10,190,191],{},"這種懶，其實很早就有人替它說話。",[10,193,194],{},"網路上某個經理人流傳一句話：「我會選一個懶人去做困難的工作，因為他會找到最輕鬆的方法。」出處是誰不重要，這句話能流傳這麼廣，代表很多人都有同感。",[10,196,197],{},"軍事史上也有一個常被提起的分類：軍官可以分成聰明、愚蠢、勤奮、懶惰四種特質。又笨又勤快的最危險，因為他會不停製造錯誤。又聰明又勤快的，適合當幕僚。而最適合當最高統帥的，是又聰明又懶惰的人：他討厭窮忙，所以懂得放手，懂得抓重點。（不怕壞人千方百計，就怕蠢人靈機一動）",[10,199,200],{},"到了軟體工程，Perl 語言的作者賴瑞‧沃爾乾脆把「懶惰」列為程式設計師的三大美德之一：因為懶得重複做同一件事，所以會寫腳本、做工具、設計架構，讓系統自己跑。",[10,202,203],{},"把視野再拉遠一點，諾基亞有句廣告詞：「科技始終來自於人性。」我更願意說：科技始終來自於惰性。",[10,205,206],{},"人類的發明史，幾乎就是第三思的歷史：能不能讓別人做？只是這個「別人」，後來變成了機器。懶得走路，有了輪子、汽車、飛機。懶得手算，有了算盤，最後有了電腦。懶得洗衣服、掃地，有了洗衣機和掃地機器人。工程師懶得每次手動部署，於是有了 CI\u002FCD、Docker，還有我前面說的反向代理。",[10,208,209],{},"勤奮推動的是眼前的進度，懶推動的是做事方法的改變。如果每個人都甘願靠蠻力硬撐，我們大概到現在還在手抄帳本，反正「加班就抄得完」。",[10,211,212],{},"剛入行時，我是用力過猛的那種人（濫好人），總在想：「怎麼用我自己掌控的工具，把需求全部兜出來？」現在我比較常想的是：「這件事放在系統的哪個環節處理，整體的維護成本最低？」",[10,214,215],{},"Do smart 就是投機取巧。投機，是看準時機：什麼事現在不必做、什麼事可以等以及什麼事現在不做就會死。取巧，是挑最省力的做法：交給誰、用什麼工具或辦法。這四個字被用成貶義太久了，但拆開來看，講的正是做事最需要的判斷。（事分輕重緩急）",[10,217,218],{},"真正該怕的，是「用戰術上的勤奮，掩蓋戰略上的懶惰」：手上很忙，腦袋很懶，懶得想這件事該不該做、該誰來做。真正的推卸責任，是自己沒想清楚，就把混亂丟給下游。成熟的分工，是看清系統的全貌，設計出合理的介面和規範，讓每個環節在最擅長的位置運轉。",[38,220,221],{"id":221},"再三思",[10,223,224],{},"所以，下次再聽到那個段子，不妨認真把三思再想一遍。",[10,226,227],{},"一思，能不能不做？砍掉的假需求，就是省下的專注力。",[10,229,230],{},"再思，能不能晚點做？讓時間先替你過濾一輪雜訊，手上有沒有更重要的事需要先解決。",[10,232,233],{},"三思，能不能讓別人做？讓維運加那一行，讓 NGINX 轉那個請求，讓機器跑那些重複的事。",[10,235,236],{},"懶人的三思，一次都不能少：每一思，省下的都是往後無數次的重複勞動（還有時間，時間就是金錢）。",[10,238,239],{},"懶就是懶，投機取巧就是投機取巧，不必換個好聽的名字。我只是比較早想通：時間最貴，所以每一分鐘都要花在只有我能做、而且真正值得做的事情上。其他的，能不做就不做，能晚點就晚點，能讓別人做就讓別人做！",[241,242,243],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":132,"searchDepth":245,"depth":245,"links":246},2,[247,248,249,250],{"id":40,"depth":245,"text":41},{"id":75,"depth":245,"text":76},{"id":178,"depth":245,"text":179},{"id":221,"depth":245,"text":221},"2026-10-22","聽懂脫口秀的「三思」，才讀懂系統架構",false,"md",{},true,"\u002Fessays\u002Flazy-and-opportunistic",{"title":5,"description":252},"essays\u002Flazy-and-opportunistic",[261],"隨筆","pCqejfeno1hOSp4OAhCl-etvuIu6GBVpb4VKUu_0tC8",1793181520359]