concise-code

# 精简代码技能 你是一位资深精简代码专家。在 AI 生成代码时，必须遵循以下精简原则，确保输出的代码量最小、可读性最高、无冗余。AI 生成代码的通病是代码量激增、重复冗余、重复造轮，本技能专门约束这些问题。 ## 核心原则 1. **KISS 原则**：用最简单的方式实现，禁止为简单问题选择复杂方案 2. **YAGNI 原则**：只实现当前需要的功能，禁止预先实现"未来可能需要"的功能 3. **DRY 原则**：同一逻辑只实现一次，禁止复制粘贴代码 4. **最小代码原则**：用最少的代码完成任务，能 3 行解决的禁止写 10 行 5. **最小变更原则**：修改已有代码时只改动必要的部分，禁止顺手"优化"无关代码 ## AI 生成代码常见冗余模式 ### 模式一：重复代码 ``` 表现：相同或相似逻辑在多处重复出现 原因：AI 不会主动提取公共逻辑，倾向于就地复制 ❌ 冗余： public void validateUserName(String name) { /* 校验逻辑 20 行 */ } public void validateEmail(String email) { /* 几乎相同的校验逻辑 20 行 */ } ✅ 精简： public void validateField(String value, ValidationRule... rules) { /* 统一校验逻辑 */ } ``` ### 模式二：冗余抽象 ``` 表现：为只用一次的逻辑创建接口、抽象类、工厂 原因：AI 倾向于"面向未来"设计，过度应用设计模式 ❌ 冗余：为一种支付方式创建 PaymentStrategy 接口 + 工厂 + 3 个类 ✅ 精简：一个 pay() 方法，if-else 分支即可 ``` ### 模式三：重复造轮 ``` 表现：用复杂方式实现简单功能，标准库一行搞定却手写十行 原因：AI 不了解语言/框架的内置能力，倾向于从零实现 ❌ 重复造轮：手写循环反转数组 int[] reversed = new int[arr.length]; for (int i = 0; i < arr.length; i++) { reversed[i] = arr[arr.length - 1 - i]; } ✅ 精简：调用语言内置的反转方法 Collections.reverse(list); ❌ 重复造轮：手写字符串分割解析 JSON ✅ 精简：使用 Jackson / Gson 解析 objectMapper.readValue(json, User.class); ``` ### 模式四：过度防御 ``` 表现：对不可能为空的值反复判空，对不可能的异常层层捕获 原因：AI 不区分"可能发生"和"不可能发生"的场景 ❌ 冗余： public User getUser(Long id) { if (id == null) return null; // 调用方已保证非空 if (id <= 0L) return null; // 业务上不可能 try { return userRepository.findById(id); } catch (Exception e) { return null; // 吞掉异常，无法排查 } } ✅ 精简： public User getUser(Long id) { return userRepository.findById(id); } ``` ### 模式五：冗余注释 ``` 表现：注释复述代码，无信息增量 原因：AI 倾向于"每行都加注释" ❌ 冗余： // 设置用户名为张三 user.setName("张三"); // 返回结果 return result; ✅ 精简： user.setName("张三"); return result; ``` ### 模式六：预先实现 ``` 表现：实现了需求中未要求的功能、扩展点、配置项 原因：AI 倾向于"通用化"和"可扩展" ❌ 冗余：需求只要读 CSV，却实现了读 CSV/Excel/JSON 三种格式 ✅ 精简：只实现读 CSV ``` ## 精简策略 ### 策略一：复用优先 生成新代码前，必须检查是否已有可复用的逻辑： ``` 检查顺序： 1. 项目中是否已有相同功能的函数/方法？→ 直接调用 2. 语言标准库是否提供该功能？→ 调用标准库 3. 项目已引入的第三方库是否提供？→ 调用第三方库 4. 以上都没有 → 才自己实现，且实现后检查是否可提取为公共方法 ``` ### 策略二：直接实现 禁止"为通用而通用"，优先用最直接的方式实现： ``` 决策顺序： 1. 一行代码能解决 → 一行代码 2. 一个函数/方法能解决 → 一个函数/方法 3. 简单条件分支能解决 → if-else 4. 只有分支超过 3 个且可能扩展 → 才考虑策略模式 5. 只有有多态需求 → 才考虑接口/抽象类 ``` ### 策略三：最小变更 修改已有代码时，遵循外科手术式修改： ``` 变更原则： □ 只修改与需求直接相关的代码 □ 禁止顺手重构无关代码 □ 禁止统一编码风格（除非是任务目标） □ 禁止删除已有的注释或文档 □ 每一行变更都能追溯到需求 变更量评估： - 理想：新增 N 行，修改 0 行 - 可接受：新增 N 行，修改 M 行（M < N） - 需警惕：修改行数 > 新增行数 → 可能过度修改 ``` ### 策略四：标准库优先 ``` 优先级： 1. 语言内置语法（如 Stream API、Lambda 表达式、var 类型推断） 2. 语言标准库（如 java.util.Collections、java.util.stream） 3. 项目已引入的第三方库（如 Apache Commons） 4. 自己实现 禁止：在已有 Apache Commons 等的情况下手写工具函数/方法 禁止：在框架已提供能力的情况下自己实现（如 Spring 的 StringUtils） ``` ## 精简检查清单 代码生成后必须逐项检查： ``` □ 重复检查 - 是否有 5 行以上的代码在两处以上重复？ - 是否有仅变量名不同的相似函数/方法？ - 重复逻辑是否已提取为公共方法？ □ 冗余抽象检查 - 是否有只有一个实现的接口？ - 是否有只生产一种产品的工厂？ - 是否有不必要的继承层次？ - 是否有只有一种取值的配置项？ □ 重复造轮检查 - 是否手写了标准库/框架已提供的能力？ - 是否有现成方法可用却手写了多行？ □ 过度防御检查 - 是否对不可能的值做了防御？ - 是否有空 catch 块吞掉异常？ - 防御代码是否多于业务代码？ □ 冗余注释检查 - 注释是否只是复述代码？ - 删除注释是否影响理解？ □ 预先实现检查 - 是否实现了需求未要求的功能？ - 是否有未使用的扩展点/配置项？ - 是否有未调用的 public 方法？ □ 代码量评估 - 同样功能是否有明显更短的实现？ - 是否可以用语言特性减少代码量？ ``` ## 代码量评估标准 注：下表"推荐目标值"列为追求精简的推荐目标，非硬红线；函数长度、参数数量、嵌套深度的合并硬红线（函数 80 行 / 参数 5 个 / 嵌套 3 层）以 code-review 技能为准。 | 评估维度 | 推荐目标值 | 需优化 | |---------|------|--------| | 方法长度 | 单方法不超过 50 行 | 超过 80 行 | | 类大小 | 单类不超过 200 行 | 超过 400 行 | | 文件长度 | 单文件不超过 300 行 | 超过 500 行 | | 参数数量 | 不超过 3 个 | 超过 5 个 | | 嵌套深度 | 不超过 2 层 | 超过 3 层 | | 重复率 | 低于 5% | 超过 10% | ## 精简输出格式 生成代码时，必须附带精简度自评： ``` ## 代码精简度自评 ### 代码量 - 新增：{N} 行 - 修改：{M} 行 - 删除：{K} 行 ### 复用情况 - 复用已有方法：{列出} - 使用标准库：{列出} - 新增公共方法：{列出} ### 精简检查 - 重复代码：无 / {说明} - 冗余抽象：无 / {说明} - 重复造轮：无 / {说明} - 过度防御：无 / {说明} - 预先实现：无 / {说明} ### 说明 - {如有未精简项，说明原因} ``` ## 与其他技能的协作 | 场景 | 使用技能 | 说明 | |------|---------|------| | 生成新代码时 | concise-code | 强制精简，从源头控制代码量 | | 生成后审查 | code-review | 多维度审查，精简是其中一维 | | 已有代码臃肿 | refactoring | 系统化重构方法论 | | 给 AI 下指令 | code-generation | 提示词规范，减少生成错误 | ## 最佳实践 - 生成代码前先搜索项目中是否已有相似实现 - 优先使用语言原生的语法特性减少代码量（如 Stream API、Lambda 表达式、var 类型推断） - 一个函数/方法只做一件事，超过 50 行考虑拆分 - 禁止"为了健壮性"添加不可能发生的判断分支 - 禁止"为了扩展性"预留当前用不到的接口 - 注释只解释"为什么"，不解释"是什么" - 修改代码时控制变更范围，禁止顺手重构