跳到主要内容

如何在有限时间内交付高质量代码

问题​

时间紧急的情况下，你如何保证代码质量？如何平衡速度和质量？

回答思路​

1. 核心观点​

核心认知

速度和质量不是非此即彼。短期内可能有矛盾，但长期看高质量代码反而更快。关键是找到合理的平衡点。

2. 质量分层策略​

不是所有代码都需要同等质量标准。按重要性分层：

层级代码类型质量标准测试要求
P0 核心支付、登录、数据提交最高标准单测 + E2E
P1 重要核心业务逻辑、数据展示高标准单测覆盖
P2 一般常规页面、管理后台基本标准关键路径测试
P3 次要内部工具、临时页面能跑就行手动测试

3. 提速手段​

MVP 思维​

MVP 思维：先做核心，再迭代
// Phase 1: MVP（3天）—— 核心功能可用
// ✅ 基础表单提交
// ✅ 数据列表展示
// ❌ 高级搜索（v2）
// ❌ 批量操作（v2）
// ❌ 数据导出（v2）

// Phase 2: 增强（下个迭代）
// ✅ 高级搜索
// ✅ 批量操作

// Phase 3: 完善（后续）
// ✅ 数据导出
// ✅ 性能优化

4. 保质手段​

即使时间紧，这些底线不能放：

底线原因耗时
TypeScript 类型防止类型错误，编码时就能发现 Bug几乎不额外耗时
ESLint 保持开启自动避免低级错误零额外成本
核心逻辑测试支付、登录等绝不能出错占总时间 10-15%
Code Review再赶也要有人 Review30 分钟
错误处理至少有基本的错误兜底少量时间

5. 紧急情况下的 TODO 策略​

标记技术债，后续偿还
// TODO: TECH-DEBT [2024-03-15] 
// 当前使用 any 绕过类型检查，下个迭代需要补全类型
// 关联 issue: #1234
const processData = (data: any): any => {
  // 快速实现的代码...
};

// TODO: OPTIMIZE [2024-03-15]
// 当前全量加载列表数据，数据量大时需要改为虚拟滚动
// 预估影响：>1000条数据时可能卡顿

// TODO: TEST [2024-03-15]
// 缺少边界条件测试（空数组、null值），下个迭代补充

关键：记录技术债并创建 issue 追踪，不要留没有追踪的 TODO。

6. 时间评估技巧​

技巧说明
拆分任务把需求拆到 2-4 小时的粒度
乘以系数自己估的时间 × 1.5（Buffer）
识别风险标注不确定的部分，提前沟通
及时反馈发现要延期时，尽早告知团队

常见面试问题​

Q1: 产品要求一周上线，你评估需要两周，怎么办？​

答案：

  1. 拆分需求：和产品一起区分 Must-have 和 Nice-to-have
  2. 协商 MVP：一周内做 Must-have，其余排到下个迭代
  3. 明确风险：如果强行压缩，可能出现的质量问题
  4. 提出方案：给出几种时间/范围的组合方案让产品选择

核心原则：不要虚报时间（降低信任），也不要硬扛（质量出问题更糟）。

Q2: 你怎么看"先上线再优化"的做法？​

答案：

关键是有底线：

  • ✅ 可接受：非核心功能先简单实现，后续优化
  • ✅ 可接受：性能未达最优但在可接受范围内
  • ❌ 不可接受：核心逻辑有 Bug 但"先上后改"
  • ❌ 不可接受：安全漏洞或数据问题"先上后改"

"先上线再优化"的前提是：

  1. 记录了技术债，有追踪
  2. 下个迭代确实会改（不是嘴上说说）
  3. 不影响核心功能和用户体验

Q3: 代码质量和业务价值哪个更重要？​

答案：

业务价值是目的，代码质量是手段。但这不意味着可以牺牲质量：

  • 短期：业务价值优先，合理降低非核心部分的标准
  • 长期：低质量代码会拖累业务迭代速度
  • 底线：安全、核心逻辑、用户体验的质量不能妥协

好的工程师能在两者之间找到平衡点。

相关链接​