CentOS Node.js项目如何进行代码审查

CentOS 上 Node.js 项目的代码审查方案

一 本地预检与提交门禁

• 使用 ESLint 做静态检查、Prettier 做统一格式化，配合 Husky + lint-staged 在提交前自动拦截不合规代码，保证进入代码库的代码已通过基础质量门禁。
• 快速落地步骤
  1. 安装依赖
     • npm i -D eslint prettier eslint-config-prettier eslint-plugin-prettier @typescript-eslint/parser @typescript-eslint/eslint-plugin husky lint-staged
  2. 初始化 ESLint
     • npx eslint --init（选择 Node.js、是否使用 TypeScript、模块化方案等）
  3. 典型 ESLint 配置（.eslintrc.js 片段）
     • env: { node: true, es2022: true }
     • extends: [ ‘eslint:recommended’, ‘plugin:@typescript-eslint/recommended’, ‘plugin:security/recommended’, ‘plugin:prettier/recommended’ ]
     • parser: ‘@typescript-eslint/parser’
     • rules: { ‘no-console’: ‘warn’, ‘no-unused-vars’: ‘error’, ‘security/detect-unsafe-regex’: ‘error’ }
  4. Prettier 配置（.prettierrc）
     • { “singleQuote”: true, “trailingComma”: “all”, “printWidth”: 100, “tabWidth”: 2, “semi”: true, “arrowParens”: “always”, “endOfLine”: “lf” }
  5. 启用 Git 钩子与暂存区检查
     • npx husky install
     • 在 package.json 增加：
       • “scripts”: { “prepare”: “husky install”, “lint”: “eslint . --ext .js,.ts”, “format”: “prettier --write "**/*.{js,ts,json,md}"” }
       • “lint-staged”: { “*.{js,ts}”: [“eslint --fix”, “prettier --write”] }
     • npx husky add .husky/pre-commit “npx lint-staged”
• 说明
  • 通过 eslint-config-prettier + eslint-plugin-prettier 消除与 Prettier 的格式化规则冲突。
  • 将 security 插件纳入规则集，可在提交阶段发现常见安全问题（如不安全正则、路径遍历等）。

二 人工审查要点清单

• 代码风格与可读性
  • 命名清晰、函数单一职责、避免深层嵌套与过长函数；一致的缩进、引号、分号策略（由 Prettier 统一）。
• 错误处理与日志
  • 对异步错误使用 try/catch 或 Promise.catch，避免吞掉异常；生产环境减少 console.log，使用结构化日志（如 Winston）。
• 安全
  • 输入校验与输出转义，防范 XSS；启用 CSP；避免 eval/new Function；谨慎使用正则（禁用不安全正则）；限制文件操作路径，避免路径遍历。
• 依赖与供应链安全
  • 定期升级依赖，排查 已知漏洞（npm audit / SCA 工具）；锁定依赖版本，避免误升级引入风险。
• 测试与覆盖
  • 关键路径具备 单元/集成测试，提交前本地跑通；在 PR 中附上测试结果与覆盖率变化。
• 性能与资源
  • 避免内存泄漏（及时清理定时器、事件监听）；大数据量场景使用流式处理；合理使用缓存与并发控制。
• 可维护性与文档
  • 公共 API 有 JSDoc；复杂业务逻辑补充注释；变更涉及对外接口或配置时同步更新文档。

三 在 CentOS 搭建 Jenkins 自动化审查

• 安装与插件
  • 在 CentOS 部署 Jenkins，安装代码质量与报告插件：SonarQube Scanner、Checkstyle、PMD、JUnit 报告插件等。
• 配置 SonarQube
  • 在 SonarQube 创建项目，获取 Token；Jenkins 全局凭据中配置 SonarQube 服务器地址与凭据。
• 定义流水线（Jenkinsfile 片段）
  • pipeline { agent any tools { nodejs ‘NodeJS-18’ } // 在 Jenkins 全局工具配置 Node.js stages { stage(‘Checkout’) { steps { git branch: ‘main’, url: ‘git@your-repo.git’ } } stage(‘Install’) { steps { sh ‘npm ci --quiet’ } } stage(‘Lint & Format Check’) { steps { sh ‘npm run lint – --max-warnings=0’ sh ‘git diff --exit-code || (echo “请先运行: npm run format”; exit 1)’ } } stage(‘Test & Coverage’) { steps { sh ‘npm test – --ci --coverage’ junit ‘reports/junit.xml’ } } stage(‘SonarQube Analysis’) { steps { withSonarQubeEnv(‘SonarQube’) { sh ‘sonar-scanner -Dsonar.projectKey=your-project -Dsonar.sources=. -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info’ } } } stage(‘Quality Gate’) { steps { timeout(time: 5, unit: ‘MINUTES’) { waitForQualityGate abortPipeline: true } } } } }
• 运行与监控
  • 每次 Push/PR 触发构建，查看 SonarQube 质量报告、单元测试结果与覆盖率；若未通过 Quality Gate，则阻断合并。

四 PR 协作流程与度量

• 分支与 PR 规范
  • 使用 Git Flow 或 GitHub Flow；PR 标题遵循 Conventional Commits（如 feat:、fix:），正文说明变更动机与影响范围；关联 JIRA/Issue 编号。
• PR 模板与检查清单
  • 模板包含：变更目的、影响范围、测试覆盖、截图/日志、回滚方案；审查者按“安全 > 正确性 > 可维护性 > 风格”顺序评审。
• 度量与改进
  • 持续跟踪 代码异味、重复率、复杂度、测试覆盖率、缺陷密度 等指标；对反复出现的问题制定 规则/模板/自动化 改进措施。
• 可选增强
  • 引入 AI 辅助审查（如终端智能工具）进行自动化扫描、变更解释与风险点提示，提高审查效率与一致性。