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