把流程换到文化时踩过的坑

# Pull Request 模板

## 变更描述
<!-- 简要描述这个 PR 做了什么 -->

## 变更类型
<!-- 选择一个 -->
- [ ] Bug 修复
- [ ] 新功能
- [ ] 性能优化
- [ ] 重构
- [ ] 文档更新

## 测试
<!-- 描述如何测试这个 PR -->

## 截图/演示
<!-- 如果有 UI 变更，提供截图或演示链接 -->

## 检查清单
- [ ] 代码遵循项目规范
- [ ] 添加了必要的测试
- [ ] 更新了相关文档
- [ ] 没有引入新的警告
- [ ] 通过了所有 CI 检查

## 相关 Issue
<!-- 关联相关 Issue -->
Fixes #123

# .github/workflows/pr-check.yml
name: PR Check

on:
  pull_request:
    branches: [ main ]

jobs:
  check:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v2
      
      - name: Setup Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '16'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run Linter
        run: npm run lint
      
      - name: Run Tests
        run: npm test
      
      - name: Check coverage
        run: npm test -- --coverage
      
      - name: Check TypeScript
        run: npm run type-check
      
      - name: Security audit
        run: npm audit --audit-level=moderate

# 代码质量检查清单

## 可读性
- [ ] 变量和函数命名清晰
- [ ] 代码格式一致
- [ ] 注释适当且准确
- [ ] 复杂逻辑有说明

## 可维护性
- [ ] 函数职责单一
- [ ] 避免重复代码
- [ ] 模块化良好
- [ ] 依赖关系清晰

## 性能
- [ ] 没有明显的性能问题
- [ ] 合理使用缓存
- [ ] 避免不必要的计算
- [ ] 数据库查询优化

## 安全
- [ ] 没有硬编码密钥
- [ ] 输入验证
- [ ] 输出转义
- [ ] 权限检查

# 测试质量检查清单

## 测试覆盖
- [ ] 核心功能有测试
- [ ] 边界条件测试
- [ ] 错误处理测试
- [ ] 集成测试

## 测试质量
- [ ] 测试用例有意义
- [ ] 测试数据合理
- [ ] 断言准确
- [ ] 没有过时的测试

// 使用 husky 和 lint-staged
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write",
      "jest --bail --findRelatedTests"
    ],
    "*.{css,scss,less}": [
      "stylelint --fix",
      "prettier --write"
    ]
  }
}

// 使用 commitlint
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']],
    'subject-case': [0]
  }
};

// 使用 SonarQube 进行代码质量分析
module.exports = {
  plugins: [
    ['@typescript-eslint/eslint-plugin'],
    ['eslint-plugin-sonarjs'],
    ['eslint-plugin-import'],
    ['eslint-plugin-jsx-a11y'],
    ['eslint-plugin-react']
  ],
  rules: {
    // 复杂度规则
    'complexity': ['warn', 10],
    'max-lines-per-function': ['warn', 50],
    
    // 安全规则
    'no-eval': 'error',
    'no-implied-eval': 'error',
    
    // 最佳实践
    'prefer-const': 'warn',
    'no-var': 'error',
    
    // 测试规则
    'sonarjs/no-duplicate-string': 'warn'
  }
};

# 好的反馈

## 代码结构
✅ 整体结构清晰，模块划分合理。

## 性能
⚠️ 在 calculate_total 函数中，建议使用数组方法代替循环：
```javascript
// 当前实现
let total = 0;
for (let i = 0; i < items.length; i++) {
  total += items[i].price;
}

// 建议
const total = items.reduce((sum, item) => sum + item.price, 0);

test('calculate_total with empty array', () => {
  expect(calculate_total([])).toBe(0);
});

# 审查对齐会议

## 会议目的
- 统一审查标准
- 讨论审查中的问题
- 分享最佳实践

## 会议内容
1. 审查标准回顾
2. 最近审查案例分析
3. 审查工具使用
4. Q&A

## 时间
- 每两周一次
- 时长：1 小时

# 审查重点

## 重点关注
1. 重大 bug 和安全问题
2. 架构和设计问题
3. 性能问题
4. 可维护性问题

## 不纠结
1. 代码风格（交给自动化工具）
2. 个人偏好
3. 细节优化（不是影响正确性的）