kaizen

Kaizen: 软件开发持续改进方法论

技能概述

Kaizen 是一套帮助开发者通过增量改进、设计防错和遵循标准化来持续提升代码质量的实用方法论，让你在每次编写代码时都能留下比之前更好的代码。

适用场景

1. 代码实现与重构

当你正在编写新功能或修改现有代码时，Kaizen 指导你采用"先让它工作，再让它清晰，最后让它高效"的三步迭代法，而不是一次性追求完美。每次只改进一个小问题，验证通过后再进行下一步。

2. 架构设计与决策

在做技术选型和架构设计时，应用 YAGNI（你不需要它）原则，只构建当前真正需要的功能，避免为假设的"未来需求"提前设计复杂的抽象层。当三个类似场景出现时再考虑抽象。

3. 错误处理与验证

在设计 API 和类型系统时，使用 Poka-Yoke 防错原则，让编译器和类型系统在编译阶段就能捕获错误，而不是等到运行时才发现。通过使无效状态无法表示，从根本上杜绝整类错误。

核心功能

1. 增量式持续改进

将大型改进分解为多次小的、可验证的变更。每次提交都应该让代码变得更好，哪怕只是更新一个过时的注释或删除一行死代码。这种"小步快跑"的方式可以降低风险，建立团队信心。

2. 设计时防错 (Poka-Yoke)

通过类型系统、验证层和前置防护，让错误在编译时就被发现，而不是等到生产环境。使用联合类型、品牌类型和 Result 类型等技术，使无效状态在类型层面就无法表示。

3. 标准化工作遵循

遵循项目现有的代码模式和约定，在引入新模式前先搜索代码库是否有现成方案。保持一致性胜过追求"更聪明"的个人风格，让代码更容易理解和维护。

4. 及时构建原则 (JIT)

只实现当前需求明确要求的功能，不预判未来可能需要的特性。在遇到性能瓶颈之前，选择最简单直接的实现方式。优化应该在测量之后进行，而不是基于假设。

常见问题

Kaizen 和大规模重构有什么区别？

Kaizen 强调持续的小改进，每次改动都可以独立验证和部署。大规模重构则是试图一次性重写大量代码，风险高且容易引入新问题。推荐的做法是：将大重构拆解为多个独立的小步骤，每次改进后都确保测试通过。

YAGNI 原则是否意味着不能做长远设计？

YAGNI 反对的是为"可能需要"的功能提前编写代码，而不是反对合理的架构设计。你仍然需要设计良好的模块边界和清晰的接口，但不需要实现那些没有明确需求支持的功能。当需求真正出现时再添加，那时候你对问题的理解也更深入。

防错设计会不会让类型定义变得很复杂？

有效的防错设计应该在不显著增加复杂度的前提下提高安全性。从简单的枚举类型和联合类型开始，只在确实能防止错误的地方引入品牌类型或高级类型特性。记住，目标是防止常见错误，而不是用类型系统解决所有问题。

如何在团队中推广 Kaizen 实践？

从 Code Review 开始，在审查时指出可以改进的小问题，而不是要求大改。建立 CLAUDE.md 文档记录团队约定，使用 Linter 和类型检查来自动化标准。最重要的是以身作则，在自己的代码中持续应用这些原则。

什么时候应该进行性能优化？

只有在实际测量确认某个操作是性能瓶颈后才进行优化。过早优化会浪费开发时间，增加代码复杂度，而且往往优化的是不是真正的问题。使用性能分析工具找到热点，优化后再次测量验证效果。