团队基建与研发规范

定位

团队基建指支撑多项目并行交付的 共性能力：代码规范、Git 工作流、CI 质量门禁、组件/工具库、文档与复盘模板等。目标是在不牺牲速度的前提下，降低 缺陷外泄成本 与 新人上手摩擦。

---

规范与协作

• 分支策略：主干开发 / Git Flow 等按团队规模选型；明确 release/hotfix 规则，避免生产补丁不可追溯。
• 合并要求：MR/PR 必选评审；关联需求/缺陷单；禁止直推受保护分支。
• 提交信息：约定 Conventional Commits 或等价规范，便于生成变更日志与自动化发版。

质量门禁

• 静态检查：ESLint / Stylelint、TypeScript 严格模式、Sonar 等按栈接入。
• 测试：核心域 单测/契约测 底线；关键路径 E2E 冒烟。
• 构建：流水线中 install → lint → test → build，失败即阻断合并。

示例：GitHub Actions 最小 CI（前端 Monorepo 单包可参考）

name: ci
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test --if-present
      - run: npm run build

示例：Husky + lint-staged（提交前只检查暂存区，缩短反馈）

{
  "lint-staged": {
    "*.{ts,tsx,vue}": ["eslint --fix", "prettier --write"]
  }
}

# prepare 脚本中启用 husky（npm 生命周期）
npx husky init
echo 'npx lint-staged' > .husky/pre-commit

可复用资产

• 组件库 / Hooks：跨项目沉淀表格、上传、权限指令等，减少重复踩坑。
• 脚手架与模板：统一 目录结构、环境变量、Dockerfile 骨架，缩短新项目 bootstrap时间。
• 内部文档：架构决策记录（ADR）、接口契约、部署 Runbook。

复盘机制

• 迭代/里程碑结束后 短复盘：问题根因、是否需规范/工具层永久修复。
• 重大故障 事后复盘：时间线、触发条件、改进项与负责人、完成时间。

---

小结

基建工作的价值往往 不直接体现在需求列表，但决定团队 长期交付曲线。在履历中可量化：流水线耗时、缺陷率变化、组件复用覆盖项目数 等，比单纯罗列工具名更有说服力。