[{"data":1,"prerenderedAt":694},["ShallowReactive",2],{"content-/topics/engineering/code-review-art-and-practice":3},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":9,"date":10,"category":5,"tags":11,"author":17,"featured":18,"series":19,"seriesOrder":20,"readingTime":21,"image":22,"body":23,"_type":688,"_id":689,"_source":690,"_file":691,"_stem":692,"_extension":693},"/topics/engineering/code-review-art-and-practice","engineering",false,"","Code Review 的艺术与实战：指出问题，不制造敌意","Code Review 的价值不在于“谁更会挑刺”，而在于提升决策质量、传递团队标准、降低系统性风险。本文从 review 目标、评论方式、风险分层、常见冲突和可执行清单五个维度，讲清高质量 Code Review 如何真正落地。","2026-04-25",[12,13,14,15,16],"Code Review","团队协作","工程治理","开发流程","技术领导力","小明",true,"team-engineering-growth",1,13,"/images/articles/code-review-art-and-practice-cover.jpg",{"type":24,"children":25,"toc":666},"root",[26,34,40,55,60,65,84,89,93,100,105,110,123,128,133,142,145,151,156,161,168,173,179,184,190,195,201,206,211,214,220,225,230,248,253,261,266,279,282,288,293,298,403,408,411,417,422,430,435,440,458,463,466,472,477,482,505,510,515,523,526,532,538,543,549,554,560,565,568,574,579,622,625,630,653,658],{"type":27,"tag":28,"props":29,"children":31},"element","h1",{"id":30},"code-review-的艺术与实战指出问题不制造敌意",[32],{"type":33,"value":8},"text",{"type":27,"tag":35,"props":36,"children":37},"p",{},[38],{"type":33,"value":39},"Code Review 在很多团队里，有两种极端命运：",{"type":27,"tag":41,"props":42,"children":43},"ul",{},[44,50],{"type":27,"tag":45,"props":46,"children":47},"li",{},[48],{"type":33,"value":49},"一种是形式主义，点两下“LGTM”，像在盖章",{"type":27,"tag":45,"props":51,"children":52},{},[53],{"type":33,"value":54},"一种是情绪战场，评论区像程序员版辩论节目",{"type":27,"tag":35,"props":56,"children":57},{},[58],{"type":33,"value":59},"这两种都不是真正的 Review。",{"type":27,"tag":35,"props":61,"children":62},{},[63],{"type":33,"value":64},"高质量 Code Review 的核心，不是让提交者感到“被考核”，也不是让审阅者显得“很懂”。它真正的作用是三件事：",{"type":27,"tag":66,"props":67,"children":68},"ol",{},[69,74,79],{"type":27,"tag":45,"props":70,"children":71},{},[72],{"type":33,"value":73},"在代码进入主干前，降低明显风险",{"type":27,"tag":45,"props":75,"children":76},{},[77],{"type":33,"value":78},"把团队标准通过具体例子传递下去",{"type":27,"tag":45,"props":80,"children":81},{},[82],{"type":33,"value":83},"帮助方案决策变得更稳，而不是更吵",{"type":27,"tag":35,"props":85,"children":86},{},[87],{"type":33,"value":88},"所以 Code Review 从来不是“评论代码”这么简单，它本质上是团队如何共同思考的一面镜子。",{"type":27,"tag":90,"props":91,"children":92},"hr",{},[],{"type":27,"tag":94,"props":95,"children":97},"h2",{"id":96},"_1-先纠正一个误解review-的对象不是人而是变更",[98],{"type":33,"value":99},"1. 先纠正一个误解：Review 的对象不是人，而是变更",{"type":27,"tag":35,"props":101,"children":102},{},[103],{"type":33,"value":104},"很多 review 气氛紧张，是因为大家下意识把评论理解成对人的评价。",{"type":27,"tag":35,"props":106,"children":107},{},[108],{"type":33,"value":109},"比如这两句话，技术内容几乎一样，但效果完全不同：",{"type":27,"tag":41,"props":111,"children":112},{},[113,118],{"type":27,"tag":45,"props":114,"children":115},{},[116],{"type":33,"value":117},"“你这个写法有问题。”",{"type":27,"tag":45,"props":119,"children":120},{},[121],{"type":33,"value":122},"“这个实现如果数据量上来，可能会有性能风险。”",{"type":27,"tag":35,"props":124,"children":125},{},[126],{"type":33,"value":127},"第一句在评价人，第二句在描述变更后果。",{"type":27,"tag":35,"props":129,"children":130},{},[131],{"type":33,"value":132},"成熟的 Review 文化有一个基本原则：",{"type":27,"tag":134,"props":135,"children":136},"blockquote",{},[137],{"type":27,"tag":35,"props":138,"children":139},{},[140],{"type":33,"value":141},"不去讨论“你行不行”，而去讨论“这次改动在什么条件下会不会出问题”。",{"type":27,"tag":90,"props":143,"children":144},{},[],{"type":27,"tag":94,"props":146,"children":148},{"id":147},"_2-review-最该看什么不该看什么",[149],{"type":33,"value":150},"2. Review 最该看什么，不该看什么",{"type":27,"tag":35,"props":152,"children":153},{},[154],{"type":33,"value":155},"如果一个 PR 很大，而你还把主要精力放在空格和分号上，那说明流程设计有问题。",{"type":27,"tag":35,"props":157,"children":158},{},[159],{"type":33,"value":160},"格式问题应该交给自动化，Review 应该优先看四个层面：",{"type":27,"tag":162,"props":163,"children":165},"h3",{"id":164},"_21-正确性",[166],{"type":33,"value":167},"2.1 正确性",{"type":27,"tag":35,"props":169,"children":170},{},[171],{"type":33,"value":172},"它真的实现了需求吗？边界条件有没有漏？",{"type":27,"tag":162,"props":174,"children":176},{"id":175},"_22-可维护性",[177],{"type":33,"value":178},"2.2 可维护性",{"type":27,"tag":35,"props":180,"children":181},{},[182],{"type":33,"value":183},"半年后别的同事读这段代码，能推理出它的意图吗？",{"type":27,"tag":162,"props":185,"children":187},{"id":186},"_23-系统影响面",[188],{"type":33,"value":189},"2.3 系统影响面",{"type":27,"tag":35,"props":191,"children":192},{},[193],{"type":33,"value":194},"这个改动是否改变了性能、缓存、权限、数据一致性等关键约束？",{"type":27,"tag":162,"props":196,"children":198},{"id":197},"_24-测试与回滚",[199],{"type":33,"value":200},"2.4 测试与回滚",{"type":27,"tag":35,"props":202,"children":203},{},[204],{"type":33,"value":205},"如果它出问题，团队能多快发现、如何回退？",{"type":27,"tag":35,"props":207,"children":208},{},[209],{"type":33,"value":210},"这四件事，才是 Review 的主战场。",{"type":27,"tag":90,"props":212,"children":213},{},[],{"type":27,"tag":94,"props":215,"children":217},{"id":216},"_3-一个更专业的评论方式结论-原因-建议",[218],{"type":33,"value":219},"3. 一个更专业的评论方式：结论 + 原因 + 建议",{"type":27,"tag":35,"props":221,"children":222},{},[223],{"type":33,"value":224},"很多差评式 review 的问题，不在“说得太直”，而在“只给否定，不给上下文”。",{"type":27,"tag":35,"props":226,"children":227},{},[228],{"type":33,"value":229},"更好的评论模板是：",{"type":27,"tag":66,"props":231,"children":232},{},[233,238,243],{"type":27,"tag":45,"props":234,"children":235},{},[236],{"type":33,"value":237},"结论：指出关注点",{"type":27,"tag":45,"props":239,"children":240},{},[241],{"type":33,"value":242},"原因：解释为什么这是问题",{"type":27,"tag":45,"props":244,"children":245},{},[246],{"type":33,"value":247},"建议：给出替代方向",{"type":27,"tag":35,"props":249,"children":250},{},[251],{"type":33,"value":252},"例如：",{"type":27,"tag":134,"props":254,"children":255},{},[256],{"type":27,"tag":35,"props":257,"children":258},{},[259],{"type":33,"value":260},"这里把权限逻辑写死在组件里，后面多角色扩展会比较难维护。建议把权限判断提到独立策略层，页面只消费结果。",{"type":27,"tag":35,"props":262,"children":263},{},[264],{"type":33,"value":265},"这样的评论有两个好处：",{"type":27,"tag":41,"props":267,"children":268},{},[269,274],{"type":27,"tag":45,"props":270,"children":271},{},[272],{"type":33,"value":273},"提交者知道你在担心什么",{"type":27,"tag":45,"props":275,"children":276},{},[277],{"type":33,"value":278},"团队标准被显性化，不再靠“悟”",{"type":27,"tag":90,"props":280,"children":281},{},[],{"type":27,"tag":94,"props":283,"children":285},{"id":284},"_4-review-不该追求全知全能而该追求风险分层",[286],{"type":33,"value":287},"4. Review 不该追求“全知全能”，而该追求风险分层",{"type":27,"tag":35,"props":289,"children":290},{},[291],{"type":33,"value":292},"一个成熟团队不会要求每个 reviewer 对所有改动都给出同等深度意见。",{"type":27,"tag":35,"props":294,"children":295},{},[296],{"type":33,"value":297},"更现实的做法是分层：",{"type":27,"tag":299,"props":300,"children":301},"table",{},[302,326],{"type":27,"tag":303,"props":304,"children":305},"thead",{},[306],{"type":27,"tag":307,"props":308,"children":309},"tr",{},[310,316,321],{"type":27,"tag":311,"props":312,"children":313},"th",{},[314],{"type":33,"value":315},"风险类型",{"type":27,"tag":311,"props":317,"children":318},{},[319],{"type":33,"value":320},"重点由谁看",{"type":27,"tag":311,"props":322,"children":323},{},[324],{"type":33,"value":325},"关注点",{"type":27,"tag":327,"props":328,"children":329},"tbody",{},[330,349,367,385],{"type":27,"tag":307,"props":331,"children":332},{},[333,339,344],{"type":27,"tag":334,"props":335,"children":336},"td",{},[337],{"type":33,"value":338},"业务逻辑",{"type":27,"tag":334,"props":340,"children":341},{},[342],{"type":33,"value":343},"需求上下文最清楚的人",{"type":27,"tag":334,"props":345,"children":346},{},[347],{"type":33,"value":348},"是否符合预期、边界是否完整",{"type":27,"tag":307,"props":350,"children":351},{},[352,357,362],{"type":27,"tag":334,"props":353,"children":354},{},[355],{"type":33,"value":356},"架构影响",{"type":27,"tag":334,"props":358,"children":359},{},[360],{"type":33,"value":361},"核心维护者",{"type":27,"tag":334,"props":363,"children":364},{},[365],{"type":33,"value":366},"模块边界、长期可维护性",{"type":27,"tag":307,"props":368,"children":369},{},[370,375,380],{"type":27,"tag":334,"props":371,"children":372},{},[373],{"type":33,"value":374},"安全与权限",{"type":27,"tag":334,"props":376,"children":377},{},[378],{"type":33,"value":379},"有经验的 reviewer",{"type":27,"tag":334,"props":381,"children":382},{},[383],{"type":33,"value":384},"权限绕过、数据泄露、输入校验",{"type":27,"tag":307,"props":386,"children":387},{},[388,393,398],{"type":27,"tag":334,"props":389,"children":390},{},[391],{"type":33,"value":392},"性能与稳定性",{"type":27,"tag":334,"props":394,"children":395},{},[396],{"type":33,"value":397},"熟悉链路的人",{"type":27,"tag":334,"props":399,"children":400},{},[401],{"type":33,"value":402},"热路径、回滚点、异常处理",{"type":27,"tag":35,"props":404,"children":405},{},[406],{"type":33,"value":407},"这样做比“一个人全看完所有细节”更现实，也更可靠。",{"type":27,"tag":90,"props":409,"children":410},{},[],{"type":27,"tag":94,"props":412,"children":414},{"id":413},"_5-最伤害团队的不是严格-review而是不稳定的标准",[415],{"type":33,"value":416},"5. 最伤害团队的，不是严格 Review，而是不稳定的标准",{"type":27,"tag":35,"props":418,"children":419},{},[420],{"type":33,"value":421},"如果今天 reviewer A 说这类抽象太重，明天 reviewer B 又说抽象不够，提交者会迅速学会一种本能：",{"type":27,"tag":134,"props":423,"children":424},{},[425],{"type":27,"tag":35,"props":426,"children":427},{},[428],{"type":33,"value":429},"不是写好代码，而是猜 reviewer 心情。",{"type":27,"tag":35,"props":431,"children":432},{},[433],{"type":33,"value":434},"这会把工程协作变成政治游戏。",{"type":27,"tag":35,"props":436,"children":437},{},[438],{"type":33,"value":439},"所以好的 Review 文化，必须尽量把标准沉淀成公开规则：",{"type":27,"tag":41,"props":441,"children":442},{},[443,448,453],{"type":27,"tag":45,"props":444,"children":445},{},[446],{"type":33,"value":447},"哪些问题必须改",{"type":27,"tag":45,"props":449,"children":450},{},[451],{"type":33,"value":452},"哪些问题建议改",{"type":27,"tag":45,"props":454,"children":455},{},[456],{"type":33,"value":457},"哪些问题只是风格讨论",{"type":27,"tag":35,"props":459,"children":460},{},[461],{"type":33,"value":462},"标准越稳定，协作成本越低。",{"type":27,"tag":90,"props":464,"children":465},{},[],{"type":27,"tag":94,"props":467,"children":469},{"id":468},"_6-什么时候该在-pr-里讨论什么时候该另开设计讨论",[470],{"type":33,"value":471},"6. 什么时候该在 PR 里讨论，什么时候该另开设计讨论",{"type":27,"tag":35,"props":473,"children":474},{},[475],{"type":33,"value":476},"PR 不是万能会议室。",{"type":27,"tag":35,"props":478,"children":479},{},[480],{"type":33,"value":481},"如果分歧已经涉及：",{"type":27,"tag":41,"props":483,"children":484},{},[485,490,495,500],{"type":27,"tag":45,"props":486,"children":487},{},[488],{"type":33,"value":489},"领域模型怎么拆",{"type":27,"tag":45,"props":491,"children":492},{},[493],{"type":33,"value":494},"服务边界怎么定",{"type":27,"tag":45,"props":496,"children":497},{},[498],{"type":33,"value":499},"权限体系是不是要重构",{"type":27,"tag":45,"props":501,"children":502},{},[503],{"type":33,"value":504},"是否换一套技术路线",{"type":27,"tag":35,"props":506,"children":507},{},[508],{"type":33,"value":509},"这类问题继续在 PR 里来回拉扯，成本很高。因为 PR 适合讨论“这次变更如何更稳”，不适合承载“系统方向重新定义”。",{"type":27,"tag":35,"props":511,"children":512},{},[513],{"type":33,"value":514},"一个简单判断是：",{"type":27,"tag":134,"props":516,"children":517},{},[518],{"type":27,"tag":35,"props":519,"children":520},{},[521],{"type":33,"value":522},"如果讨论结果会影响未来一整批 PR，而不仅是当前这一个，那它应该升级成设计讨论，而不是继续耗在评论区。",{"type":27,"tag":90,"props":524,"children":525},{},[],{"type":27,"tag":94,"props":527,"children":529},{"id":528},"_7-review-里最常见的三种坏味道",[530],{"type":33,"value":531},"7. Review 里最常见的三种坏味道",{"type":27,"tag":162,"props":533,"children":535},{"id":534},"_71-只提问题不给判断标准",[536],{"type":33,"value":537},"7.1 只提问题，不给判断标准",{"type":27,"tag":35,"props":539,"children":540},{},[541],{"type":33,"value":542},"这会让提交者改得像抽盲盒。",{"type":27,"tag":162,"props":544,"children":546},{"id":545},"_72-只改局部不看系统后果",[547],{"type":33,"value":548},"7.2 只改局部，不看系统后果",{"type":27,"tag":35,"props":550,"children":551},{},[552],{"type":33,"value":553},"某段代码局部上更优雅，但如果引入了更重的耦合，整体上可能更差。",{"type":27,"tag":162,"props":555,"children":557},{"id":556},"_73-把-review-变成彰显资历的舞台",[558],{"type":33,"value":559},"7.3 把 Review 变成彰显资历的舞台",{"type":27,"tag":35,"props":561,"children":562},{},[563],{"type":33,"value":564},"一旦评论的隐藏目的变成“证明我更懂”，团队就会从协作转向防御。",{"type":27,"tag":90,"props":566,"children":567},{},[],{"type":27,"tag":94,"props":569,"children":571},{"id":570},"_8-一份实用-review-清单",[572],{"type":33,"value":573},"8. 一份实用 Review 清单",{"type":27,"tag":35,"props":575,"children":576},{},[577],{"type":33,"value":578},"每次 Review 可以快速过这 8 个问题：",{"type":27,"tag":66,"props":580,"children":581},{},[582,587,592,597,602,607,612,617],{"type":27,"tag":45,"props":583,"children":584},{},[585],{"type":33,"value":586},"这个改动真正解决了什么问题？",{"type":27,"tag":45,"props":588,"children":589},{},[590],{"type":33,"value":591},"有没有遗漏边界条件？",{"type":27,"tag":45,"props":593,"children":594},{},[595],{"type":33,"value":596},"命名和抽象是否贴近业务意图？",{"type":27,"tag":45,"props":598,"children":599},{},[600],{"type":33,"value":601},"是否影响性能、缓存、权限或一致性？",{"type":27,"tag":45,"props":603,"children":604},{},[605],{"type":33,"value":606},"失败时如何观测、如何回滚？",{"type":27,"tag":45,"props":608,"children":609},{},[610],{"type":33,"value":611},"测试是否覆盖关键路径？",{"type":27,"tag":45,"props":613,"children":614},{},[615],{"type":33,"value":616},"这次抽象是在降低复杂度，还是只是转移复杂度？",{"type":27,"tag":45,"props":618,"children":619},{},[620],{"type":33,"value":621},"评论是否针对代码，而不是针对人？",{"type":27,"tag":90,"props":623,"children":624},{},[],{"type":27,"tag":94,"props":626,"children":628},{"id":627},"总结",[629],{"type":33,"value":627},{"type":27,"tag":41,"props":631,"children":632},{},[633,638,643,648],{"type":27,"tag":45,"props":634,"children":635},{},[636],{"type":33,"value":637},"Code Review 的目标是降低风险、传递标准、提升共同决策质量。",{"type":27,"tag":45,"props":639,"children":640},{},[641],{"type":33,"value":642},"高质量评论应该做到结论、原因、建议三件事都清楚。",{"type":27,"tag":45,"props":644,"children":645},{},[646],{"type":33,"value":647},"Review 的核心不是面面俱到，而是风险分层和标准稳定。",{"type":27,"tag":45,"props":649,"children":650},{},[651],{"type":33,"value":652},"真正差的 Review，不是严格，而是情绪化、随意化、政治化。",{"type":27,"tag":35,"props":654,"children":655},{},[656],{"type":33,"value":657},"小明收尾一句：",{"type":27,"tag":134,"props":659,"children":660},{},[661],{"type":27,"tag":35,"props":662,"children":663},{},[664],{"type":33,"value":665},"好的 Code Review 不是把人审怕，而是把系统里那些“本来会晚点爆炸的问题”提前温柔地拆掉。",{"title":7,"searchDepth":667,"depth":667,"links":668},3,[669,671,677,678,679,680,681,686,687],{"id":96,"depth":670,"text":99},2,{"id":147,"depth":670,"text":150,"children":672},[673,674,675,676],{"id":164,"depth":667,"text":167},{"id":175,"depth":667,"text":178},{"id":186,"depth":667,"text":189},{"id":197,"depth":667,"text":200},{"id":216,"depth":670,"text":219},{"id":284,"depth":670,"text":287},{"id":413,"depth":670,"text":416},{"id":468,"depth":670,"text":471},{"id":528,"depth":670,"text":531,"children":682},[683,684,685],{"id":534,"depth":667,"text":537},{"id":545,"depth":667,"text":548},{"id":556,"depth":667,"text":559},{"id":570,"depth":670,"text":573},{"id":627,"depth":670,"text":627},"markdown","content:topics:engineering:code-review-art-and-practice.md","content","topics/engineering/code-review-art-and-practice.md","topics/engineering/code-review-art-and-practice","md",1777109940703]