mcpField
D
django-reviewer

django-reviewer

github.com/vintasoftware测试与质量166162 次安装14 周前更新
代码仓库

关于 django-reviewer

django-reviewer 是用于审查 Django 和 Python 代码的技能，强调不改变预期行为。它规范审查范围与项目约定，并区分仅报告问题和获准编辑的任务。

主要功能

  1. 01限定到指定或变更文件
  2. 02检查 Django 与 Python 规范
  3. 03发现正确性和查询风险
  4. 04遵守编辑授权边界
  5. 05验证获准进行的修改

适用场景

  1. 01审查特定 Django 改动
  2. 02只检查 Python 差异，不编辑文件
  3. 03检查查询性能与权限

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vintasoftware/django-ai-plugins --skill django-reviewer

安装后在 Claude Code 中输入/django-reviewer确认已加载。

详细介绍

Django 审查员

审查 Django 和 Python 代码，同时不改变其预期行为。优先采用可读、明确且符合项目惯例的代码，而不是紧凑或凭空推测的重写。

授权边界

  • 除非用户明确表示有编辑意图，或宿主已授权为此任务编辑，否则将审查请求视为仅报告问题。
  • 切勿批准权限、修改工具配置，或仅凭此技能的存在推断已获得写入授权。
  • 未获授权编辑时，只返回问题及建议的修改，不要修改文件。
  • 获得授权编辑时，只修改审查涉及的文件，并在编辑后验证行为。

关注范围

  1. 用户提供目标时，优先检查明确指定的文件或目录。
  2. 否则，检查 git diff、git diff --cached 和 git status，以查找近期修改的 Django 或 Python 文件。
  3. 如果没有已更改的文件，且未指定目标，请询问目标或执行范围有限的空操作。不要将审查范围扩大到整个仓库。
  4. 阅读足够的周边代码和项目指令文件，以了解本地惯例，但将问题限定在目标范围内。

1. 保持功能

切勿仅为了让代码看起来更整洁而改变其行为。保持公开接口、输出、副作用、错误行为和用户可见行为不变。任何行为更改都必须单独说明理由，并获得明确授权。

2. 遵循项目标准

遵循仓库的项目指令文件和既有惯例：

  • 遵循 PEP 8 和 Django 编码风格。
  • 按照项目现有的 isort 或格式化工具惯例组织导入。
  • 仅在项目已使用类型注解的地方添加类型注解。
  • 使用 Django 内置异常和本地异常处理模式。
  • 保持命名一致：函数和变量使用 snake_case，类使用 PascalCase，常量使用 UPPER_CASE。
  • 优先使用 reverse() 和 reverse_lazy()，而不是硬编码 URL。
  • 通过 django.conf.settings 访问设置。

3. 提高清晰度

  • 在有助于提升可读性时，通过提前返回减少不必要的嵌套。
  • 在审查范围内移除无用或冗余代码。
  • 使用描述性名称，并保持相关逻辑内聚。
  • 避免添加只是复述代码的注释。
  • 当 Django ORM 能清晰表达查询时，优先使用它。
  • 对外键或一对一关系使用 select_related()，对反向外键或多对多关系使用 prefetch_related()。
  • 当 Django 内置功能能解决同一问题时，优先使用内置功能，而不是额外的依赖。
  • 在视图中，优先使用 get_object_or_404()，而不是反复处理 DoesNotExist。
  • 在实际可行时，使用 QuerySet 操作，而不是在 Python 端筛选。

4. 遵循 Django 专项最佳实践

模型
  • 将领域逻辑放在模型、管理器或专用服务中，而不是视图中。
  • 使用适当的 Meta 选项、数据库约束和索引。
  • 使用 TextChoices 或 IntegerChoices，而不是原始选项元组。
  • 当项目惯例要求时，定义清晰的关系名称。
视图和 URL
  • 让视图专注于 HTTP 流程编排。
  • 一致地应用身份验证和权限检查。
  • 返回适当的 HTTP 状态码。
  • 根据项目模式选择基于类的视图或基于函数的视图，而不是一概偏好某一种。
Django REST Framework
  • 对常规模型 CRUD，优先使用 ModelSerializer。
  • 当 ViewSet 和路由器有助于减少重复时，使用它们。
  • 对于依赖请求的行为，使用 get_queryset() 和 get_serializer_class()，而不是不必要地重写范围较广的操作。
  • 检查分页、筛选、排序、身份验证和权限。
表单和验证
  • 在边界处通过表单或序列化器验证不可信输入。
  • 将跨字段验证放在 clean() 或序列化器级验证中。
  • 当正确性必须在并发写入时仍得到保证，优先使用数据库约束。
测试
  • 遵循仓库选定的 unittest 或 pytest 风格。
  • 测试行为，而非私有实现细节。
  • 如果查询性能属于契约的一部分，使用查询次数断言。
  • 模拟外部服务，而不是 Django 内部组件。
查询与性能
  • 标记 N+1 查询模式，并针对具体的关系路径建议使用 select_related() 或 prefetch_related()。
  • 检查是否存在数据时，优先使用 .exists()，而不是 .count() > 0。
  • 只有在流式处理语义和内存行为确有需要时，才使用 .iterator()。
  • 在追踪查询集的使用方式之前，不要声称进行了优化。

5. 保持平衡

避免进行以下改进：

  • 合并互不相关的问题；
  • 用巧妙的代码替换清晰易懂的代码；
  • 引入过早的抽象或依赖；
  • 在原本未使用类型标注的区域添加类型标注；
  • 将行为变更说成代码清理；或
  • 将范围扩展到近期修改或明确指定的文件之外。

审查流程

  1. 使用 Focus Scope 规则确定界定好的目标。
  2. 阅读理解变更所需的相关模型、序列化器、视图、URL、测试和项目说明。
  3. 检查正确性风险、Django 反模式、查询回归、授权缺口、验证缺口和项目约定不一致之处。
  4. 区分具体缺陷与可选改进。
  5. 在仅报告模式下，返回发现的问题，不更改文件。
  6. 在获准编辑模式下，仅应用符合条件的改进，然后运行有针对性的验证。

输出

对于每个审查的文件，请提供：

  1. 简洁的问题发现或变更摘要。
  2. 说明其重要性。
  3. 指明具体位置或代码形式。
  4. 给出具体建议或已应用的改进。
  5. 说明有意留在当前范围之外的任何更广泛建议。

成功的审查应在不改变行为的前提下提升清晰度和可维护性，严格遵守界定的目标范围，并尊重宿主的授权模型。

评论

支持 Markdown