被 Code Review 打臉的日子：從訓練營到商業產品的現實落差
轉職不只打怪升等，更是「被怪打到痛」的真實洗禮——這篇記錄被怪打的心得
我的總體歷程大概是這樣：
功能可以動 → 可讀性問題 → 品質盲區，驗證不足 → 思路狹窄，只會找一個可行解 → 慢慢開始有自己的想法
這歷程裡的每一段，對我來說都不是自然而然突然會的，而是「刻意練習強制修正」。從訓練營出來也就 6 個月時間，仍然是趕鴨子上架，很多觀念只是了解表面而已。
真正進到商用產品真的還差了一大截，不可否認剛開始我對自己感覺良好，畢竟從訓練營畢業，能做出網頁而且可以 demo 我已經覺得自己很棒。但第一次 code review 之後就讓我面對現實了… 滿滿的 code review comment，讓我發現還有很多成長空間。想起來那段時間充滿壓力，每天不斷反思錯誤在哪，真的是胃痛啊啊啊啊啊啊。
Code Review 是照妖鏡：「以為懂了」，其實還沒懂？
曾經前輩對我提出這個問題，並且要求我理解問題的時候加入以下流程：
- 什麼是 XX？
- 為什麼有 ＸＸ？ ＸＸ 想解決什麼問題？ 什麼時候用到？
- 舉例說明使用方式？
我才開始思考，我之前的理解是真的會嗎？還是我只是囫圇吞棗把答案記下來就覺得自己會了？我想有人幫忙 code review 大概就是提供一面鏡子，幫自己反思。
以上漫畫內容擷取於「藍色時期」 14 集單行本，已購買正版漫畫。
但...這也只是我碰到的第一個問題而已。
良藥痛心：接受指導的真實感受
人家說良藥苦口，我覺得都還太淺，對我而言，這更像是良藥痛心。
遇到好的前輩能夠指導當然是福，而團隊也透過定期的 1-on-1 持續關心我的狀況，協助我釐清問題點。儘管如此，感激和痛苦卻是同時存在，要改變都是痛，面對自己缺點全都需要勇氣。
因為改變很慢，進步也很慢。當然學到東西時固然開心，但如果是自己覺得已經寫得很棒的時候呢？自己寫的東西會灌入自己的價值觀，並且，每次提交 PR 就像考試作答，希望自己是 100 分。這時候看到 comment，很難不覺得是在「被扣分」。我想這也是 code review 的其中一個難點，每個人都抱持善意，希望能夠更好，也提供協助，但是實際上自己接收訊息的時候，真的能每次都將其視為善意嗎？大家都說要有 reviewer 跟 mentor 指導，這樣才進步的又好又快，但我們真的想被指導嗎？
邏輯被攤開：原來 code review 是看思維
實際上寫程式時，你會在程式碼裡面展現以下：
- 你怎麼思考問題
- 你覺得什麼是清楚的邏輯
- 你認為什麼是好的命名方式
- 你對程式碼「優雅」的定義
以為的 code review comment，可能就像老師改作業一樣：「這裡有個小錯誤，改一下就好囉」。但實際上對我來說，那可能更像是是有人看了你寫的日記，然後說：「這段思考邏輯不通，要換一種方式想。」（這就是我心裡常跑出來的濾鏡）
當然我們都理解這是學習的機會，改正就好，但我必須說這很困難。調整這些底層的思維習慣，是一個極其痛苦且漫長的過程，伴隨強烈不適感，因為必須練習用自己不習慣的方式處理問題，而且這不是一蹴可及。
標準落差：我的『夠好』為什麼不夠好？
舉一個例子：
你習慣了買料理包做菜，只要加熱，一下子就能變出一道菜。它很方便，你也知道他的流程跟結果，你覺得味道也還行。
但如果有一天因為團隊要求，你必須學會從零開始做一道菜，而且要統一規格，必須有團隊特有的「媽媽味」，例如：炒出媽媽風味蕃茄蛋
這會發生什麼事？你必須自己去市場挑菜、洗菜、切菜、炒蛋，還要學習什麼時候下鍋、火候大小、什麼時候放鹽巴。剛開始，你可能會把蛋炒太乾，味道也可能很奇怪，甚至會手忙腳亂，又忘記某個步驟。你看了食譜以為會了但事實上你根本還沒搞清楚狀況。
而在新習慣養成的過程中，一旦遇到緊急或者勞累的時候，你就會忘記要用新的習慣去解決問題，也就是說問題在這個過程中會反覆復發，也會需要反覆被提醒。這相當挫折，我常常會想：「寫出來也是能動啊。」
這時，就會遇到：「我就覺得料理包味道也還行，為什麼一定要有媽媽味？還要注意那麼多？」 — 這就是價值觀抵觸
工程師的「社會化」：個人標準如何與團隊對齊？
前期我大概就是一直遇到這樣的問題，自己預設的標準跟團隊標準不一樣。我需要符合團隊的標準，所以需要調整自己的標準，即使我覺得還好。在這部分，其實團隊有積極透過溝通協助我理解，讓我明確認知團隊需求的必要性。因為我是在一個團隊底下工作，不是為自己寫程式，對品質與流程的期待自然不同。這也是我當軟體工程師「社會化」的過程，我的品質標準必須要符合團隊標準。
為什麼公司要做行為面試？
在這個磨合過程中，我也漸漸理解到一個現象 — 為何許多團隊在招聘時，會如此重視行為面試？
正是因為習慣的養成與修正都十分困難，當引入了有經驗的工程師，如果他已形成某種根深蒂固的習慣，改變習慣就非常困難，更別說他已經深植了某些「價值觀」。改變習慣會深深觸及個人認同和價值觀，有時甚至可能讓人產生「對錯之爭」的錯覺，或誤以為是在否定他一直以來認為正確的做法。
並不是每個人都容忍得下內心裡建立不同標準。更何況，有的時候不是對錯問題，一旦有了這種根深蒂固的觀念，行為上的改變會更加困難。因此，一個團隊確實需要選擇那些價值觀和文化與自身需求相符的人，因為有的時候，即使人進來了，彼此的磨合也可能真的難以實現。
工程師最難的還是溝通
當「懂了」與「沒懂」之間，是無法跨越的鴻溝。
這也是我前期卡關最嚴重的地方：雙方都以為彼此懂了，但其實內在標準根本不一樣。這不是誰的錯，而是職場上非常常見的「經驗與隱性標準的落差」所導致的溝通誤區。以下說明我的歷程
摸索期：為什麼品質忽好忽壞？
第一年的時候我一直為了功能的「正確性」的問題苦惱打轉（也就是產出品質是否足夠、是否確實符合規格），我寫出來的功能有時候會做得很好，有時候會做不好。
在尋求建議的過程中，我發現『多檢查幾遍』是常見的建議。
但我明白這不是檢查的問題，我已經檢查好多次了，問題是：我沒辦法發現。而我為什麼沒辦法發現？難道我檢查好多遍都還是不夠仔細嗎？
- 為什麼這裡會犯錯？
- 為什麼我沒有想到？
那段摸索期很常在這種高壓的自我檢視中度過，也成了當時的日常。
重新定義「理解」：為什麼我的「懂了」，跟資深前輩不一樣？
我們或許不該將『理解』視為單一標準的結果。事實上，由於個人經驗、視角、思考的流程的不同，每個人的理解結果必然各異。
- 思考的流程：分析、比較、歸納、驗證之類的流程。
- 思考的結果：經歷上述流程後得到的「我已經懂了」的狀態，為理解。是我們根據既有經驗與知識建構出來的判斷。
如果理解是綜合「我的經驗」推論出來結果，那麼出錯其實很正常，因為我經驗還不夠，根本不知道哪些地方有可能出錯。
而我跟資深同事的理解前的思考流程根本不一樣，甚至理解「品質好」的定義也不一樣，那麼要怎麼能夠達到品質的要求？更困難的是，我甚至說不出自己缺了什麼，因為我根本無法辨識差距在哪裡。
實例差異：新手四步 vs 資深一步
| 角色 | 檢查心智模型 | 實際動作 |
|---|---|---|
| 新手 | 排版需確認的平台有限 | 測試兩～四個常用裝置／瀏覽器 |
| 資深 | "檢查寄信排版" ＝ 所有裝置＋瀏覽器的完整驗收 | 一口氣檢查桌面 App、Web、Mobile、跨瀏覽器 |
新手可能只會測試自己常用的裝置或瀏覽器，這對他來說是四個獨立的檢查步驟，因為他還沒意識到「環境差異會影響結果」這件事。他可能只想到兩步檢查。但資深工程師早已內化這些檢查，都叫做「檢查寄信排版」。這在他們腦中只是一步，卻涵蓋了所有平台與裝置的考量。
脫離混亂！Checklist 如何幫我對齊「隱性」的品質標準？
這些隱形流程的理解差異，就是我當時無法意識到的盲點，也就「想問也不知道怎麼問」。這其實是對品質標準理解的落差，而這種新手與資深者間的認知落差，在技術領域中相當普遍。資深同事已經內化了完整的思考流程，而新手還在建立自己的思考流程。這種經驗差距讓學習過程充滿了很多挑戰，是技術成長路上的常見現象。
後來我是回去找我訓練營的學姊聊一聊之後才發現問題點。而且這些坑他早就踩過了…這些坑是新人常態。我那時候真的忍不住想：「天啊！這種坑到底怎麼樣才能自己發現啊？」，因為其他 camp 出來的同學跟我處在同個時期，我們卡的問題根本差不多，看不到彼此的盲點，反而是那些「剛進業界一兩年、還記得混亂期」的學姐，才有可能講出貼近現實的辦法。
程式碼會報錯，但人與人之間的落差不會
程式寫錯了會噴錯，但當我和前輩對「檢查標準」的理解不同時，卻沒有任何提示告訴我們彼此想的不一樣。
這不是說多檢查幾次就會發現，這也不是誰不夠仔細（當然有的時候還是會粗心），這可能是驗證流程沒有對齊所造成的。後來我和學姊釐清這個問題後，主動找前輩討論，決定在每次執行任務前，先列出一份檢查清單（checklist），用來對齊彼此對驗證重點與範圍的認知，並正式納入團隊的任務流程中。
舉個實際的 checklist 為例：在提交按鈕附近，會提醒檢查以下項目：
□ 正常狀態下可點擊
□ 資料不完整時點擊會跳出提示
□ 已經提交後按鈕需要防呆不能按
□ 成功後顯示確認訊息
□ 失敗時顯示錯誤提示
這樣的清單能在開發一開始就明確列出所有驗證點跟情境，讓團隊成員不會各自解讀需求，或遺漏特定角色的狀況。不是去多測幾次就能補救，而是從一開始就建立一致的檢查框架。這樣的 checklist 看似簡單，卻真正幫我們解決了品質問題，也避免後期才發現問題、導致需要反覆修改甚至重寫。 （不過…我現在再看這個，第一個直覺也是覺得這個不是應該注意到嗎？🤣 看來是升等有感了，會有盲點了）
結語
有了 Checklist 和更清楚的標準後，我的品質開始穩定下來。雖然還是會犯錯，但至少知道該檢查什麼、該注意什麼。這個過程大概又花了幾個月，但確實感受到自己在進步。Code Review 的 comment 開始從「基礎問題」轉向「更好的寫法建議」，我知道自己總算是從最混亂的階段走出來了。
但老實說，checklist 只是讓我不再那麼混亂而已。我到現在還是常常會想：「這個我當時怎麼會看不出來？」每次回頭看自己幾個月前的程式碼，都還是會有這種感覺。可能這就是成長的證明吧——永遠會覺得過去的自己還有改進空間。
不過在那之後，更大的挑戰是：光有 checklist 還不夠，『發現差距後，要怎麼真正縮小它？怎麼慢慢追上團隊的思考流程，甚至超越？』這又是另一段漫長的旅程了。關於這部分我之後會再寫一篇，分享我是如何透過「復盤」來補足這一塊的。
我的適應期其實超過 6 個月，對我來說上面的歷程都是超級不容易，萬幸自己是撐了過去。也非常感謝當時的團隊與前輩們的耐心，還有那些在我最低潮時依然願意陪伴的人。沒有這些衝擊，我可能還停留在覺得『能動就好』的階段。
當初是因為覺得喜歡寫 code 才轉職，但當這份喜歡昇華為職業，才真正體會到其中的萬般不同...它不再是純粹的自由發揮，而是一段需要長期磨合與對齊的過程，也是一份必須全然承擔的責任。原來，把興趣當飯吃，也沒那麼浪漫啊...。
寫這篇文章，是想記錄我的掙扎。因為到現在，我也還會掙扎。偶爾真的會跌倒，會懷疑、會累，只想先躺平。大家都會說「加油、再站起來」，但不是每一次都能馬上做到。有時候，是在地上多躺了一會，才終於願意再爬起來。真的很幸運身邊有人願意等我躺夠了再起來。
相關文章：附上剛從 bootcamp 畢業後的文章，可以做對比...
Yin