Back to Details

zero-tech-debt

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Zero Tech Debt

零技术债务

Rework the change from the intended end state, not from the historical path that produced the current patch.
从预期的最终状态出发重新设计变更，而非基于产生当前补丁的历史路径。

Steps

步骤

  1. State the intended end state in one or two sentences.
  2. Search for real callers before preserving compatibility. If a mode, prop, wrapper, route alias, or fallback has no current caller, delete it.
  3. Reshape around the final product surface. Prefer one clear component or flow over mode flags. Split only when it creates an obvious boundary such as state, layout, controls, or domain commands.
  4. Move shared rules to one place. Feature flags, permissions, route gating, URL state, and command naming should not be duplicated across pages or hidden in view components.
  5. Verify the intended flow. Test the new behavior and any deleted assumptions that affect navigation, permissions, or persisted state.
  1. 用一两句话描述预期的最终状态。
  2. 在保留兼容性之前，先查找实际调用方。如果某个模式、属性（prop）、包装器、路由别名或回退机制没有当前调用方，则将其删除。
  3. 围绕最终产品界面重新调整结构。优先选择清晰的单一组件或流程，而非模式标记。仅当拆分能形成明显边界（如状态、布局、控件或领域命令）时才进行拆分。
  4. 将共享规则集中到一处。功能标记（Feature flags）、权限、路由限制、URL状态和命令命名不应在多个页面中重复，也不应隐藏在视图组件中。
  5. 验证预期流程。测试新行为以及所有被删除的、会影响导航、权限或持久化状态的假设。

Rules

规则

  • Optimize for the code that should exist, not the smallest diff from the old shape.
  • Delete dead compatibility paths instead of making them better.
  • Do not invent a generic framework for one feature.
  • Keep the refactor scoped to what makes the final shape coherent.
  • Prefer names that describe product intent over implementation history.
  • 针对应存在的代码进行优化，而非追求与旧代码的最小差异。
  • 删除无用的兼容性路径，而非改进它们。
  • 不要为单一功能构建通用框架。
  • 保持重构范围仅围绕能使最终结构连贯的内容。
  • 优先选择描述产品意图的命名，而非体现实现历史的命名。