🔧 阿川の電商水電行
我們來聊聊程式碼審查中究竟發生了什麼事。
你認識那個剛辭職的初級員工嗎？就是那個在離職面談裡提到你的評價讓他覺得自己永遠不夠好的？沒錯，我的團隊裡就發生過這種事。在你覺得「我的初級員工都很喜歡我的回饋」之前，先問問自己：如果他們不喜歡，他們會告訴你嗎？
這並非指責誰。好吧，其實——的確如此。因為太多資深開發者把程式碼審查變成了一場表演，我們是時候該指出來了。我自己也犯過這樣的錯。但這並不意味著我們不應該揭露整個產業正在發生的事情。
🎭 “最佳實踐”劇場
模式是這樣的：一個初級程式設計師提交了一個 PR，優雅地解決了問題。測試通過，邏輯也正確。然後你就插話進來：
-
「這個變數應該是
userData而不是user」。 -
我們能讓它更實用嗎？
-
“我本來會用工廠現成的模板。”
-
「嗯，有趣的方法…」（譯： 「這樣做不對，但我想要顯得深思熟慮」）
同時，他們真正錯過的漏洞呢？會導致生產環境崩潰的極端情況呢？你沒發現它，因為你忙著論證他們的函式應該叫processData還是handleDataProcessing 。
你不是在審查他們的程式碼，你是在運用你的專業技能。
⚔️ 吹毛求疵的權力之旅
讓我們坦誠地談談程式碼審查對許多資深程式設計師來說已經變成的什麼：一種武器。也許並非出於惡意，但影響卻是一樣的。
完美主義者的遊樂場
每一次 PR 都變成了展示你如何做得更好的機會，而不是展示如何改進他們的程式碼。
你偷偷塞進一些你剛學到的晦澀難懂的模式。你把之前公司的架構決策當作普遍真理來引用。你留下的評論其實只是你的自言自語，而不是什麼切實可行的回饋。
移動球門柱遊戲
-
🥇第一輪： “使用更具描述性的名稱”
-
🥈第二輪： “其實，這些名字太冗長了”
-
🥉第三輪： “你能重寫整個函數嗎？”
-
💀第四輪：他們放棄了，正在更新履歷
聽起來是不是很耳熟？如果你這樣做，你不是在“維護標準”，而是在欺凌新員工。
冷戰
三天了。沒有評論。沒有批准。只有……沉默。
你告訴自己「太忙了」或「需要再想想」。但實際上呢？你只是在拖延給予有效回饋這項艱鉅的任務。而你的沉默呢？它賦予你權力。它讓你成為瓶頸。它讓別人等著你。
那不是領導力，那是把關。
🚨 你忽略的真正問題
當你在爭論文法糖的時候，你卻沒問到這個問題：
-
這樣真的能解決用戶的問題嗎？
-
我們是否在引入技術債？
-
這真的是應該開發的功能嗎？
-
這種模式可以推廣嗎？
-
有人測試過正常流程以外的情況嗎？
當然，你可以爭論這應該是一個類別還是一個函數。因為這些爭論會讓你覺得自己很聰明。而那些真正需要思考的問題呢？
🤷♂️“但是程式碼品質！”
是啊，大家都用「程式碼品質」來解釋。
但你實際創作的是：
-
初級開發人員學會編寫能通過你審查的程式碼，而不是寫優秀的程式碼。
-
一個團隊，真正的學習不再發生。
-
在一個因你基於偏好的吹毛求疵而扼殺創新的環境中
你並沒有提高標準，只是為了保持競爭力而不斷調整標準。
🧪 自我測試
當出現以下情況時，你的評價文化就是有害的：
-
你因為一些不符合任何風格指南的風格偏好而屏蔽了 PR——這些偏好僅僅是你的個人偏好而已。
-
你的評論只關注他們是如何做到的，而沒有關注這種方法是否有效。
-
你對其他資深人士的糟糕做法表示認可，卻對低年級學生犯下同樣的錯誤大加撻伐。
-
討論帖的長度往往超過了差異本身——因為你無法放手。
-
你會發現自己心裡想著：“如果我找不到什麼問題，人們就會質疑他們為什麼需要我。”
如果你發現自己符合以上任何一點，恭喜你：你也是問題的一部分。
✅ 程式碼審查的真正意義是什麼
程式碼審查應該：
-
發現漏洞和安全問題（你知道，就是那些重要的事情）
-
分享為什麼某些方法更好，而不僅僅是斷言它們更好。
-
驗證解決方案是否符合問題要求。
-
確保測試真正檢驗的是重要內容。
-
要進行對話，而不是單向講授
注意到少了什麼嗎？
證明你比作者更聰明。
🌱 一篇好評論到底是什麼樣的
大多數老年人寫道：
“這種方法無法擴展。請使用倉庫模式重寫。”
導師制的具體形式：
「不錯的解決方案！不過有個問題：這種方法會循環查詢資料庫，如果記錄很多，速度可能會比較慢。你能不能批量處理一下？如果需要的話，我很樂意一起研究——這是我們之前用過的方法：[連結]。但如果這種方法有什麼我沒考慮到的原因，請告訴我！”
第一種是把關，第二種是合作。
你在做哪一個？
🌑 令人不安的真相
大多數評論都帶有表演性質。
它們不過是披著品質控制外衣的掩蓋真相之舉。它們其實是你為了維護自己「資深」的地位而採取的手段，因為你覺得自己比誰都懂。它們其實是你害怕如果沒發現問題，別人就會質疑你存在的意義。
是的，我也犯過同樣的錯誤。但認識到問題的存在並不能免除我們解決問題的責任。
🤔 在點擊「提交」之前需要問自己的問題
在你留下下一則評論之前，請強迫自己回答以下問題：
-
我進行程式碼審查是為了改進程式碼，還是為了炫耀？
-
這則評論是有用的還是只是批評？
-
我是因為個人偏好還是實際問題而選擇屏蔽？
-
如果這段程式碼是另一位資深人士寫的，我會接受嗎？
-
這則評論會幫助他們成長，還是只會讓他們感到渺小？
如果你對自己誠實，你可能會刪除一半的評論。
🧾 底線
良好的程式碼審查：
-
捕捉昆蟲
-
傳播知識
-
改進系統
-
增強自信心
糟糕的程式碼審查：
-
迷霧籠罩著人們
-
拖慢球隊速度
-
維持自尊心
-
嚇跑人才
有時，你能給出的最好評價是：
“看起來不錯，發貨了。”
當你收到回饋時，先說說哪些方面做得好，再指出哪些需要改進。多問問題，少妄下斷言。要像對待專業人士一樣對待每一位公關稿撰寫者。
挑戰來了：去看看你最近的 10 次程式碼審查。認真仔細地看看。你的評論有多少是關於實際問題的，又有多少是關於個人偏好的？你問了多少問題，又提了多少要求？如果你把精力放在真正重要的事情上，有多少 PR 可以提前一天發布？
資深開發人員/評審員的職責不是當守門人，而是打開大門；是鼓勵他人，而不是打擊他人；是運用我們的經驗讓團隊變得更好，而不是證明我們是房間裡最聰明的人。
問題是：你這樣做了嗎？
還是說你只是在搞一場自我膨脹的競賽，卻美其名曰「程式碼審查」？
原文出處：https://dev.to/adamthedeveloper/code-reviews-quality-control-or-ego-olympics-426g
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
