我的 CodeReview 实战经验

背景

Code Review 是大家日常开发过程中很常见的流程，当然也不排除一些团队为了快速上线，只要功能测试没问题就直接省去了 Code Review。

我个人觉得再忙的团队 Code Review 还是很有必要的（甚至可以事后再 Review），好处很多：

• 跳出个人开发的思维误区，更容易发现问题
• 增进团队交流，提高整体的技术氛围
• 团队水平检测器，不管是审核者还是被审核的，review 几次后大概就知道是什么水平了

通常 Code Review 有两种场景，一种是公司内部，还有就是开源社区。

开源社区

先说开源社区，最近也在做 cim 项目里做 Review，同时也在 Pulsar、OpenTelemetry、StarRocks 这些项目里做过 Reviewer。

以下是一些我参与 Code Review 的一些经验：

先提 issue

在提交 PR 进行 Code Review 之前最好先提交一个 issue 和社区讨论下，你的这个改动社区是否接受。

我见过一些事前没有提前沟通，然后提交了一个很复杂的 PR，会导致维护者很难 Review，同时也会打击参与者的积极性。

所以强烈建议一些复杂的修改一定先要提前和社区沟通，除非这是一些十拿九稳的问题。

个人 CI

一些大型项目往往都有完善的 CI 流程来保证代码质量，通常都有以下的校验：

• 各种测试流程（单元测试、集成测试）
• 代码 Code Style 检测
• 安全、依赖检测等

如果一个 PR 连 CI 都没跑过，其实也没有提前 Review 的必要了，所以在提 PR 之前都建议先在自己的 repo 里将主要的 CI 都跑过再提交 PR。

这个在 Pulsar 的官方贡献流程里也有单独提到。

同时在 PR 模板里也有提到，建议先在自己的 fork 的 repo 里完成 CI 之后再提交到 upstream。

这个其实也很简单，我们只要给自己的 repo 提交一个 PR，然后在 repo 设置中开启 Action，之后就会触发 CI 了。

如果自己的 PR 还需要频繁的提交修改，那建议可以先修改为 draft，这样可以提醒维护者稍后再做 Review。

同时也不建议提交一个过大的 PR，尽量控制在 500 行改动以内，这样才方便 Review。

Review 代码

Github 有提供代码对比页面，但也只是简单的代码高亮，没法像 IDE 这样提供函数跳转等功能。

所以对于 Reviewer 来说，最好是在本地 IDE 中添加 PR 的 repo，这样就可以直接切换到 PR 的分支，然后再本地跟代码，也更好调试。

有相关的修改建议可以直接在 github 页面上进行评论，这样两者结合起来 Review，效率会更高。

Review 代码其实不比写代码轻松，所以对免费帮你做 Review 的要多保持一些瑞思拜。

AI Review

现在 Github 已经支持 copilot 自动 Review 了，它可以帮我们总结变更，同时对一些参加的错误提供修改建议。

使用它还是可以帮我们省不少事情，推荐开启。

企业内部

在企业内部做 Code Review 流程上要简单许多，毕竟沟通成本要低一些，往往都是达成一致之后才会开始开发，所以重点就是 Review 的过程了。

既然是在公司内部，那就要发挥线下沟通的优势了；当然在开始前还是建议在内部的代码工具里比如说 gitlab 中提交一个 MR，先让参会人员都提前看看大概修改了哪些内容，最好是提前在 gitlab 中评论，带着问题开会讨论。

实际 Review 过程应该尽量关注业务逻辑与设计，而不是代码风格、格式等细枝末节的问题。

提出修改意见的时候也要对事不对人，我见过好几次在 Review 现场吵起来的场景，就是代入了一些主观情绪，被 Review 的觉得自己能力被质疑，从而产生了一些冲突。

Code Review 做得好的话整个团队都会一起进步，对个人来说参与一些优质开源项目的 Code Review 也会学到很多东西。

评审的艺术——谈谈现实中的代码评审

这篇讲的是代码评审的实践智慧——那些很难从课本学到、却在日常团队协作中至关重要的经验。作者从自身出发，认为代码创造本身就带有个性，评审时过度追求一致既不现实也容易扼杀活力。他坦言评审风格因人而异，有人温和、有人直接，而自己更倾向于对事不对事地坚持原则。 文章将评审问题分为三类：需求业务层面、代码结构层面和风格格式层面。前两者可能成为合并代码的阻碍，而后者通常不是关键。作者分享了一套沟通技巧：比如为风格问题标注“picky”以降低火药味；多用“也许”“可能”等虚拟语气缓和建议；或是用提问代替断言（如“为什么这里用3？”）。他还强调，评审应“先抓主干”，遇到满是问题的代码时，先聚焦核心设计缺陷而非细枝末节。 一个有趣的观点是，评审标准不必完全统一。对新项目代码和新人提交的代码要求应更严格，前者影响后续质量基调，后者关乎职业习惯养成。最后作者指出，若对业务或技术背景不熟，勉强评审反而有害，此时不如坦诚沟通、确保质量。整篇文章没有空谈流程，而是像一位经验丰富的工程师在分享如何在真实团队中让评审变得高效而有人情味。

Python 代码规范小结

这是一份从实践中总结的 Python 代码编写规范清单。作者从一次 code review 的小结出发，强调了两个核心原则：一切都与复杂度有关，以及代码应当易于理解。 文章将规范具体化到了编码的各个环节。在基础风格上，它指出代码被阅读的次数远多于编写和修改的次数，因此可读性至关重要。接着，文章系统性地梳理了注释、命名、常量、变量、数据结构以及表达式的写法，并深入到了控制流（分支、循环、异常处理）的具体实现建议。对于函数和类的设计，文中也给出了相应的组织思路。最后，内容还延伸到了模块、抽象与整体设计层面。 特别值得一提的是，文章提出了一个评估项目可行性的公式：可行性=(当前价值+未来价值)/(实现成本+维护成本)，强调了降低长期维护成本的优先级。这些从具体语法细节到宏观设计思想的总结，为写出更规范、更易于维护的 Python 代码提供了清晰的路线图。

拒绝修复 bug 的几个正当理由

这篇讲的是：在软件开发中，一味地、立即修复所有 bug 可能并非最佳实践。 作者从代码质量与项目长期健康度的视角出发，提出了四个可以“正当”拒绝 bug 修复的理由。首先，草率的修复常通过删除或跳过单元测试来让构建通过，这实质上降低了测试覆盖率，为系统埋下隐患。其次，一个合格的修复应包含能重现该 bug 的测试用例，否则只是掩盖问题，无法防止修复行为本身引入更多“熵”。再者，bug 修复应保持小而专注，避免与代码重构混杂在一起，否则会使补丁难以审查和理解。最后，一次 pull request 应只处理一个 bug，确保修改的纯粹性和可追溯性。 作者的核心观点是，bug 修复的纪律比程序员良好的重构意图更重要。有时，要求提交者完善测试、拆分补丁，是比简单合入代码更负责任的选择。文章通过具体的技术场景，为团队代码评审和维护流程提供了一套清晰的思考框架。

如果代码审查时你忘记了拿近视眼镜

这篇讲的是代码审查中那些破坏可读性的常见“坏味道”。作者用了一个有趣的比喻：当你忘记戴近视眼镜时，看代码就只能依赖整体的“形态”和“结构”。这恰恰点出了代码审查的本质——我们有时需要暂时忽略实现细节，去审视代码的骨架是否健康。 文章通过六个生动的代码片段示例，具体演示了哪些设计会让“模糊的你”一眼就觉得不对劲。比如，把 `UserCreator` 的职责过分简化，导致创建一个简单的对象都需要在一堆小文件中寻觅；或者反其道而行之，让一个类塞进太多无关的方法，伪装成一个“全能”类。再比如，方法被拆得过于碎片化，使得逻辑追踪令人头疼；以及命名空间嵌套深达六层，让代码定位变得曲折。 作者指出，这些做法虽然在技术上可能“能运行”，却为人脑的理解设置了不必要的障碍。一个拥有8个参数的方法、一段需要长篇注释才能理解的逻辑，都在无声地增加协作与维护的成本。 最终，文章的落点在于：清爽、简洁、结构良好的代码是高效团队协作的基石。忽视代码的“可读性设计”，无论初衷多么良好，终将反噬项目本身。

代码审查：ThoughtBot官方给出的代码审查指导原则

这篇讲的是如何让代码审查变得更高效、更友好。作者从 ThoughtBot 的官方指南出发，总结了在 GitHub 上进行代码审查时，审查者和被审查者双方都应遵循的一系列核心原则。 文章为审查者提供了具体的沟通心法：要记住编程主张常是个人观点，因此应多提问少命令、请求说明而非指责、避免代码归属之争，并且绝不能人身攻击。审查评论应清晰谦逊，避免使用“总是”“从不”等夸张修辞。如果讨论过于深入，可以转到线下进行。 而对于被审查的代码作者，文章建议要主动感谢建议、理解对事不对人、解释代码背后的思考，并在一个独立的 push 提交中集中处理反馈。关键流程包括：基于反馈更新代码、注明审查链接、等待所有审查者退出后再合并，并确保持续集成测试通过。 此外，文章还提倡建立统一的代码风格指南。当出现分歧时，应在指南仓库中发起讨论，而非在审查评论中争论。这些具体而微的实践，旨在将代码审查从一场潜在的技术辩论，转变为一次促进团队学习和代码质量提升的协作。

我自己研究开源项目源代码的两个重要习惯

这篇讲的是作者在长期研究开源项目源代码时，逐渐沉淀出的两个核心工作习惯：撰写代码流程分析文档，以及编写不同场景的测试用例。文章以分析 HBase 的 HMaster 和 HRegionServer 启动流程为例，具体展示了这些习惯是如何落地的。 作者并非一开始就追求完美的分析。他会在文档中按方法调用顺序梳理流程，允许自己留下未完全理解的“TODO”标记，甚至可能包含一些初期的错误理解。这份文档会随着研究的深入，经过多次反复和迭代而不断完善。关键的是，他会将这份“过程文档”提交到版本库中，既为了保存，也为了记录自己的理解历程。 文章贴出了一段真实的、略显“粗糙”的分析记录作为示例。我们可以看到，从构造 ZooKeeper 节点、生成核心组件，到复杂的初始化与分配逻辑，每一步都被尽可能细致地追踪和记录下来。这份文档的价值在“冷启动”时尤为明显——当作者时隔数月后需要重新投入某个项目时，对照着这份自己写的、充满个人注解的文档，能迅速恢复到当初的理解水平，避免了从零开始的巨大时间成本。 这两个看似“普通”的习惯，其威力在于将抽象、易逝的阅读和思考过程，转化为了具体、可版本化管理的资产。对于需要长期维护或间歇性深入的复杂代码库而言，这是一种极为高效的知识管理策略。

聊聊Code Review

这篇讲的是Code Review，但切入点有点不一样——它从一个关于“那一点的调用”的评论讨论出发。作者hopesfish的提问，指向了一个更实际也更常被团队忽视的问题：代码评审到底在评什么？ 文章的核心观点很明确，它认为一次有效的Code Review，重点不应仅仅是发现表面的代码错误。更深层次的价值在于，它是团队成员之间一次“思维同步”的机会。比如，通过讨论一个调用的设计，其实是在对齐对业务逻辑的理解、对架构意图的共识，甚至是对“好代码”标准的认同。这种交流能避免后续开发中因理解偏差导致的返工。 作者由此引申开，探讨了Review文化中的常见困境：比如，审查者是只抓细枝末节，还是关注整体设计？被审查者是感到被挑战，还是看作共同学习的机会？这篇文章没有给出标准答案，而是通过一个具体的讨论案例，启发读者去反思自己团队中Code Review的实际状态和潜在价值。 它提醒我们，技术实践的效果，往往取决于背后团队协作与沟通的“那一点”微妙之处。

为什么要结对编程？

这篇讲的是结对编程（Pair Programming）的实践价值，它并非只是两个人坐在一起敲代码。作者从ThoughtWorks内部的讨论出发，解构了许多团队对结对编程的刻板印象。文章指出，结对编程的核心远超传统的“一人写，一人看”模式，它更像是一种实时的知识传递和协作式的设计过程。 文章深入探讨了结对编程如何发生在需求分析和软件设计阶段，而不仅仅是在编码时。作者分享了实际观察：当两名开发者结对时，他们能更快地厘清模糊需求，并在编写第一行代码前，就通过讨论发现潜在的逻辑漏洞。一个常见的发现是，结对中产生的思维碰撞，往往能催生出比单独思考更简洁、更具扩展性的解决方案。 此外，文章也直面了实践中的挑战，比如如何维持结对的专注度、如何安排轮换节奏以最大化收益。它最终引导读者思考：在追求高效交付的同时，结对编程通过提升代码质量与团队知识共享水平，实质上降低了整个项目周期的长期成本与风险。这为那些在“个人效率”与“团队稳健”之间权衡的技术管理者，提供了一个扎实的分析视角。

抵制代码重写

这篇讲的是，当开发者面对一个逐渐臃肿、难以维护的遗留系统时，“推倒重写”往往是一个极具诱惑力的选项。作者从大量实际项目经验出发，剖析了这种诱惑背后的陷阱。 他指出，重写项目常被乐观地估计，却极易陷入无限循环的泥潭：新系统需要实现旧系统里所有已知甚至未知的业务逻辑，而这些逻辑往往已无文档，只存在于少数资深员工的脑中或陈旧代码的缝隙里。这个过程不仅耗费巨大，还可能丢失关键的隐性知识，导致新系统反而不如旧系统稳定。 文章的核心观点是：除非系统已彻底腐化到无法维护，否则应首先考虑“抵制重写”的冲动。作者主张，更稳妥的路径是采取渐进式重构，在持续交付价值的同时，一步步改善代码质量与架构。这对于维护关键业务的系统尤为重要，因为稳定性与可预测性远胜于一次高风险的重置。

关于这段时间的技术评审

这篇讲的是作者团队近期在实践技术评审时的一些观察和思考。他们发现，纯粹依赖评审会上的讨论，有时效果有限，于是开始梳理和定义更前置的评审动作。例如，将设计文档的关键决策点拆解出来，在正式评审前就进行一轮异步的、小范围的预审，目的是过滤掉方向性分歧，让大会聚焦于更具体的实现细节和风险。文章也反思了评审中常见的“大家不说反对就是同意”的误区，并强调了明确评审结论和行动项跟踪的重要性。其核心观点是，高效的评审不是一次性的会议，而是一个嵌入开发流程、有明确责任分工的持续沟通机制。对于想提升团队工程效率的读者，文中关于“评审重心前移”和“闭环管理”的实践总结，提供了可操作的参考。

关于"谦虚一点去工作"背后的故事

这篇文章是作者对之前《谦虚一点去工作》一文引发的讨论进行的回应与澄清。从文章标题和简短的描述来看，它属于**事件复盘/观点类**内容，核心是回应评论区中对作者“妒贤忌能、独断专横”的误解。 作者从《谦虚一点去工作》一文发布后读者的强烈反应出发，坦言自己“吓了一跳”，并坦诚地梳理了大家产生这种印象的原因。文章聚焦于一次具体的观点输出如何引发了意外的舆论反馈，核心在于剖析误解产生的过程，并隐含了作者对于职场沟通、表达方式与接收效果之间关系的反思。 对于读者而言，这篇文章的启发在于：一句简单的工作建议，在脱离具体语境和背景后，可能被解读出截然不同的含义。它提醒技术人，在分享观点时，清晰的表述和上下文的铺垫同样重要。

养成良好的习惯

作者从自己之前引发的讨论《以习惯对抗虚无》出发，深入探讨了人们在践行“好习惯”时普遍遇到的两个实际障碍。一方面，许多公认有益的习惯（如定期整理、基础学习）因显得“意义不够宏大”，难以提供足够的启动动力；另一方面，随着年龄增长，固有行为模式让培养新习惯的阻力显著增大。 这篇文章直面了“知易行难”的困境，并尝试拆解“说服自己行动”背后的心理与执行机制。它没有停留在强调习惯重要性，而是将问题具体化：如何为“小而好”的习惯赋予即时反馈？又该如何调整策略，以适应不同人生阶段的可塑性？ 对于那些认同习惯力量却总在第一步徘徊的技术人来说，文中对这两个痛点的剖析，或许能提供一种更务实的思考起点——不是追求完美的习惯清单，而是找到撬动自己日常的那个最小杠杆。

成长的艰辛

这篇讲的是作者在步入职场半年后的一次自我剖析。当大学同学突然问起“工作后最大的变化是什么”时，作者一时语塞，支吾半天也找不到答案，只能回应“让我想一想”，但思考许久仍未得出结论。这个简单的对话场景，像一段

最大的对手

这篇探讨的是个人与企业共同的成长瓶颈——那面让我们直面自身的镜子。作者开篇就点破了一个悖论：我们常常向外寻找“最大的对手”，认为是那些明确的竞争者阻碍了道路，但真正的束缚往往来自内部。 文章的核心观点很直接：那个“阻挡着、束缚着”我们的对手，其实很容易找到——“照一下镜子就看到了”。这意味着固有的思维模式、难以打破的习惯、对现状的满足，或是拒绝改变的恐惧，这些才是更难逾越的障碍。无论是想突破技术瓶颈的工程师，还是寻求增长的企业，向外竞争是常态，但向内革新才是真正的突破点。 这篇短文没有提供具体方法，却提出了一个根本性的方向：真正的成长，始于承认并致力于超越那个镜子里的自己。它提醒我们，在所有的战略、技术、竞争分析之前，或许应该先完成一次诚实的自我审视。