Code Review 最佳实践 2：业务实战中的审核细节

🧠 本节谈

我们聚焦真实业务模块中的 Code Review，涵盖：

🔐 表单校验逻辑
🧩 动态权限控制
🧱 页面逻辑复杂度管理
⚠️ 接口调用规范
♻️ 组件解耦重构
🧪 单元测试提示

每一条都配备真实反面代码 + 改进建议 + 原因说明，并总结通用审核 checklist。

📍 场景 1：复杂表单校验逻辑

❌ 错误示例：耦合 + 不可维护

javascript 复制代码

const onSubmit = () => {
  if (!form.name || form.name.length < 3 || !form.age || isNaN(form.age)) {
    message.error('请填写正确信息')
    return
  }
  // ...
}

问题：

所有校验写死在事件里，不可复用
无法做提示区分

✅ 改进方式：抽离校验 + 可扩展

kotlin 复制代码

const validateForm = (form: UserForm) => {
  if (!form.name) return '姓名不能为空'
  if (form.name.length < 3) return '姓名过短'
  if (!form.age || isNaN(Number(form.age))) return '年龄格式错误'
  return ''
}

const onSubmit = () => {
  const msg = validateForm(form)
  if (msg) return message.error(msg)
  // ...
}

👉 Review 要点：

校验逻辑是否可复用？
是否便于单测？
提示是否明确？

📍 场景 2：权限控制逻辑写死

❌ 反例

ini 复制代码

<Button v-if="user.role === 'admin'">删除</Button>

问题：

无法集中管理
用户身份切换时易出错
无法与服务端权限匹配

✅ 推荐：

typescript 复制代码

const hasPermission = (perm: string) => user.permissions.includes(perm)

ini 复制代码

<Button v-if="hasPermission('can_delete')">删除</Button>

👉 Review 要点：

权限是否统一处理？
是否可扩展到路由、接口层？
是否易于调试？

📍 场景 3：复杂页面组件未解耦

❌ 嵌套组件塞一堆逻辑

xml 复制代码

// 页面结构
<Table data={data}>
  {data.map(row => (
    <tr>
      <td>{row.name}</td>
      <td>
        <Button onClick={() => doSomething(row.id)}>操作</Button>
      </td>
    </tr>
  ))}
</Table>

所有数据/逻辑/视图耦合一起
无法复用
改动难以测试

✅ 推荐：

ini 复制代码

<TableRow :row="row" @action="handleRowAction" />

xml 复制代码

// TableRow.vue
<template>
  <tr>
    <td>{{ row.name }}</td>
    <td><Button @click="emit('action', row.id)">操作</Button></td>
  </tr>
</template>

👉 Review 要点：

是否具备清晰的"数据流 → 逻辑流 → 视图层"结构？
是否把组件职责划分清楚？
是否拆分足够颗粒度便于测试？

📍 场景 4：接口调用未封装

❌ 直接 axios 写在组件中：

kotlin 复制代码

axios.get('/api/list?id=' + id).then(res => {
  this.list = res.data
})

问题：

接口不可复用
无法集中处理错误
改动接口时无法追踪引用

✅ 推荐：

typescript 复制代码

// services/user.ts
export const getUserList = (id: number) =>
  request.get('/api/list', { params: { id } })

// 页面中
getUserList(id).then(res => (this.list = res.data))

👉 Review 要点：

是否将接口层抽离为服务？
是否统一请求拦截、错误处理？
是否易于 Mock 和调试？

📍 场景 5：测试个锤子🔨

❌ 错误写法：组件中逻辑混杂难以测试

kotlin 复制代码

if (user.age > 18 && user.vipLevel > 3 && user.region === 'CN') {
  return true
}

问题：

没有语义抽象
不可测试

✅ 改进写法：

ini 复制代码

const isPremiumUser = (user: User) =>
  user.age > 18 && user.vipLevel > 3 && user.region === 'CN'

👉 Review 要点：

是否具备良好的可测试性？
是否便于 Jest/Vitest 测试用例编写？

✅ 最佳实践总结

Review 高级 Checklist

检查点	检查说明
✅ 表单逻辑	是否抽离，是否健壮
✅ 权限处理	是否统一管理，可扩展
✅ 页面复杂度	是否组件解耦，职责清晰
✅ 接口调用	是否封装为服务层，便于复用
✅ 可测试性	关键逻辑是否抽象、是否测试友好

🎯 尾声：从 Code Review 走向"架构推动者"

掌握 Code Review 不止是"找错"，而是：

帮助他人提升思维方式
用标准统一团队技术认知
用习惯推动系统演进