資訊科技產業強調效能優化與團隊協作成為軟體開發新趨勢

當你以為每個產品都要服務百萬用戶時，其實十個人用的系統只需要一台伺服器

想像一下，某個大半夜，有人窩在家裡穿著睡衣，眼皮快要闔上了，卻還得盯著那些讓人頭昏腦脹的系統日誌。這應該不是少數工程師會遇到的情境。那時候也許腦中還飄過剛加入團隊的某位新進同事，她總讓人想起自己很久之前的模樣——熱血、有點衝動、覺得只要多寫幾行程式就能晉級成高手。

如果有機會回頭和那個當年的自己聊一聊，也許能省下不少彎路。不過更實際一點，倒是挺希望能和現在剛入行沒多久的人談談，那些市面上的教學課程、技術文章不太會提到的事。有些經驗嘛，大概只有在經歷過幾次小型災難、錯過一些時限，再加上將近十來次凌晨兩三點還醒著，才會慢慢體會出來。

嗯，要說什麼建議比較實用？有時候很難一次講完。好像也不用每句都太嚴肅，不如從一件常見的小事開始：不少初學者（有人可能連我以前也算）總以為，一套應用程式一開發就必須準備好應付大量使用者，好像哪天突然湧進數十倍預期的人潮。其實，現實往往沒這麼戲劇化，多半得先把小東西做好再說。

偶爾想到這些瑣碎又真切的體悟，就忍不住想隨手記下來，也許對某些剛啟程的人多少有點參考價值吧。

獨自開發很自由，直到團隊協作讓你明白CI/CD和測試有多重要

以前有段時間，常常花上一兩個禮拜，甚至更久吧，就只是為了幫那種差不多我媽跟幾個大學朋友在用的小應用程式搞一堆複雜的微服務。其實仔細想想，如果用戶不到十人，單台伺服器配個普通的REST API，大致上也就能混過去。

身邊見過不少專案，好像大家都很執著要把架構弄到極致，結果反而拖了半年，到頭來還沒碰到第一批將近一百名用戶。這情形偶爾會讓人聯想到，有些事情早點簡單處理說不定比較輕鬆。

但說也奇怪，一旦哪天流量突然竄高到一天有數千萬次請求（這種狀況可能不是每個人都碰得到），事情好像就開始變得很麻煩。深夜三點，你可能才剛學會什麼是負載平衡器，因為本來那台伺服器已經直接罷工。有時候又突然意識到，「自動擴展」原來不只是某種流行語，而是你能不能安穩睡覺的差別。這裡面關鍵倒不是一開始要懂多少，而是大概知道自己什麼時候該從基礎方案慢慢調整、往上升級。

話說回來，我記得第一份工作，那時幾乎就是獨立開發者一樣。很多流程可以跳過，比如自動化測試啊、持續整合什麼的，不做好像也沒誰管你。其實這些事等團隊規模起來後才真的重要——但小型專案，好像也不一定非得一板一眼照辦不可。有時候就是這樣吧，人少時偷懶一下，大部分問題都還撐得住，只是長遠來看會不會出狀況，也不好說啦。

Comparison Table:

結論	內容
命名規則的重要性	良好的命名規則能幫助團隊成員理解程式碼的用途，減少維護成本。
技術債的影響	隨著專案進展，未解決的技術債會導致後續開發變得複雜且困難。
透明化流程的必要性	建立可重複還原的開發環境，能降低錯誤發生率並提高團隊效率。
面對選擇與決策	工程師在資訊不完整時作出的選擇，往往影響專案長期成功與否。
持續學習與經驗交流	透過社群互動和經驗分享，可以加速個人成長並提升整體能力。

網站掛掉五分鐘沒關係？等電商黑五每秒都在燒錢時你就懂了

大概在剛開始寫程式的那陣子吧，反正如果哪裡壞掉了，心裡很有底，大概因為之前所有東西都是自己親手敲出來的。日子沒隔多久，就進了個開發團隊，成員加起來快十個人，大家幾乎天天都丟新東西進去，也不知道什麼時候一切就變得亂七八糟。有時候說不上來是誰先提到的，不過後來才知道什麼叫 CI/CD、測試層那些玩意，如果都不弄好，整個專案還真像拿積木疊高那種遊戲，每次要不要週五下午部署還會有人猶豫老半天。

功能旗標這類工具以前聽過但沒特別在意，一直到自己也碰上那種“明明只做好一半卻被放上線”的囧事（這樣的情況發生次數比想像中多），才有點明白為什麼要先學會怎麼收斂新功能。說起來，有些習慣當獨立工程師時看起來多此一舉，但換成團隊協作後，好像就變得不可或缺。整理自己的房間可以隨便丟東西，可跟其他人合租就不太一樣，那感覺差異挺大的。

時間再往後推一些，我記得剛開始其實對系統掛掉沒什麼特別感覺。偶爾網站某頁卡住或打不開？簡單搞個「目前發生技術問題」公告頂著，等有空再慢慢修。可等我轉到電商領域工作之後，一次黑色星期五活動讓我見識到什麼叫每分鐘損失相當於好幾千塊（光是估算下來也嚇一跳），才驚覺備援機制、健康檢查、優雅降級等等，其實不是書上講講而已——這些措施用不用直接關係到能不能繼續留在崗位，甚至還可能要向老闆解釋為何漏掉將近二十五萬的營收。

事情做到這裡，有人會認為每個項目都非得追求企業級穩定性，其實未必啦，只是在經歷過那些大大小小的事故之後，很難再對風險掉以輕心就是了。

用API很簡單，但設計給別人用的API就像簽了賣身契

系統一出狀況，最先崩掉的東西，其實常常跟你原本想的不太一樣。說真的，這種事情大概得碰過好幾回才慢慢抓得到訣竅。有時候光是在那邊猜是哪裡壞掉，就能讓人頭痛半天。

API啊，初學工程師大多是直接拿來用，這部分通常都還算輕鬆。發個請求、管一下像是四百多或五百多那類的錯誤代碼，大致上就差不多了。可是自己動手做給別人連接用，那感覺就完全不同——等於寫下某種協議，而且一旦釋出，好像之後幾年都要背著它走。有些細節以前根本沒注意，比如說版本要怎麼處理；還有文件怎麼寫，不至於讓人看到快要放棄人生那種程度。另外測試、監控也少不了，要是能在大家開始上網抱怨前先發現問題，就已經算不錯。曾經遇過一次狀況：因為沒留意接口變更的影響，搞到開發社群裡有好一陣子都有人在抱怨。只記得最後學會了一件事，就是跟外部溝通的界面，一但推出去，多半就很難再完全掌控。

談到效能優化這塊——蠻多人剛開始會覺得「速度越快越好」，其實情況比想像中複雜。有些內部系統，一兩個月才跑一次，但有人可能花上將近一週只為了把它加速零點零幾秒，說穿了有點像技術版拖延症。不過現場也見過不少例子，有些搜尋功能明明每個人天天用，可查詢結果卻要等上二三十秒，都沒人管。但如果遇到真的需要即時反應的場景，用戶盯著手機螢幕一直戳畫面，你就會發現性能問題突然間變成全部人的重心。

大致就是這樣啦，有些事直到親身經歷後才比較能體會——也不是什麼絕對規則，只是偶爾回想起來總覺得還挺值得記住的。

效能優化是種奢侈？當用戶開始流失時它就成了生存問題

有些人聽到什麼效能分析、快取策略、內容分發網路、資料庫優化，第一反應不見得是多開心，有時候甚至搞不清楚這些東西到底要幹嘛。不過話說回來，好像也不少用戶會因為系統速度慢吞吞，沒過多久就跑去別家了。這種情況下，優化這些細節似乎還算蠻重要的——但怎麼做？大概得先看自己是落在哪一種類型，再去針對性調整。

講到資料處理，一開始有人覺得只要隨手丟進類似雜湊表那種結構就完事，反正量少的時候，記憶體裝得下，也沒太多麻煩。結果等到數據量級突然飆升到好幾千G（反正就是很大），事情馬上變複雜，不再只是桌面抽屜裡翻東西那樣單純，而是有點像是在管理一間大型倉庫——空間、位置、搬運都要重新規劃。以前沒遇過的什麼索引設計啊、分區方式啊、硬碟讀寫模式等等，全都得慢慢摸索。

變數命名問題嘛……其實有點像有人在廚房弄了一堆碗盤沒洗，久了你會發現找個湯匙都累。

從HashMap到TB級資料庫，數據規模會逼你重新學一遍電腦科學

一個人住的時候，有些事其實只是有點煩，差不多像是桌上一直堆著幾張帳單那種感覺。可如果身邊還有室友，就會變成另一回事——可能會開始看到有人貼了好幾張便條紙，語氣裡帶著那麼點微妙的情緒。程式碼裡也常見類似狀況。有時候，一個叫「temp」的小東西，其實裝的是那些用戶付款資料；「doStuff」這種看起來啥都能做的函式，居然負責認證安全。偶爾自己寫完馬上回頭看，也許還能猜出當初在想什麼。不過只要多了幾個夥伴一起維護，那些不起眼的小亂象就慢慢浮現，好像誰都得被捲進來，沒人能置身事外。

但說到命名規則這件事，好像也不是光靠列出規則或硬性標準就能處理乾淨。有的人說，其實那更像是在替下個讀你程式碼的人留一點體貼的空間——而且很可能那個人就是半年後已經忘得差不多的自己。

從簡單的 console .log 開始，大部分工程師都是這樣摸索 bug 的。一週修一次錯誤、剛寫完的新功能失誤，很快便能找到原因。有時甚至覺得這種方法挺管用。不過當你負責的是給真實用戶服務的大系統，一切跟原本又不太一樣。事情變複雜了，人變多了，意外好像也變得比較容易發生。有些細節現在回頭想起來也許沒那麼清晰，有些工具可能聽過但還沒真的派上用場。總之，有時候，就是需要花點時間適應一下……

亂取變數名稱就像把髒碗盤留給室友，遲早會收到憤怒小紙條

有時候，事情總是這樣的，眼前的螢幕顯示著一堆分散的 console.log，像是拼圖缺了好幾塊。那個週末，好像花了兩天多點時間追查某個生產環境的小問題，只靠那些早就忘記誰寫的日誌訊息，一切東拼西湊。這種經驗，大概不少人都有過吧？後來才慢慢明白，如果沒有可以搜尋的結構化日誌、無法跨服務追蹤請求流向、遇到狀況時沒辦法即時收到警報通知——甚至連即時儀表板都不太看得懂現場情形，那只會讓自己陷入更深層的困惑。有些朋友說，他們也碰過類似狀況，通常都不是什麼好下場。

偶爾趕進度嘛，不少工程師應該都試過那種「先寫能動的再說」的程式。不過，其實要誠實面對自己的選擇才行。有些人會在代碼旁邊寫點備註，比如現在為什麼這樣湊合用，或者加一些 TODO 留給未來某個自己回頭檢查。大致上，也會標一下哪些地方只是權宜之計，不是真的設計思考出來。只是臨時方案如果拖太久沒改，最後可能就變成長期存在的小地雷。有聽說，有系統裡面的「暫時解決方案」撐了將近半個十年還在跑，每次改版都有人提心吊膽。

對於開發環境和部署現場，其實大家常講一句話：「反正在我電腦上是能跑啦。」這種感覺，差不多就像學生說：「老師我真的交作業了！」也許是真的，可惜對其他人沒什麼幫助。畢竟，再怎麼保證本機運作正常，也沒辦法替整體系統背書。一轉換環境，各種不可預測的小插曲就跟著冒出來。所以，還是得想點辦法讓流程透明一點，不然每次出事就只能原地打轉——大概就是這樣吧。

當console.log不管用時，你會懷念結構化日誌和分散式追蹤的好

有時候一個人自己寫程式，亂七八糟的開發環境也沒什麼大不了。可要是跟別人一起動手，那些能讓大家都用得上的、能重複還原的環境或組建流程，就變得挺重要。否則出現小問題也許不太容易察覺，某台電腦上才會冒出來，好像不同版本的函式庫偶爾就會搞怪。這種情況有人說碰過不少次——每次都得花掉好幾個晚上去追那種只有特定機器才會有的錯誤。於是後來，慢慢開始把設定開發環境當成工程裡不可忽略的一件事，不再只是想到才臨時處理。

技術債嘛，大概就是那回事——早期開發新東西，趕進度、隨便調整，其實效率未必差，有些團隊靠這樣嘗試才能快點找到用戶真正想要的是什麼。但很多人都有類似經驗，「以後」總是很快就到了。有些專案最後連加一個小功能，都得改動七八十個檔案；系統架構一開始設計比較隨意，隔了幾年，每逢維護或增修就相當頭痛。有的地方甚至沒人願意負責，因為太容易壞，也不知道哪天踩到地雷。技術債如果能提前解決自然最好，但一般都等到不得不面對才著手整理。

說穿了，軟體工程到底做什麼？有人說半輩子下來（可能將近二十年吧），才漸漸領悟這行業其實不是單純「建造東西」。更多時候是在資訊還不是很完整、狀況也還在摸索裡頭，不斷做選擇。不一定每一步都清楚，也難講哪條路完全正確，但大致方向總需要拿捏一下罷了。

'先求有再求好'的程式碼如果五年後還在跑，那根本是技術債高利貸

有時候，工程師會遇到那種明明很想動手做點什麼，可偏偏得忍住不去做。可能是因為現在不太需要，也可能只是純粹沒那個必要。刪掉寫得還算不錯的程式碼，好像也不是件罕見的事，只是因為它已經派不上用場。這些選擇並非總是基於完整數據——現實裡，決策往往是在資訊有點斷裂、分析並不齊全的情況下完成。

也有人說過，優秀的工程師好像都不是只追求速度。他們打造出來的系統，讓其他同事也能更放心地快速嘗試新東西。不僅僅自己能變快，身邊一圈人多少都受惠。當然啦，他們心裡其實還有條隱形界線：什麼時候該堅守原則，又什麼時候可以乾脆自己推翻舊規矩？這些建議聽起來頭頭是道，其實每條都有例外——能辨認那些特殊情境的人，大概就離資深工程師又近了一點。

有人記得自己剛入行時總以為多背點最佳實踐、多看幾個熱門框架就是成長。但後來發現，比起死背技術，更重要的是慢慢練出某種判斷力。不少問題值不值得花時間處理，其實說不上絕對標準；取捨之間，有時還真難說哪個比較好。有些「戰役」根本沒必要打下去。

大致上來說吧，不論經驗幾年，就算累積到二十多年，大家對未知多少還是會猶豫，只是有些人習慣了這種模糊感，也稍微懂得怎麼在猶豫中硬著頭皮做決定。至於那些所謂標準答案，看久了大概都只剩參考價值而已。

軟體工程的本質其實是在資訊不全的情況下持續做抉擇

有時候看到那些剛入行的工程師，感覺他們總是在混亂中摸索，其實這也挺正常。大概每個資深前輩走過來的時候，都經歷過一陣手忙腳亂，也許還踩過和你現在差不多的坑，甚至搞砸過類似的事情。只是那種錯誤會隨著年資變得……嗯，應該說是越來越有趣？好像每次都能學到點新東西吧。

如果你常用LinkedIn，可以隨手加個好友也沒什麼不好——畢竟圈子裡大家互通有無，有的人在某些領域特別擅長，有些則是慢慢累積經驗。所以，有空就交流一下囉。

對了，如果你碰巧是玩DevOps、時不時要處理系統問題的人，也許可以看看我放在GitHub上的一些資料。那裡面零零碎碎地收集了不少排查命令、腳本還有步驟說明，但其實內容大致也是自己平常記錄下來，用著順手而已。有興趣可以去翻翻，覺得還行的話給個星號支持也行，不過只是小小心意啦。

偶爾寫這些故事或技術筆記，其實挺花精力。如果有人讀完覺得還不錯、樂意請杯咖啡，就當作一種鼓勵吧——這樣我之後大概也比較有動力繼續寫下去。謝謝你看到這裡，嗯，大致就是這樣。