非暴力溝通：為什麼你的 Code Review 總是變成互相指責？

當 Code Review 變成「程式碼法庭」時，你就知道溝通出了問題

不知道大家有在 Code Review 中被「狠狠批評」的經驗嗎？

你花了一整天寫的功能，滿懷期待地提交 PR，結果收到一堆「這個寫法有問題」、「為什麼不這樣寫」、「這樣會有 Bug」的評論。

你心裡想：「這些人怎麼這麼挑剔？我的程式碼明明能跑啊！」

然後你開始反擊：「這個寫法有什麼問題？」、「你說的 Bug 在哪裡？」、「你有更好的寫法嗎？」

結果，Code Review 變成了「程式碼法庭」，大家在爭論誰對誰錯，而不是如何讓程式碼變得更好。

這就是「暴力溝通」的典型症狀。

《博客來-非暴力溝通：愛的語言(全新修訂版)》這本書，正是為了解決這個問題。
它教會我，溝通不是「證明自己對」，而是「一起找到更好的解決方案」。

痛點一：Code Review 變成互相指責，破壞團隊氛圍

描述：在 Code Review 中提出的建議被同事視為人身攻擊

典型災難場景：

👤 工程師A：
「這個函式寫得不好，應該要重構」

👤 工程師B：
「哪裡不好？我的程式碼能跑啊」

👤 工程師A：
「能跑不代表寫得好，你看這個邏輯這麼複雜」

👤 工程師B：
「複雜又怎樣？你寫的就很簡單嗎？」

👤 工程師A：
「至少我的程式碼別人看得懂」

👤 工程師B：
「你的意思是我的程式碼別人看不懂？」

👤 工程師A：
「我沒這樣說，但你這個寫法確實有問題」

👤 工程師B：
「那你說說看，哪裡有問題？」

👤 工程師A：
「...算了，你愛怎麼寫就怎麼寫」

👤 工程師B：
「...」

為什麼會這樣？

• 大家都在「評判」程式碼，而不是「理解」程式碼
• 焦點放在「誰對誰錯」，而不是「如何改善」
• 沒有區分「程式碼」和「寫程式的人」

書中解方：對事不對人，聚焦於「程式碼」而非「寫程式的人」

非暴力溝通的四個要素：

1. 觀察（Observation）

描述事實，不帶評判

不好的表達：

「這個函式寫得很亂」
「這個命名很奇怪」
「這個邏輯有問題」

好的表達：

「這個函式有 50 行，包含了驗證、處理和儲存三個邏輯」
「這個變數名稱是 `temp`，比較通用」
「這個條件判斷有 5 層巢狀」

2. 感受（Feeling）

表達你的感受，而不是想法

不好的表達：

「我覺得你寫得不好」
「我認為這個設計有問題」
「我覺得你應該要這樣寫」

好的表達：

「我看到這個函式時，感覺有點複雜」
「我擔心這個邏輯可能會讓其他同事難以理解」
「我對這個效能有些疑慮」

3. 需要（Need）

說明你的需要或價值觀

不好的表達：

「你應該要這樣寫」
「這樣寫比較好」
「標準做法是這樣」

好的表達：

「我希望能讓程式碼更容易維護」
「我重視程式碼的可讀性」
「我希望能確保系統的穩定性」

4. 請求（Request）

提出具體、可執行的請求

不好的表達：

「你要重構這個函式」
「你應該要加上註解」
「你要處理這個問題」

好的表達：

「我們可以考慮將這個函式拆分成三個小函式嗎？」
「可以幫這個複雜的邏輯加上一些註解嗎？」
「我們可以一起討論一下這個潛在的問題嗎？」

改進後的 Code Review 範例：

👤 工程師A：
「我看到這個函式有 50 行，包含了驗證、處理和儲存三個邏輯。
我擔心這可能會讓其他同事難以理解和維護。
我希望能讓程式碼更容易維護。
我們可以考慮將這個函式拆分成三個小函式嗎？這樣每個函式的職責會更單一。」

👤 工程師B：
「你說得對，我確實把太多邏輯放在一個函式裡了。
我們可以一起討論一下怎麼拆分比較好？」

👤 工程師A：
「太好了！我覺得可以這樣拆分：
1. `validateUserInput()` - 負責驗證
2. `processUserData()` - 負責處理
3. `saveUserToDatabase()` - 負責儲存
你覺得這樣的拆分合理嗎？」

👤 工程師B：
「很合理！我來重構一下，謝謝你的建議。」

關鍵差異：

• 聚焦於程式碼：討論的是程式碼本身，不是寫程式的人
• 表達感受和需要：讓對方理解你的關切點
• 提出具體請求：給出明確的改善方向
• 保持開放態度：邀請對方一起討論

痛點二：跨部門溝通困難，技術與商業語言不通

描述：跟 PM 或設計師溝通時，對方聽不懂技術限制

典型災難場景：

👤 PM：
「我們需要一個新的功能，讓用戶可以上傳圖片」

👤 工程師：
「這個功能需要考慮檔案大小限制、格式驗證、儲存空間、CDN 配置、安全性檢查...」

👤 PM：
「...什麼是 CDN？」

👤 工程師：
「CDN 就是內容傳遞網路，用來加速圖片載入...」

👤 PM：
「...我們先不要管這些技術細節，什麼時候可以上線？」

👤 工程師：
「這要看你們的需求規格，如果只是簡單上傳，大概一週；如果要加上壓縮、縮圖、浮水印，可能需要兩週...」

👤 PM：
「為什麼要這麼久？不就是上傳圖片嗎？」

👤 工程師：
「...」

為什麼會這樣？

• 技術人員用技術語言，商業人員用商業語言
• 沒有建立共同的溝通橋樑
• 缺乏對彼此領域的理解

書中解方：使用「類比」與「翻譯」的技巧

1. 技術概念的「翻譯」

不好的表達：

「這個功能需要 Redis 快取」
「我們要用 WebSocket 做即時通訊」
「這個 API 需要 JWT 認證」

好的表達：

「這個功能需要一個『記憶體』來暫存資料，就是快取，存取速度很快」
「我們要用『即時通訊』技術，就像 LINE 一樣，訊息會立即傳送」
「這個 API 需要『身份證』來確認用戶身份，就像進門要刷卡一樣」

2. 商業價值的「翻譯」

不好的表達：

「這個功能會影響效能」
「這個設計不符合技術架構」
「這個需求太複雜了」

好的表達：

「這個功能可能會讓網站變慢，用戶體驗會變差」
「這個設計可能會讓後續維護變困難，增加開發成本」
「這個需求需要更多時間來確保品質，可能會延後上線時間」

3. 實際應用範例

場景：PM 要求即時聊天功能

👤 PM：
「我們需要即時聊天功能，用戶發送訊息後要立即顯示」

👤 工程師：
「我理解你的需求。這就像 LINE 的即時通訊一樣，對吧？
不過這在技術上需要一些額外的考量：

1. 即時性：我們需要建立『即時連線』，就像打電話一樣，需要保持連線
2. 穩定性：如果網路斷線，訊息不能遺失，就像簡訊一樣
3. 效能：如果同時有很多人在聊天，系統要能承受，就像電信公司要處理很多通話

基於這些考量，我建議我們分階段實作：
- 第一階段：基本聊天功能（1週）
- 第二階段：加入離線訊息（0.5週）
- 第三階段：優化效能（0.5週）

你覺得這樣的規劃合理嗎？」

👤 PM：
「很合理！我理解了技術的複雜性，我們就按照這個規劃進行。」

關鍵技巧：

• 用生活化比喻：讓技術概念變得具體
• 說明商業影響：讓技術決策有商業意義
• 提供選擇方案：讓對方有參與感
• 確認理解：確保溝通沒有誤解

我的實踐：將非暴力溝通應用到技術工作中

建立「建設性回饋」文化

1. Code Review 的 SOP

Before（暴力溝通）：

「這個寫法有問題」
「為什麼不這樣寫？」
「這樣會有 Bug」

After（非暴力溝通）：

「我注意到這個函式比較長，我擔心可能會影響可讀性。我希望能讓程式碼更容易維護。我們可以考慮將它拆分成幾個小函式嗎？」

2. 需求討論的 SOP

Before（暴力溝通）：

「這個需求不合理」
「技術上做不到」
「時間不夠」

After（非暴力溝通）：

「我理解你想要達成 X 目標，但目前的方案可能會遇到 Y 挑戰。
我希望能確保專案的品質和時程。我們可以一起討論一下是否有其他方案？」

建立「同理心」思維

1. 理解對方的動機

「PM 為什麼要這個功能？」
「設計師為什麼要這樣設計？」
「同事為什麼要這樣寫程式碼？」

2. 表達自己的動機

「我提出這個建議，是因為我關心程式碼的品質」
「我擔心這個方案，是因為我重視系統的穩定性」
「我建議這樣做，是因為我希望團隊能更有效率」

建立「共同解決問題」的心態

1. 從「對立」到「合作」

❌ 「你的想法有問題」
✅ 「我們一起找到更好的解決方案」

❌ 「你應該要這樣做」
✅ 「我們可以討論一下這樣做的好處和挑戰」

2. 從「批評」到「建設」

❌ 「這個設計不好」
✅ 「這個設計可以這樣改善」

❌ 「你的程式碼有問題」
✅ 「這個程式碼可以這樣優化」

總結：溝通是技術工作的核心技能

非暴力溝通不是「軟弱」，而是「智慧」。

有重要三個原則：

1. 對事不對人：聚焦於問題本身，不是個人
2. 表達感受和需要：讓對方理解你的關切點
3. 提出具體請求：給出明確的改善方向

實務建議：

• 在 Code Review 中，用「觀察-感受-需要-請求」的結構
• 跨部門溝通時，用生活化比喻「翻譯」技術概念
• 建立「建設性回饋」的文化，而不是「批評」文化
• 將溝通視為「共同解決問題」，而不是「證明自己對」

好的溝通不是為了證明自己對，而是為了找到更好的解決方案。

明天我們來聊聊，如何用「向上管理」來讓你的技術價值被看見。

#非暴力溝通 #CodeReview #團隊協作 #溝通技巧 #吳桑泥的升級書單