1. 从零搭建代码评审工具：为什么我要造这个轮子
代码评审这件事，做过团队协作开发的人都懂——它既是保证代码质量最有效的手段，也是最容易流于形式的环节。我待过几个不同规模的研发团队，从五六人的小作坊到几十人的中型团队，代码评审的落地效果差异极大。小团队里大家面对面沟通，评审往往就是一句“你帮我瞅一眼”；团队一大，评审就变成了流程里的一个卡点，点个“通过”就算完事。时间长了，代码里的坏味道越积越多，等到线上出问题再回头查，成本已经翻了好几倍。
市面上成熟的代码评审平台不少，功能也很强大，但它们有个共同的问题：重。要么需要绑定特定的代码托管平台，要么需要部署一整套服务端组件，要么按人头收费价格不菲。对于一个只想在本地快速跑一遍静态检查、或者想在自己的小项目里加一道轻量级质量门禁的开发者来说，这些方案都显得杀鸡用牛刀。更关键的是，很多工具把评审逻辑封装成了黑盒，你只知道它报了问题，却不知道它为什么报、依据是什么、能不能按自己的规则来调整。
open-code-review这个项目就是在这个背景下冒出来的想法。它的定位很明确：一个开放、轻量、可定制的代码评审工具集。所谓“开放”，是指评审规则、检查逻辑、报告格式全部透明可查，你可以清楚地知道每一条建议是怎么产生的；所谓“轻量”，是指它不依赖任何特定的代码托管服务，不需要复杂的服务端部署，一条命令就能在本地跑起来；所谓“可定制”，是指你可以根据自己的团队规范，增删改查评审规则，让它真正贴合你的开发习惯。
这篇文章适合三类人看：第一类是想了解代码评审工具内部原理的开发者，第二类是想给自己项目加一道质量门禁但不想引入重型方案的独立开发者，第三类是对静态分析、代码质量度量感兴趣的技术爱好者。我会从核心需求拆解开始，一步步讲清楚这个工具的设计思路、关键技术点、实操步骤，以及我在开发和试用过程中踩过的坑。文章里涉及的具体实现细节，有些是基于常见实践的合理补充，我会在相应位置说明。
2. 核心需求拆解：一个轻量评审工具到底要解决什么问题
2.1 评审场景的真实痛点梳理
在动手写第一行代码之前，我花了大概一周时间，跟不同团队的开发者聊他们日常做代码评审时最烦的事情。汇总下来，痛点集中在这么几个方面。
第一个痛点是评审标准不统一。同一个团队里，张三觉得变量名用驼峰没问题，李四觉得必须用下划线；王五认为函数超过五十行就该拆，赵六觉得一百行以内都能接受。没有统一的规则，评审就变成了个人偏好的博弈，讨论半天也吵不出结果。更麻烦的是，新人进来之后不知道听谁的，只能靠一次次被指出问题来“悟”，学习成本很高。
第二个痛点是重复性问题反复出现。空指针没判、日志里打了敏感信息、循环里查数据库、异常被吞掉——这些问题几乎每个项目都会遇到，但每次都要靠人工去发现。评审者精力有限，看多了就会麻木，漏掉几个也在所难免。如果能把这些确定性的问题交给工具自动检查，评审者就能把精力集中在架构设计、业务逻辑这些更需要人类判断的地方。
第三个痛点是评审结果难以沉淀。今天评审时讨论了一个问题，大家达成了共识，但过两个月新人来了，同样的问题又出现一遍。讨论过程散落在聊天记录、会议纪要、代码评论里，没有形成一个可检索、可复用的知识库。下次遇到类似情况，还得从头讨论一遍。
第四个痛点是工具太重、接入成本高。很多团队想引入代码质量工具，但一看部署文档就劝退了——要装数据库、要配消息队列、要对接单点登录、要维护服务端进程。对于小团队或者个人项目来说，这些额外负担完全不划算。
2.2 功能边界与设计取舍
基于上面这些痛点，我给open-code-review划定了明确的功能边界。它要做的事情是：在代码提交前或提交后，自动扫描变更内容，按照预设规则给出评审意见，并生成结构化的报告。它不做的事情是：不替代人工评审，不负责代码托管，不提供 Web 界面，不搞复杂的权限体系。
这个边界很重要。很多工具做着做着就想把所有事情都包进来，结果变得臃肿不堪。我坚持一个原则：工具只做机器擅长的事情，人类擅长的事情交还给人类。机器擅长的是模式匹配、规则校验、重复劳动；人类擅长的是判断设计好坏、评估业务影响、权衡技术债务。两者分工明确，效率才高。
在技术选型上，我选择了 Python 作为主要开发语言。原因有几个：一是 Python 的生态里有很多成熟的代码解析库，比如ast模块可以解析 Python 代码，pygments可以做语法高亮，libcst可以做更精细的语法树操作；二是 Python 脚本易于分发和运行，用户不需要编译，装个解释器就能跑；三是 Python 的插件机制很灵活，方便后续扩展支持其他语言。当然，如果你主要写 Go 或 Java，也可以用对应的语言来实现类似思路，核心逻辑是相通的。
2.3 与现有方案的差异化定位
市面上已经有不少代码检查工具，比如各种 linter、formatter、静态分析器。open-code-review跟它们有什么区别？
第一，关注点在“评审”而非“检查”。Linter 通常只告诉你“这行代码不符合规则”，而open-code-review会尝试给出更接近人类评审者的意见，比如“这个函数承担了太多职责，建议拆分成两个”“这个异常处理太宽泛，建议捕获具体异常类型”。它不只是报错，还会解释为什么这是个问题。
第二，规则可插拔、可组合。你可以把规则想象成积木，每个规则是一个独立的模块，有自己的触发条件、检查逻辑和输出格式。你可以按需启用或禁用规则，也可以把多个规则组合成一个规则集，针对不同的项目类型应用不同的规则集。
第三，报告格式面向人类阅读。很多工具的输出是给机器看的，一堆错误码和文件路径，读起来很费劲。open-code-review的报告会按文件分组、按严重程度排序，每条意见都附带代码片段和修改建议，读起来像是一个有经验的同事在给你提意见。
第四，零外部依赖。整个工具就是一个 Python 包，不需要数据库、不需要服务端、不需要网络连接。你可以在本地跑，也可以在 CI 流水线里跑，接入成本极低。
3. 关键技术点拆解：从代码解析到规则引擎
3.1 代码解析层的设计思路
代码评审工具的第一步，是把源代码变成程序可以理解的结构。如果只是做简单的文本匹配，那用正则表达式就够了，但正则表达式处理不了嵌套结构，也理解不了语法上下文。比如你想检查“函数是否过长”，用正则很难准确识别函数的起止位置；你想检查“变量是否在使用前初始化”，正则更是无能为力。
所以open-code-review选择了基于抽象语法树（AST）的解析方案。AST 是源代码语法结构的一种抽象表示，它把代码中的每个元素（函数、类、变量、表达式）表示成树形结构中的节点。有了 AST，你就可以精确地知道每个节点的类型、位置、子节点关系，从而做出更准确的判断。
以 Python 为例，标准库里的ast模块就能完成解析工作。下面这段代码演示了如何把一段 Python 代码解析成 AST 并遍历所有函数定义：
import ast source_code = """ def calculate_total(items): total = 0 for item in items: total += item.price return total """ tree = ast.parse(source_code) for node in ast.walk(tree): if isinstance(node, ast.FunctionDef): print(f"函数名: {node.name}") print(f"起始行: {node.lineno}") print(f"结束行: {node.end_lineno}") print(f"参数个数: {len(node.args.args)}")这段代码会输出函数名、起止行号和参数个数。有了这些信息，你就可以计算函数长度、检查参数数量是否过多、判断函数是否有返回值等等。
对于其他语言，也有对应的解析方案。JavaScript 可以用esprima或@babel/parser，Java 可以用javalang，Go 可以用标准库里的go/ast。open-code-review的设计是把解析层抽象成一个接口，每种语言实现自己的解析器，上层规则引擎不关心底层是什么语言，只关心解析出来的 AST 结构。
3.2 规则引擎的核心机制
规则引擎是整个工具的大脑。它的工作流程可以概括为：加载规则 -> 遍历 AST -> 匹配规则条件 -> 生成评审意见。
每个规则本质上是一个函数，输入是 AST 节点和上下文信息，输出是一个评审意见列表（可能为空）。规则可以很简单，比如“检查函数名是否使用蛇形命名法”；也可以很复杂，比如“检查是否存在循环嵌套查询数据库的模式”。
下面是一个简单规则的示例，检查函数参数是否超过五个：
def check_function_parameter_count(node, context): """检查函数参数数量是否过多""" max_params = context.get_config("max_params", 5) param_count = len(node.args.args) if param_count > max_params: return [{ "rule_id": "function-too-many-params", "severity": "warning", "message": f"函数 '{node.name}' 有 {param_count} 个参数，" f"超过建议上限 {max_params} 个。" f"考虑将相关参数封装成对象，或拆分函数职责。", "line": node.lineno, "column": node.col_offset, }] return []这个规则接收一个函数定义节点和上下文对象，从上下文里读取配置的最大参数数量（默认是 5），然后统计实际参数个数。如果超限，就返回一条评审意见，包含规则 ID、严重程度、提示信息、行号和列号。
规则引擎在遍历 AST 时，会对每个节点调用所有已注册的规则函数，收集返回的意见。遍历完成后，把所有意见按文件、按行号排序，生成最终报告。
这里有个设计细节值得说一下：规则的执行顺序和优先级。有些规则之间有依赖关系，比如“检查未使用变量”需要在“检查变量声明”之后执行。我在引擎里加了一个简单的优先级机制，每个规则可以声明自己的优先级，引擎按优先级从高到低执行。同时，规则之间可以通过上下文对象共享信息，比如一个规则发现了某个变量被声明，可以把它记录到上下文里，后续规则就可以查询这个信息。
3.3 评审意见的生成与分级
评审意见不是越多越好。如果工具报了一百个问题，开发者大概率会直接忽略。所以意见的生成需要克制，分级需要清晰。
open-code-review把评审意见分成三个级别：
- error：确定的问题，必须修复。比如语法错误、未捕获的异常、资源泄漏。
- warning：潜在的问题，建议修复。比如函数过长、参数过多、魔法数字。
- info：风格建议，可选修复。比如命名规范、注释格式、导入顺序。
分级的标准不是拍脑袋定的，而是根据“这个问题是否会导致运行时错误”和“修复成本与收益的比值”来综合判断。会导致运行时错误的，级别高；修复成本低但收益明显的，级别也高；纯粹是风格偏好且修复成本高的，级别低。
每条意见除了级别，还包含这些字段：规则 ID（方便追溯和屏蔽）、文件路径、行号列号、代码片段、问题描述、修改建议。修改建议这一项很关键，很多工具只告诉你“这里有问题”，但不告诉你“怎么改”。open-code-review尽量给出具体的修改方向，哪怕只是一个思路，也能帮开发者省下不少思考时间。
3.4 配置系统与规则集管理
不同项目对代码规范的要求不一样。一个写 Web 后端的项目和一个写数据分析脚本的项目，对函数长度、命名风格、异常处理的要求可能完全不同。所以配置系统必须灵活。
open-code-review的配置采用 YAML 格式，放在项目根目录下的.open-code-review.yml文件里。配置内容包括：启用哪些规则、每个规则的参数、忽略哪些文件或目录、报告的输出格式等。
rules: function-too-many-params: enabled: true max_params: 5 function-too-long: enabled: true max_lines: 50 magic-number: enabled: true allowed_numbers: [0, 1, -1, 100] ignore: - "tests/" - "migrations/" - "*.generated.py" output: format: "markdown" group_by: "file" min_severity: "warning"这个配置文件的意思是：启用“函数参数过多”规则，上限 5 个；启用“函数过长”规则，上限 50 行；启用“魔法数字”规则，允许 0、1、-1、100 这几个数字直接出现；忽略 tests、migrations 目录和所有 .generated.py 文件；输出格式为 Markdown，按文件分组，只显示 warning 及以上级别的意见。
规则集的管理采用“基础规则集 + 项目覆盖”的模式。基础规则集是工具自带的，包含一套通用的最佳实践；项目可以在自己的配置文件里覆盖基础规则集的设置，也可以完全禁用某些规则。这样既保证了开箱即用，又保留了足够的灵活性。
4. 实操落地：从安装到跑通第一条评审
4.1 环境准备与安装步骤
open-code-review的安装非常简单，因为它本身就是一个纯 Python 包，没有复杂的系统依赖。你只需要确保机器上装了 Python 3.8 或更高版本，然后用 pip 安装即可。
# 创建虚拟环境（推荐，避免污染全局环境） python -m venv .venv source .venv/bin/activate # Windows 下用 .venv\Scripts\activate # 安装 open-code-review pip install open-code-review安装完成后，可以用ocr --version验证是否安装成功。如果输出了版本号，说明环境没问题。
这里有个小坑要注意：如果你用的是 macOS 自带的 Python，可能会遇到权限问题。建议用pyenv或conda管理 Python 版本，避免跟系统自带的 Python 混用。另外，如果你在公司内网环境，pip 可能需要配置镜像源，这个根据实际情况调整即可。
4.2 初始化项目配置
安装完成后，在项目根目录下运行初始化命令：
ocr init这个命令会生成一个默认的.open-code-review.yml配置文件，里面包含了所有可用规则的说明和默认参数。你可以直接使用默认配置，也可以根据自己的需求修改。
初始化完成后，建议先跑一次全量扫描，看看项目里有哪些问题：
ocr scan --path ./src--path参数指定要扫描的目录，默认是当前目录。扫描完成后，工具会在终端输出评审报告，同时生成一个open-code-review-report.md文件，方便你存档或分享。
4.3 解读评审报告
报告的结构是这样的：先是一个概览，显示扫描了多少文件、发现了多少问题、按严重程度分布如何；然后是详细列表，按文件分组，每个文件下列出具体的评审意见。
# 代码评审报告 扫描时间: 2025-01-15 10:30:00 扫描文件数: 42 发现问题数: 17 (error: 2, warning: 9, info: 6) ## src/services/user_service.py ### [error] 第 45 行: 异常处理过于宽泛 ```python try: user = db.query(User).filter_by(id=user_id).first() except Exception: return None问题: 捕获了所有异常，会掩盖真正的错误（如数据库连接失败、SQL 语法错误）。建议: 捕获具体的异常类型，如SQLAlchemyError，并记录日志。
[warning] 第 78 行: 函数参数过多
函数create_user有 7 个参数，超过建议上限 5 个。建议: 考虑将用户信息封装成UserCreateDTO对象。
每条意见都包含：严重程度、行号、问题描述、代码片段、修改建议。读起来很直观，不需要额外的解释。 ### 4.4 集成到开发流程 工具跑通之后，下一步是把它集成到日常开发流程里。有两种常见的集成方式。 第一种是**本地 Git 钩子**。在 `.git/hooks/pre-commit` 里加一行命令，每次提交前自动扫描变更的文件。如果发现 error 级别的问题，就阻止提交；warning 和 info 级别的问题只提示，不阻止。 ```bash #!/bin/bash # .git/hooks/pre-commit ocr scan --staged --min-severity error if [ $? -ne 0 ]; then echo "发现 error 级别问题，提交被阻止。请修复后重试。" exit 1 fi--staged参数表示只扫描暂存区里的文件，也就是本次提交涉及的文件。这样扫描速度很快，不会因为项目太大而卡住提交。
第二种是CI 流水线集成。在 CI 配置里加一个步骤，每次推送代码或发起合并请求时自动扫描。这种方式适合团队协作，可以保证所有进入主分支的代码都经过检查。
# .github/workflows/code-review.yml 示例 name: Code Review on: [push, pull_request] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v4 with: python-version: '3.10' - run: pip install open-code-review - run: ocr scan --path ./src --min-severity warning这个配置会在每次推送和合并请求时运行扫描，如果发现 warning 及以上级别的问题，CI 就会失败，提醒开发者修复。
5. 踩坑实录：那些让我熬夜排查的问题
5.1 AST 解析的边界情况
第一个让我头疼的问题是 AST 解析的边界情况。Python 的ast模块虽然强大，但有些语法结构处理起来并不直观。
比如装饰器。一个函数如果有装饰器，ast.FunctionDef节点的lineno指向的是def那一行，而不是装饰器那一行。如果你在报告里只显示def的行号，用户可能找不到问题所在，因为装饰器在上面几行。解决办法是检查节点的decorator_list，如果有装饰器，就把行号往上调整。
再比如异步函数。async def定义的函数，节点类型是ast.AsyncFunctionDef，而不是ast.FunctionDef。如果你只检查FunctionDef，就会漏掉所有异步函数。这个坑我在早期版本里踩过，后来加了一个统一的函数节点判断逻辑，把两种类型都覆盖了。
还有 lambda 表达式。Lambda 也是函数，但它没有名字，参数和函数体写在一行里。如果你用检查普通函数的规则去检查 lambda，很多逻辑会失效。我的处理方式是：对于 lambda，只做最基本的检查（比如参数数量），不做复杂度相关的检查。
5.2 规则误报的排查过程
规则误报是另一个让人头疼的问题。误报多了，用户就会失去信任，直接关掉工具。我遇到过几个典型的误报场景，这里分享一下排查思路。
第一个误报场景是魔法数字检查。规则的本意是提醒开发者不要把数字直接写在代码里，应该定义成常量。但有些数字是约定俗成的，比如 0、1、-1、100，这些数字直接出现并不会影响可读性。如果规则把这些也报出来，就会产生大量噪音。解决办法是在配置里加一个allowed_numbers列表，把这些常见数字排除掉。
第二个误报场景是未使用变量检查。规则会扫描所有变量声明，然后检查是否有对应的使用。但有些变量是故意不用的，比如用下划线开头的占位变量，或者通过globals()动态访问的变量。如果规则把这些也报出来，就会误伤。解决办法是加一个忽略模式，变量名匹配^_或者出现在globals()调用里的，跳过检查。
第三个误报场景是函数过长检查。规则按行数计算函数长度，但有些函数的行数多是因为注释和空行多，实际逻辑并不复杂。如果只看总行数，就会误报。解决办法是计算“有效行数”，排除空行、纯注释行和文档字符串。这样计算出来的长度更接近函数的实际复杂度。
排查误报的通用思路是：先复现问题，找到触发规则的代码；然后分析规则的判断逻辑，看是哪一步产生了误判；最后调整规则的判断条件或参数，让它在保持检出率的同时降低误报率。这个过程需要反复迭代，没有一劳永逸的方案。
5.3 性能优化的实际经验
当项目规模变大时，扫描速度会成为问题。我测试过一个包含约 500 个 Python 文件的项目，初始版本的扫描时间超过 30 秒，这在 Git 钩子里是不可接受的。
性能瓶颈主要有两个：一是 AST 解析本身耗时，二是规则遍历 AST 时重复计算。
针对第一个瓶颈，我加了缓存机制。解析结果按文件内容哈希缓存，如果文件内容没变，就直接用缓存，跳过解析。这个优化在增量扫描场景下效果很明显，第二次扫描同一个项目时，速度能提升 80% 以上。
针对第二个瓶颈，我把规则遍历改成了单次遍历。初始版本是每个规则独立遍历一遍 AST，十个规则就遍历十遍。后来改成一次遍历，在每个节点上调用所有规则，把结果收集起来。这样 AST 只遍历一遍，速度提升了好几倍。
还有一个优化是并行处理。Python 的multiprocessing模块可以把不同文件的扫描任务分配到多个进程，充分利用多核 CPU。不过并行处理会带来进程间通信的开销，文件数量少的时候反而更慢。我加了一个阈值判断：文件数超过 20 个才启用并行，否则用单进程。
5.4 配置文件的常见错误
配置文件写错是新手最容易遇到的问题。我见过几种典型的错误配置。
第一种是缩进错误。YAML 对缩进非常敏感，多一个空格少一个空格都会导致解析失败。而且 YAML 的报错信息往往不直观，只说“解析错误”，不告诉你具体哪一行有问题。我的建议是用支持 YAML 语法高亮的编辑器来写配置文件，能提前发现缩进问题。
第二种是规则名拼写错误。规则名是区分大小写的，function-too-long和Function-Too-Long是两个不同的名字。如果拼错了，工具会忽略这个配置项，规则会使用默认参数，而不是你期望的参数。解决办法是在配置里加一个校验步骤，启动时检查所有规则名是否有效，无效的给出警告。
第三种是参数类型错误。比如max_lines期望的是整数，你写成了字符串"50"，工具可能会报类型错误，也可能静默失败。我的处理方式是在读取配置时做类型转换和校验，如果类型不对，给出明确的错误提示，而不是让用户去猜。
6. 规则定制与扩展：让它真正贴合你的团队
6.1 编写自定义规则的完整流程
内置规则覆盖了常见的代码质量问题，但每个团队都有自己的特殊情况。open-code-review提供了自定义规则的机制，让你可以把自己的团队规范固化下来。
编写自定义规则的流程分四步：定义规则元信息、实现检查逻辑、注册规则、测试验证。
第一步，定义规则元信息。每个规则需要有一个唯一的 ID、一个显示名称、一个描述、一个默认严重程度。这些信息放在规则类的属性里。
from open_code_review.rule import BaseRule class NoPrintStatementRule(BaseRule): rule_id = "no-print-statement" name = "禁止使用 print 语句" description = "生产代码中不应使用 print 输出调试信息，应使用日志模块" severity = "warning" languages = ["python"]第二步，实现检查逻辑。规则类需要实现一个check方法，接收 AST 节点和上下文，返回评审意见列表。
def check(self, node, context): import ast if isinstance(node, ast.Call): if isinstance(node.func, ast.Name) and node.func.id == "print": return [self.make_issue( node=node, message="发现 print 语句，建议改用 logging 模块", suggestion="将 print(...) 替换为 logger.info(...) 或 logger.debug(...)" )] return []第三步，注册规则。把规则类加到配置文件的规则列表里，或者在代码里显式注册。
from open_code_review.engine import RuleEngine from my_rules import NoPrintStatementRule engine = RuleEngine() engine.register(NoPrintStatementRule())第四步，测试验证。写一个包含 print 语句的测试文件，跑一遍扫描，看规则是否按预期触发。同时也要测试不包含 print 的代码，确保没有误报。
6.2 规则组合与规则集设计
单个规则的力量有限，把多个规则组合成规则集，才能覆盖一个完整的评审维度。open-code-review支持把规则分组，每组规则有一个名字，可以在配置里按组启用或禁用。
我建议按“关注维度”来组织规则集，比如：
- 命名规范组：变量命名、函数命名、类命名、常量命名、模块命名。
- 复杂度控制组：函数长度、参数数量、嵌套深度、圈复杂度。
- 异常处理组：异常捕获范围、异常日志记录、异常类型选择。
- 资源管理组：文件句柄关闭、数据库连接释放、锁的获取与释放。
- 安全检查组：SQL 注入风险、硬编码密码、不安全的反序列化。
每个组可以独立启用，也可以组合使用。比如一个新项目可以启用所有组，一个遗留项目可能只启用“安全检查组”和“异常处理组”，先解决最紧迫的问题。
规则集的设计原则是：从宽到严，逐步收紧。一开始不要把标准定得太高，否则开发者会被大量问题淹没，产生抵触情绪。先启用少量关键规则，等团队适应了，再逐步增加规则和收紧参数。
6.3 规则参数的调优经验
规则的默认参数是通用场景下的保守值，但每个项目的实际情况不同，需要调优。调优的核心依据是扫描结果的数据分布。
以“函数过长”规则为例。默认上限是 50 行。你可以先跑一次全量扫描，看看项目里函数长度的分布情况。如果 90% 的函数都在 30 行以内，那 50 行的上限可能太宽松了，可以收紧到 40 行；如果有很多函数在 60-80 行之间，那 50 行的上限可能太严格了，会产生大量误报，可以先放宽到 80 行，等重构之后再收紧。
调优不是一次性的工作，而是一个持续的过程。我建议每次迭代周期结束时，回顾一下评审报告，看看哪些规则报得最多、哪些规则被忽略得最多。报得最多的规则，要么是确实存在大量问题需要修复，要么是规则太严格需要放宽；被忽略得最多的规则，要么是规则不重要，要么是提示信息不够清晰，需要改进。
6.4 与团队规范的对接方法
工具最终是给人用的，如果团队不认可，规则写得再好也没用。所以规则定制的过程一定要让团队成员参与进来。
我的做法是：先让每个成员提三条他们认为最重要的代码规范，汇总之后投票选出前十条，作为第一批规则。然后把这十条规则写成自定义规则，在团队内试运行两周。试运行期间，每周收集一次反馈，看看哪些规则误报多、哪些规则提示不清楚、哪些规则大家觉得没必要。根据反馈调整之后，再正式启用。
这个过程看起来麻烦，但效果很好。因为规则是大家自己选的，执行起来抵触情绪小很多。而且通过参与规则制定，团队成员对代码规范的理解也更深入了，这比单纯地宣讲规范文档有效得多。
7. 从工具到习惯：代码评审文化的落地思考
工具能解决“发现问题”的效率问题，但解决不了“愿不愿意改”的意愿问题。我见过不少团队，工具装了一堆，报告生成了一摞，但代码质量该怎么样还怎么样。问题出在文化上，不是工具上。
要让代码评审真正发挥作用，有几个前提条件。第一，评审意见要能被看到。如果报告生成之后就躺在某个文件夹里没人看，那跟没生成一样。所以报告要集成到开发者每天都会看的渠道里，比如合并请求的评论、即时通讯群的消息、邮件列表。第二，评审意见要能被讨论。工具报出的问题不一定都对，开发者应该有渠道反馈“这条规则不适用”或者“这个场景是特例”。第三，评审结果要能被追踪。哪些问题修复了、哪些问题被忽略了、忽略的原因是什么，这些信息要记录下来，形成团队的知识库。
open-code-review在设计上尽量降低了这些环节的摩擦。报告格式是 Markdown，方便贴到任何地方；规则可以按项目配置，方便处理特例；每条意见都有规则 ID，方便统计和追踪。但工具只是工具，真正的改变还是要靠人。
我个人在实际操作中的体会是：不要试图一次改变所有事情。先从一个小的、具体的点开始，比如“禁止使用 print 语句”，让团队看到工具确实能帮上忙，然后再逐步扩展。每次只加一两条规则，让团队有适应的过程。等大家习惯了工具的存在，再讨论更复杂的评审维度。
还有一个技巧是把评审结果跟正向激励挂钩。比如每个月统计一次，看看哪个模块的代码质量提升最明显，在团队会议上表扬一下。人都是需要反馈的，正向反馈比负向惩罚有效得多。
最后再分享一个小技巧：把open-code-review的扫描命令加到项目的 README 里，让每个新加入的开发者第一件事就是跑一遍扫描，看看自己负责的模块有哪些问题。这样既能快速了解代码现状，也能从一开始就建立起质量意识。
