developer-profile

开发者档案

在实现、重构、修复、审查或扩展代码时使用；尤其适用于新功能、行为变更、重构、缺陷，以及组件／服务／工具／类型／测试或不熟悉的项目区域。

不可妥协的原则

1. 最后才添加代码。先检查完整的功能流程，然后再复用、重构、简化或删除现有代码，之后才创建任何新内容。
2. 绝不在旧代码上层层堆叠新代码。如果行为重叠，就合并或扩展现有流程，并删除过时的重复代码。
3. 功能变更应改善整个功能，而不只是追加文件。如果变更大部分都是新增内容，就停下来重新评估是否有复用、删除或重构的机会。
4. 在添加文件／函数／组件／服务／状态／类型／辅助工具之前，先确认没有现有内容能以更少的总代码量复用或扩展。
5. 优先减少代码：除非包装器、辅助工具、抽象、依赖、配置或层次能明显降低总体复杂度，否则不要引入。
6. 让结构与领域相匹配：按功能／库／状态等组织文件夹和文件；文件名应体现文件夹上下文，例如 Feature/Library/State/LibraryState.ts。
7. 解耦职责：分离 UI、状态、业务逻辑、数据访问、格式处理和副作用，使各部分可复用、可测试、可替换。
8. 遵循项目原有方式：沿用现有命名、导入、格式、状态／数据模式、测试和架构。

必须遵循的工作流程

1. 先检查：功能流程；类似实现；文件夹结构；共享组件／服务／工具／类型／状态／样式；错误处理；测试。
2. 先复用／重构／删除：移除重复／无用／过时的代码；扩展合适的抽象；不要创建并行的组件、服务、类型、状态、工具、样式或架构。
3. 只添加仍有必要的内容：采用最精简、清晰的方案；变更范围要集中；不要进行无关重写；除非有充分理由证明能简化整体，否则不要引入新依赖／架构。
4. 保持模块化／类型明确／易读：名称清晰；在有帮助时明确声明类型；避免使用 any；不要混合职责；不要引入隐式副作用。
5. 严格遵循项目结构：放在自然的位置；沿用现有文件命名、导入方式、格式、惯例和测试结构。
6. 最终总结必须说明：复用了／扩展了什么；删除了／简化了什么；为什么新代码不可避免。