AI辅助软件工程与OOPS、SOLID原则及文档化

自上而下方法定义"做什么"，自下而上方法构建"如何做"。面向对象编程（OOP）和SOLID原则实现了灵活、可复用的设计。AI可以提供帮助，但前提是需要清晰的结构和上下文。

自上而下与自下而上的方法

自上而下和自下而上是两种分而治之的问题解决方法。

什么是自上而下方法？

将任何问题分解，直到能够将其安排到机器、操作系统、SDK或软件系统中。

什么是自下而上方法？

拥有可插拔的解决方案或构建块（如机器、操作系统、SDK），在给定问题时将这些构建块组合起来构建完整的解决方案。

OOPS如何促进软件中的自下而上方法？

通过面向对象编程（OOPS），我们开始构建更多可复用和组合的软件构建块。从Java、C++等OOPS语言中涌现出了许多提供各种组件的库。

OOPS和自下而上方法解决问题了吗？

是的，但只是部分解决。大多数需求仍然来自顶层（即业务视角），我们必须使用自上而下的方法将这些组件拼接在一起以满足需求。

业务环境不断变化。我们需要可复用组件，但也需要将它们插入系统中来解决业务问题。业务识别"需求"，然后转换为"用户故事"，这些用例再次转换为"需求规范"。正如俗话所说，1个需求变成100个用户故事，100个用户故事变成1000个需求。需求也随时间变化，从而改变用户故事和需求规范。这种分解仍然是自上而下的。

这是一个实际示例：

业务需求 “通过启用个性化购物体验提高客户保留率”

用户故事

• 作为回头客，我希望看到基于我之前购买的商品推荐，以便更快找到相关产品
• 作为登录用户，我希望在主页上看到最近浏览的商品，以便继续购物
• 作为客户，我希望将商品保存到愿望清单，以便以后重新访问

技术规范（针对故事#1）

• API：GET /api/recommendations/{userId}
• 数据源：购买历史、用户行为跟踪
• 算法：协同过滤或外部ML服务
• 安全性：符合GDPR的数据使用和选择退出功能
• 前端集成：主页布局中的轮播组件

这种分解展示了业务策略如何导致具体的技术成果。虽然可复用组件有助于实现这些规范，但需求流仍然是自上而下的。

如何应对快速变化的业务需求？

为了适应这种变化的环境，我们应该利用SOLID原则：

• 单一职责原则（SRP）：每个模块或类应该做好一件事
• 开闭原则（OCP）：组件应该对扩展开放，对修改关闭
• 里氏替换原则（LSP）：派生类型必须可替换其基类型
• 接口隔离原则（ISP）：倾向于许多小而特定的接口，而不是大而通用的接口
• 依赖倒置原则（DIP）：高层模块不应依赖低层模块，两者都应依赖抽象

控制反转原则在组合组件时，简单来说就是"调用"，也称为依赖注入。虽然我们渴望在最高成熟度级别工作，如运行时依赖切换，但我们应该能够构建可复用组件，每个组件都有单一职责，每个都对扩展开放且对修改关闭，每个都准备好被替换。

虽然每个SOLID原则都有帮助，但从依赖注入原则开始。这是一个缺失的部分，可以帮助我们减缓快速变化的需求环境，增加我们的周转时间，并介绍其他原则。

如何在使用过程中应用AI辅助？

即使明天出现AI操作系统，使用可复用组件构建软件的艺术也不会改变，但AI辅助应该了解市场上所有维护良好且安全可用的可复用组件和库。AI辅助应该了解当前开发系统中存在的组件如何工作、它们的职责，以及如何扩展和替换它们。在解决业务需求时，我们应该让自己了解AI辅助的需求。

重申一下：

• 需要维护良好的可复用组件和库的目录
• 需要需求、用户故事和需求规范文档
• 需要当前软件组件的文档，包括职责、可扩展性和可替换性

当前的AI助手没有做到所需的吗？是的，但部分没有。虽然LLM正在尽力理解整个工作空间，但只有开发人员的指令才能指导AI助手。在本文中，我们只提出了系统性地有效利用AI助手的方法。

结论

在本文中，我们强调了自下而上和自上而下的方法，以及自上而下方法如何改变需求、用户故事和需求，我们如何采用OOPS原则，为什么要依赖SOLID原则（特别是依赖注入和基于抽象的依赖）来自下而上构建软件，以及如何通过准备能够与开发人员意图对齐的相关文档来使用AI扩展这些方法。