看著這個標題我第一反應是這又是什么網(wǎng)絡熱梗。但仔細想想它在開發(fā)者圈子里其實扎心得很多少人剛學會一個新框架轉頭就去嘲諷還在用舊技術的同事多少人把代碼寫得晦澀難懂還覺得是自己水平高多少人晉升之后第一件事不是把事情做得更好而是讓身邊的人顯得更弱。技術圈有一個很有意思的現(xiàn)象**一個開發(fā)者真正的分水嶺往往不是他變強的那一刻而是他變強之后怎么對待“弱者”的那一刻。**有的人選擇用能力去解決問題有的人選擇用能力去制造問題。而后者通常會在接下來的工程協(xié)作里付出慘痛代價。這篇文章不打算單純玩梗而是想借著這個標題把“變強之后的技術姿態(tài)”這件事聊透。我會從真實的開發(fā)場景出發(fā)講講為什么“侮辱弱者”在工程上其實是一筆虧本買賣以及當你真的變強之后應該用哪些工程化手段來讓自己的強變得可復制、可維護、可協(xié)作。如果你正在帶新人、做代碼審查、維護老系統(tǒng)或者剛剛從“寫代碼的人”變成“影響代碼的人”這篇文章值得看完。1. 這篇文章真正要解決的問題先界定一下這里的“強者”和“弱者”并不是對人的貶低而是對技術能力狀態(tài)的一種比喻。在一個團隊里強者的狀態(tài)通常是能看懂別人看不懂的代碼能設計出更合理的架構能快速定位別人找不到的 bug能引入新的技術方案解決老問題。弱者的狀態(tài)則可能是剛入行的新人還在熟悉業(yè)務和代碼規(guī)范維護著多年歷史的遺留系統(tǒng)不敢輕易動核心模塊被復雜業(yè)務裹挾短期內沒有時間重構技術債熟練度不夠寫出的代碼不夠優(yōu)雅。這三類人真實地存在于每一個團隊里每個人在職業(yè)不同階段也都可能處于其中某個位置。真正的問題是當一個人從“弱者”變成“強者”之后他對還在弱狀態(tài)的代碼、系統(tǒng)和同事采取什么樣的態(tài)度會直接決定下一個階段他是繼續(xù)變強還是開始滑落。這篇文章要解決的核心問題有三個為什么“侮辱弱者”在技術世界里是低效行為而不只是道德問題當你看不慣一段代碼、一個系統(tǒng)、一個人的時候正確的技術動作是什么如何通過代碼、工具和流程把個人的“強”轉化為團隊和系統(tǒng)的“強”。換句話說這篇文章不是雞湯而是一份“變強后行為指南”。2. 技術世界里的“強者”與“弱者”到底是什么在開始講方法之前先把概念對齊一下。2.1 代碼層面的強弱代碼沒有情感但它有質量高低之分。強代碼的特征通常是可讀性高命名清晰結構簡單可測試核心邏輯能被單元測試覆蓋可維護修改一個功能不需要連帶改十幾個文件有邊界模塊之間通過接口通信不隨意共享可變狀態(tài)。弱代碼的特征則相反命名隨意變量叫a1、data、temp函數(shù)又長又雜一個方法幾百行改一個參數(shù)影響一片邏輯沒有測試改完只能靠人工回歸各種隱式依賴全局變量滿天飛模塊之間耦合嚴重。但是這里有一個關鍵認知**弱代碼不等于寫代碼的人弱。**很多所謂“爛代碼”是在業(yè)務壓力大、時間緊迫、需求頻繁變更的情況下產生的。它是當時條件下的局部最優(yōu)解只不過后來環(huán)境變了它沒有跟上。2.2 開發(fā)者層面的強弱開發(fā)者層面的強弱往往體現(xiàn)在判斷力上。初級開發(fā)者通常關注的是“這段代碼能不能跑通”“這個 API 怎么調用”“這個報錯怎么解決”進階開發(fā)者會進一步問“這個方案在并發(fā)下會不會有問題”“這個設計后續(xù)能不能擴展”“這個依賴引入的成本值不值”資深開發(fā)者則會再進一步“這個方案對整個系統(tǒng)意味著什么”“團隊其他人能維護嗎”“三個月后回來看這個決定還成立嗎”**強者與弱者之間差的往往不是技術棧的多少而是思考尺度的長短。**理解了這一點你就會明白單純的“侮辱”解決不了任何工程問題它只會讓思考尺度短的人更不敢思考。2.3 系統(tǒng)的強弱系統(tǒng)也有強弱之分。強系統(tǒng)有明確的架構邊界、完善的監(jiān)控告警、合理的容量規(guī)劃、完整的文檔沉淀。弱系統(tǒng)則是“能跑就行”沒有監(jiān)控、沒有日志、沒有降級方案出問題只能靠重啟大法。但注意幾乎所有強系統(tǒng)都是從弱系統(tǒng)演化來的。把系統(tǒng)變強才是工程能力嫌系統(tǒng)弱然后重寫一遍很多時候只是賭博。這也是“侮辱弱者”最坑人的地方它會讓強者產生一種“我很行、系統(tǒng)不行”的錯覺然后沖動地去推倒重來而不是在現(xiàn)有基礎上穩(wěn)步改造。3. 變強之后侮辱弱者工程上要付出什么代價很多剛變強的人會有一個錯覺我看出了別人代碼的問題我指出來我嘲笑他這能證明我強。但工程世界是結果導向的侮辱本身對系統(tǒng)沒有任何貢獻代價卻是實打實的。3.1 溝通成本指數(shù)級上升在代碼審查里如果評論寫得充滿攻擊性例如“這種代碼也能提交”、“你寫的這是什么東西”對方的防御心理會立刻拉滿。接下來你們爭論的焦點就不再是“這段代碼是否正確”而是“你的語氣是否尊重人”。一次 5 分鐘能結束的 review會演變成半小時的情緒拉鋸然后什么事情都推進不下去。3.2 信息透明被打斷團隊的底層信任一旦被破壞新人和經(jīng)驗少的同事就不敢再暴露自己的問題。不敢問、不敢提、不敢改遇到問題自己悶著頭硬扛最后產出更差的代碼然后又被嘲諷一輪。這是一個惡性循環(huán)最終所有人都在為低質量代碼買單。3.3 系統(tǒng)風險被低估“侮辱弱者”還有一個隱蔽的變種看不起老系統(tǒng)。很多人一進團隊看到老代碼就皺眉頭張口閉口“這代碼沒法看”然后提一個“重構大方案”。但老系統(tǒng)雖然丑它可能承載了大量隱含業(yè)務邏輯。強行重構而缺乏有效驗證手段往往上線即事故。真正的強者不會用“這代碼很爛”來證明自己而是會用“我能在不動它的情況下加新功能”來證明自己。3.4 技術判斷容易變形當一個人把大量精力花在證明“別人弱、我強”上時他的技術判斷就開始變形了。他會傾向于選擇看起來更炫酷的方案而不是更合適的方案會更在意代碼的“復雜度”來彰顯水平而不是用“簡單”來解決問題會更愿意新造輪子而不是復用穩(wěn)定但不夠性感的組件。一個很典型的場景是明明用數(shù)據(jù)庫唯一索引就能解決的問題非要把重構做成分布式鎖 消息隊列 事務消息理由是這樣“架構更先進”。結果系統(tǒng)復雜度上去了可用性沒提升反而引入一堆新問題。這不是強這是表演強。4. 把“侮辱”翻譯成技術動作一次老代碼重構的正確姿勢聊完了代價接下來進入技術實操。假設你現(xiàn)在就是一個“變強了”的開發(fā)者看了一段老代碼覺得它寫得不夠好。這時候正確的技術動作是什么我們從一個最常見的場景開始一個歷史悠久、邏輯混亂、沒有測試的模塊它還不時出線上問題大家都在靠手工補丁維護它。你覺得它很弱你想改造它。4.1 第一步不要一上來就重寫很多人看到老代碼的第一反應是“重寫”。這是最大的坑。老代碼哪怕再難看它是在生產環(huán)境里被驗證過的里面可能包含了大量你還沒理解到的邊界情況。直接重寫相當于拿一個新系統(tǒng)在線上做實驗風險極高。正確的做法是先做行為凍結把當前代碼的行為當成“正確行為”記錄下來然后進行重構重構過程中保證行為不變。重構完成之后再由業(yè)務方?jīng)Q定哪些行為需要調整。4.2 第二步先補測試再動代碼沒有測試保護的重構本質上就是裸奔。如果在你的環(huán)境里還沒有測試基礎設施可以先從最小單元開始。下面用一個 Python 的例子來說明假設我們有一個老函數(shù)邏輯混亂但還在線上跑著# 文件路徑legacy/order.py # 老代碼計算訂單折扣邏輯比較混亂 def calc_discount(order): total 0 for item in order[items]: total item[price] * item[count] customer order.get(customer, {}) level customer.get(level, normal) if level vip: if total 1000: return total * 0.8 else: if total 500: return total * 0.9 else: return total * 0.95 else: if total 2000: return total * 0.85 else: return total這段代碼的問題是折扣邏輯嵌套太深條件判斷散亂后續(xù)很難維護。但你現(xiàn)在不能直接改它因為你不知道哪些分支是業(yè)務真正依賴的。我們要做的第一件事是先把當前行為鎖定住。# 文件路徑tests/test_order_legacy.py # 先把當前行為記錄下來 import pytest from legacy.order import calc_discount def test_vip_over_1000_gets_20_percent_off(): order { items: [{price: 600, count: 2}], customer: {level: vip}, } assert calc_discount(order) 960 def test_vip_between_500_and_1000_gets_10_percent_off(): order { items: [{price: 300, count: 2}], customer: {level: vip}, } assert calc_discount(order) 540 def test_normal_over_2000_gets_15_percent_off(): order { items: [{price: 1100, count: 2}], customer: {level: normal}, } assert calc_discount(order) 1870這些測試用例的目的是把老代碼當前的行為變成一個可以自動驗證的基準。有了這批測試后面無論你怎么改代碼只要跑一遍測試就能知道有沒有改壞業(yè)務邏輯。4.3 第三步用“替換”而不是“重寫”的方式重構有了測試保護后就可以開始重構了。注意重構的原則是小步替換不要一次把所有邏輯都改了。每次改完立刻跑測試確保綠燈。我們可以把折扣計算邏輯抽取成一個獨立的函數(shù)讓原函數(shù)只負責調度# 文件路徑legacy/order.py # 重構后將折扣計算邏輯分離保持行為不變 def _calculate_discount_rate(level, total): 根據(jù)用戶等級和金額返回折扣率。 if level vip: if total 1000: return 0.8 if total 500: return 0.9 return 0.95 if total 2000: return 0.85 return 1.0 def calc_discount(order): total sum(item[price] * item[count] for item in order[items]) level order.get(customer, {}).get(level, normal) return total * _calculate_discount_rate(level, total)這樣改動之后對外行為完全一致但代碼結構清晰了很多。以后想修改折扣規(guī)則只需要調整_calculate_discount_rate這一個函數(shù)不需要在calc_discount里繞來繞去。這一步看起來沒有增加任何新功能但它讓后續(xù)的維護成本顯著下降而且風險可控。真正的強者恰恰敢于做這種看起來“沒什么技術含量”的整理工作。4.4 第四步讓新代碼建立在舊代碼行為之上當舊代碼被整理清楚之后新需求就能在其之上穩(wěn)定疊加而不是繼續(xù)在泥潭里打補丁。比如產品說要加一個“鉆石會員滿 500 打 7 折”的規(guī)則你只需要改一個函數(shù)# 文件路徑legacy/order.py # 新增會員等級展示可擴展性 def _calculate_discount_rate(level, total): if level diamond: if total 500: return 0.7 return 0.9 if level vip: if total 1000: return 0.8 if total 500: return 0.9 return 0.95 if total 2000: return 0.85 return 1.0這就是“不侮辱弱者”的工程化表達你把弱代碼變得不弱了而不是站在遠處嘲笑它為什么這么弱。5. 技術評審場景如何發(fā)表不同意見重構老代碼是“人與代碼”的關系日常開發(fā)里更高頻的場景是“人與人的關系”。在一次技術評審中你看到同事的設計有明顯問題你該怎么說低級的做法大家都能想到“這個設計不行?！薄澳銢]考慮并發(fā)吧”“這方案能上線嗎”這些話不一定錯但它們的表達方式會讓對方進入防御狀態(tài)。更工程化的表達方式是把主觀判斷變成客觀標準。比如下面這個對照表達方式效果“這個設計不行?！币l(fā)防御進入爭論“這個方案在 QPS 達到 1000 時數(shù)據(jù)庫連接數(shù)會翻倍可能存在連接池耗盡風險?！庇懻摼唧w問題“你沒考慮并發(fā)吧”顯得居高臨下“如果兩個請求同時走到這里會產生重復訂單建議增加唯一索引校驗?！苯o出具體防護建議“這代碼沒法用。”沒有建設性“從異常堆?？闯瑫r重試沒有得到冪等保護建議用訂單號做去重?！碧岢隹蓤?zhí)行方案原則其實只有一句話對事不對人把批評包裝成可驗證的技術指標。在代碼評審里我比較推薦一個模板式的表達結構## Code Review 建議模板 **問題描述**當前實現(xiàn)中XXX 操作在并發(fā)場景下可能產生重復數(shù)據(jù)。 **判斷依據(jù)** - 當前使用了先查詢再插入的方式中間存在時間窗口 - 數(shù)據(jù)庫未對業(yè)務唯一鍵加約束。 **建議方案** 1. 在 order_no 字段上增加唯一索引 2. 代碼中捕獲 DuplicateKeyException 并返回友好提示 3. 如果必須保留先查詢再插入的邏輯需要引入分布式鎖但成本更高不推薦。 **影響范圍**主要影響下單接口涉及訂單創(chuàng)建、支付回調兩個場景。這種表達不會讓人覺得你在“侮辱”他而是在幫他補齊盲區(qū)。而這本身就是一種強者行為你能把問題說清楚也能把方案給到位。6. 從個人強者到團隊強者代碼規(guī)范、自動化與知識沉淀個人變強是加法團隊變強是乘法。但很多團隊的問題在于強者的能力沒有被沉淀下來只停留在個人腦子里。今天他能解決的問題明天換一個人就解決不了。所以如果你真的變強了應該做的事是讓團隊里的“弱者”也能按相對正確的路徑成長而不是讓他們繼續(xù)在黑暗里反復踩坑。6.1 用自動化替代口頭指導很多重復性的代碼問題完全可以通過工具攔截不需要每次都由“強者”跑去給“弱者”講道理。比如在 CI 里增加靜態(tài)檢查在提交代碼時自動校驗。下面是一個常見的 CI 配置片段用 GitHub Actions 做 Python 項目的靜態(tài)檢查# 文件路徑.github/workflows/lint.yml name: lint on: pull_request: branches: [ main ] jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-pythonv4 with: python-version: 3.11 - name: Install dependencies run: | pip install ruff pytest - name: Run ruff run: ruff check . - name: Run tests run: pytest這個文件做的事情很簡單每次有人提交 pull request就自動跑一遍代碼檢查和測試。代碼風格問題、明顯錯誤機器先幫你篩掉一輪。這樣“強者”就不用每天花大量時間在 review 里給“弱者”逐行講“這里命名不規(guī)范”、“那里缺少空行”了可以把精力放在真正的架構設計上。6.2 寫文檔但是要寫“為什么”很多團隊有文檔但只寫了“怎么做”沒有寫“為什么”。結果就是后來的人只會照著步驟做遇到一點變化就卡住然后又來問“強者”。一個合格的接口文檔至少應該包含這樣幾個部分# 訂單創(chuàng)建接口文檔 ## 接口說明 創(chuàng)建一個訂單返回訂單號。 ## 為什么需要這個接口 用戶在下單頁面點擊“提交訂單”時調用。 該接口需要同時完成訂單記錄創(chuàng)建、庫存預占、優(yōu)惠券鎖定三個動作。 ## 為什么不用事務 訂單記錄和庫存預占是跨庫操作無法使用單庫事務。 當前方案通過本地消息表實現(xiàn)最終一致性具體流程見[鏈接]。 ## 調用方注意事項 - 冪等請求頭需要帶 requestId服務端用唯一索引做去重 - 超時默認超時 3 秒超時后客戶端可以重試但不要無限重試 - 降級如果庫存服務不可用訂單仍可創(chuàng)建但狀態(tài)變?yōu)?PENDING。這種文檔的意義在于把“強者”腦子里那層無法直接看到的判斷邏輯顯性化。新人遇到問題時先看文檔的“為什么”部分很大概率能找到答案而不是立刻跑來打斷“強者”的深度工作。6.3 結對編程是最高效的知識轉移方式如果你想真正把經(jīng)驗和思路傳給一個“弱者”最有效的辦法不是開會不是發(fā)文檔而是坐在一起寫代碼。用結對編程的方式強者只負責引導和提問讓弱者自己動手每完成一個關鍵步驟就停下來討論“為什么這么做”。結對時強者可以參考下面的提問節(jié)奏“你打算怎么設計這個接口的入?yún)ⅰ薄叭绻@個查詢慢你會從哪里開始排查”“這個狀態(tài)流轉有沒有可能走到中間態(tài)”“如果失敗了用戶看到的提示是什么”這些問題本身就是在教對方“強者是怎么思考的”。比直接扔給他一段“標準答案”有效得多。7. 常見問題與排查思路在實際工程中“變強之后怎么和弱者協(xié)作”這個問題經(jīng)常表現(xiàn)為一些非常具體的場景。下面整理幾個高頻場景的處理思路供大家參考。問題現(xiàn)象可能原因排查方式解決方案新人提交的代碼被 review 打回后不敢再提交評審意見太抽象或語氣帶攻擊性和對方聊聊看卡點是技術問題還是心理壓力具體指出問題位置給出修改示例不要給出整體性負面評價老系統(tǒng)代碼太亂新人抱怨看不懂缺乏模塊級文檔代碼注釋少收集新人閱讀代碼時的具體卡點判斷是業(yè)務邏輯難還是代碼結構難先補模塊說明文檔再按業(yè)務主流程整理代碼注釋重構過程中行為發(fā)生意外變化測試覆蓋不足行為未凍結對比重構前后的輸入輸出樣例定位差異分支補測試后再重構每次改動保持小步提交頻繁驗證強者提出重寫方案團隊意見分裂方案沒有量化風險和收益要求給出收益指標、風險清單、回滾方案先做行為凍結和測試覆蓋再小范圍試點Code Review 里爭論語氣越來越激烈雙方開始“對人不對事”陷入了面子之爭暫停討論回到具體技術標準和客觀數(shù)據(jù)約定評審規(guī)則只討論問題不評價人只引用代碼和運行結果作為依據(jù)團隊依賴某個強者一走就癱瘓知識只集中在該強者的腦子里審視關鍵模塊的文檔和代碼可讀性實行輪崗 review、結對編程、文檔強制沉淀8. 最佳實踐與工程建議聊到這里把前面所有內容沉淀成一份可執(zhí)行的建議清單。8.1 對“弱代碼”先凍結再重構不推倒任何重構開始前先寫下當前行為的關鍵用例讓測試變成安全網(wǎng)每次重構只改一個維度不要同時調整結構和業(yè)務邏輯重構后的代碼必須過一遍 “命名是否清楚、函數(shù)是否短、調用方是否容易理解” 這三關盡量不要用“重寫”替代“重構”只有在完全廢棄舊系統(tǒng)時才考慮重寫。8.2 對“弱系統(tǒng)”先止血再優(yōu)化不鄙視線上系統(tǒng)不穩(wěn)定時第一優(yōu)先級是止血不要借機做架構改造給弱系統(tǒng)加監(jiān)控、加日志、加告警比加新功能更重要用穩(wěn)定性指標驅動改造不要用“代碼難看”驅動改造老系統(tǒng)的技術債要可視化列成清單標記影響范圍逐步削減。8.3 對“弱同事”先對齊再指導不貶低對齊標準把這些寫在團隊規(guī)范里讓所有評審基于規(guī)范而不是基于個人偏好指導時多問為什么少給“正確代碼”讓對方自己推導出答案建設知識庫把常見問題、踩坑記錄、設計決策沉淀成文檔遇到對方暫時理解不了的情況不要甩一句“這你都不明白”可以換一個類比角度再講一遍。8.4 對自己的定位從寫代碼的人變成影響代碼的人當你變強之后你的產出不再只是你自己寫了多少行代碼而是你讓整個系統(tǒng)的質量水位提升了多少。一個簡單但有效的自我審視問題是這個月你有沒有讓另一個人的代碼質量變好這個月你有沒有讓一個老模塊更容易維護這個月你有沒有讓團隊少踩一個之前會踩的坑如果這三個問題的答案都是否定的那么哪怕你再強對團隊和系統(tǒng)的貢獻也是有限的。9. 真正的強者姿態(tài)讓弱者不再需要被“侮辱”回到標題那個“我都變成強者了不侮辱一下弱者我變強還有什么意義”的問題。玩梗歸玩梗在工程世界里答案其實是非常明確的你變強的意義在于你能把原來只有你會做的事變成很多人都會做的事把原來很容易崩的系統(tǒng)變成不容易崩的系統(tǒng)把原來只靠人肉維護的流程變成靠工具自動保障的流程。當你真正做到了這些你根本不需要通過貶低別人來確認自己強。系統(tǒng)穩(wěn)定性、團隊產出、新人成長速度這些才是實力的真實注腳。如果你現(xiàn)在剛好處在“感覺自己變強了”的階段我建議你做一件很具體的事找一個你早就看不順眼的舊模塊不要抱怨它給它的核心邏輯補上三個測試然后在不改變行為的前提下把最亂的函數(shù)拆成兩個清晰的函數(shù)。做完之后你會感到一種完全不同于嘲諷弱者的踏實感。這才是變強之后真正有意義的事。