Dev_新功能开发-优快云博客

项目场景：

我需要开发一个新功能，我是在老功能的基础上，修修改改，还是另外弄一个新的？

或者说，弄个新的 A方法，然后去调用老功能的逻辑？

这是一个非常经典且重要的软件工程问题！没有绝对的“是”或“否”，但有一个核心原则和一系列需要考量的因素。

核心原则：追求高内聚、低耦合，同时平衡开发效率与长期维护成本。

场景A：高度相似，只是“锦上添花”
- 例子： 老功能是“查询用户列表”，新功能是“查询用户列表并支持按姓名模糊搜索”。
- 决策： 直接在老功能上修改。这是最直接、最高效的方式。你只需要在原有的查询逻辑上增加一个过滤条件即可。
场景B：部分相似，有共同的核心逻辑
- 例子： 老功能是“创建订单”，新功能是“快速创建订单”（跳过一些步骤，但创建订单的核心校验和保存逻辑是一样的）。
- 决策： 这是你提到的“A方法调用老功能逻辑”的最佳场景。 你需要重构老功能，提取核心逻辑。
  1. 将老功能中的核心逻辑（如订单校验、库存检查、数据保存）提取成一个独立的、可复用的函数或类（例如 OrderService.createOrderCore()）。
  2. 让老功能调用这个新的核心函数。
  3. 最后，新功能也调用这个核心函数，并实现自己独特的流程（如跳过某些步骤）。
- 优点： 避免了代码重复，符合DRY原则，未来再变也更容易。
场景C：完全不同或只是表面相似
- 例子： 老功能是“上传图片”，新功能是“生成用户统计报告”。
- 决策： 另起炉灶，写一个新的。 强行在旧代码上修改，只会引入不必要的复杂度和耦合，让代码变得难以理解和维护。

代码质量高（清晰、模块化、有测试）：
- 修改风险低。 即使是在上面说的“场景B”，你也可以放心地重构和提取逻辑。因为有测试覆盖，你不怕改坏旧功能。
- 倾向： 更倾向于在原有基础上修改或重构。
代码质量差（“屎山”、逻辑混乱、无测试）：
- 修改风险极高！ 你动一行代码都可能引发未知的崩溃。
- 倾向：
  - 如果相似度低（场景C），绝对要写新的。
  - 如果必须与之交互（场景B），采用“绞杀者模式”：将新功能开发为一个全新的、独立的服务或模块，然后通过API、消息队列等方式与老系统交互，逐步替代老功能，而不是直接修改它。
  - 如果非要修改且业务压力大，至少要为修改的部分和受影响的部分增加测试，但这通常很困难。

非常紧急： 如果业务方催得紧，而写一个新的、调用核心逻辑的A方法比理清和重构老代码更快，那么可以先采用“A方法”这种策略，哪怕代码有些重复，先上线再说（但要记下技术债）。
时间充裕： 如果时间允许，那么花时间重构老代码，提取公共逻辑，是为未来投资，长期来看收益巨大。

这是一个非常实用且常见的策略，它通常对应着上面的场景B。

具体做法和最佳实践：

不要直接复制粘贴老功能的代码。 这会创建重复代码，是维护的噩梦。
重构老功能：
- 将老功能中可以被共享的核心逻辑提取出来，形成一个独立的函数、类或服务。我们称之为 CommonCore。
- 修改老功能，让它也调用这个 CommonCore。
开发新功能：
- 创建你的新功能 A。
- 在 A 中，调用第二步提取出来的 CommonCore。
- 在 CommonCore 的前后，添加 A 自己独有的逻辑。