Back to Details

bullet-tracer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Bullet Tracer Skill

追踪子弹开发技巧

From The Pragmatic Programmer: "Use Tracer Bullets to Find the Target" — build a minimal end-to-end vertical slice that touches all layers first, then expand.
出自《程序员修炼之道》：“用追踪子弹找到目标”——先构建一个覆盖所有层级的最小化端到端垂直切片，再进行扩展。

Compatibility Note

兼容性说明

Not all tickets/features are fully compatible with the tracer bullet approach (e.g., pure refactors, config changes, single-layer fixes). Be smart: apply tracer bullet concepts to compatible parts, use general best practices for the rest.
并非所有需求单/功能都完全适配追踪子弹方法（例如纯重构、配置变更、单层级修复）。灵活处理：对适配的部分应用追踪子弹理念，其余部分使用通用最佳实践。

Philosophy

核心理念

  • Tracer bullet != prototype: You keep the code, it becomes the foundation
  • Vertical slice: Touch ALL layers (UI → API → logic → DB → tests) in one thin path
  • Fast feedback: Validate architecture and integration points early
  • Hardcoded is OK: Initial tracer can use minimal/fake data
  • 追踪子弹 ≠ 原型：你会保留代码，它将成为基础
  • 垂直切片：在一条精简路径中覆盖所有层级（UI → API → 逻辑 → 数据库 → 测试）
  • 快速反馈：尽早验证架构和集成点
  • 硬编码可接受：初始追踪可以使用最小化/模拟数据

Workflow

工作流程

Phase 1: Tracer Bullet (MUST DO FIRST)

阶段1：追踪子弹（必须优先完成）

  1. Identify all layers the feature touches (e.g., frontend, API, service, DB, config)
  2. Implement the thinnest possible path through ALL layers:
    • One happy path only
    • Hardcoded values acceptable
    • Skip edge cases, validation, error handling
    • Must be runnable/testable end-to-end
  3. Write one integration test that exercises the full path
  4. Verify it works — run the test, manually test if needed
  1. 识别功能涉及的所有层级（例如前端、API、服务、数据库、配置）
  2. 实现贯穿所有层级的最精简路径：
    • 仅覆盖一个正常流程
    • 允许使用硬编码值
    • 跳过边缘情况、验证和错误处理
    • 必须可端到端运行/测试
  3. 编写一个集成测试来覆盖完整路径
  4. 验证功能可用——运行测试，必要时进行手动测试

Phase 2: Expand

阶段2：扩展

Only after tracer works, expand systematically:
  1. Replace hardcoded values with real implementations
  2. Add validation and error handling
  3. Add edge cases and additional paths
  4. Add unit tests for individual components
  5. Refactor for production quality
仅在追踪子弹功能可用后，再系统性地扩展：
  1. 将硬编码值替换为真实实现
  2. 添加验证和错误处理
  3. 添加边缘情况和额外路径
  4. 为单个组件添加单元测试
  5. 重构以达到生产环境质量

Example

示例

Feature: "User can save favorite items"
功能：“用户可以保存收藏项”

Tracer (Phase 1):

追踪子弹（阶段1）：

- Frontend: Add button that calls POST /api/favorites with hardcoded itemId
- API: Endpoint that inserts into favorites table
- DB: Create favorites table with user_id, item_id
- Test: Integration test that clicks button, verifies DB row exists
- Frontend: Add button that calls POST /api/favorites with hardcoded itemId
- API: Endpoint that inserts into favorites table
- DB: Create favorites table with user_id, item_id
- Test: Integration test that clicks button, verifies DB row exists

Expand (Phase 2):

扩展（阶段2）：

  • Real item selection UI
  • Validation (item exists, not already favorited)
  • Error handling and user feedback
  • Unfavorite functionality
  • List favorites page
  • Unit tests for each layer
  • 真实的项选择UI
  • 验证（项存在、未被收藏过）
  • 错误处理和用户反馈
  • 取消收藏功能
  • 收藏项列表页面
  • 各层级的单元测试

Rules

规则

  1. NEVER skip the tracer phase — always build e2e first
  2. NEVER expand before tracer works — resist the urge to "do it properly"
  3. Keep tracer minimal — if you're adding "nice to haves", stop
  4. Tracer must touch ALL layers — if it doesn't, it's not a tracer
  5. Tracer must be testable — if you can't verify it works, add a test
  1. 绝不要跳过追踪子弹阶段——始终先构建端到端功能
  2. 绝不要在追踪子弹可用前进行扩展——克制“一步到位”的冲动
  3. 保持追踪子弹的精简性——如果你在添加“锦上添花”的功能，请停止
  4. 追踪子弹必须覆盖所有层级——如果没有，那就不是追踪子弹
  5. 追踪子弹必须可测试——如果你无法验证它可用，请添加测试

Anti-patterns

反模式

❌ Building the perfect DB schema before any code
❌ Implementing full validation before happy path works
❌ Writing all unit tests before integration test
❌ Building frontend in isolation from backend
❌ "I'll connect it later"
❌ 在编写任何代码前先构建完美的数据库架构
❌ 在正常流程可用前先实现完整的验证
❌ 在编写集成测试前先编写所有单元测试
❌ 独立于后端构建前端
❌ “我之后再连接它”

Checklist

检查清单

Before moving to Phase 2, verify:
  • Code touches every layer the feature needs
  • Can run/test the feature end-to-end
  • At least one integration test passes
在进入阶段2前，验证：
  • 代码覆盖了功能所需的所有层级
  • 可以端到端运行/测试该功能
  • 至少有一个集成测试通过