软件工程最佳实践 — 从需求到上线
软件工程不只是写代码，而是一个从需求理解到生产运维的完整生命周期。在企业级 SAP 开发中，缺乏规范流程的项目往往导致代码质量差、维护成本高、上线风险大。本文从实践角度，系统梳理软件工程全生命周期的最佳实践，特别关注 SAP/ABAP 开发场景。
一、需求分析
1.1 用户故事
用户故事（User Story）是敏捷开发中表达需求的标准格式：
作为 [角色]，我希望 [功能]，以便 [价值]
示例：
作为 采购员，我希望 在审批被拒时收到邮件通知，以便 我能及时修改采购申请并重新提交。好的用户故事遵循 INVEST 原则：
- Independent（独立）：用户故事之间尽量独立，减少依赖。
- Negotiable（可协商）：用户故事是讨论的起点，而非固定契约。
- Valuable（有价值）：每个故事必须为用户或业务提供可感知的价值。
- Estimable（可估算）：开发团队能够估算工作量。
- Small（小）：一个故事应在一个 Sprint 内完成。
- Testable（可测试）：有明确的验收标准。
1.2 验收标准
每个用户故事必须定义验收标准（Acceptance Criteria），通常使用 Given-When-Then 格式：
Given 采购申请金额超过 10000 元
When 采购员提交申请
Then 申请自动路由至部门经理审批
Given 采购申请金额不超过 10000 元
When 采购员提交申请
Then 申请自动审批通过1.3 优先级排序
需求优先级常用 MoSCoW 方法：
| 优先级 | 含义 | 示例 |
|---|---|---|
| Must Have | 必须实现，否则系统无法上线 | 基本的采购订单创建流程 |
| Should Have | 重要但非关键，可延后一个 Sprint | 审批超时自动提醒 |
| Could Have | 锦上添花，时间允许才做 | 订单历史趋势图表 |
| Won't Have | 明确不在当前范围 | 移动端审批（Phase 2） |
二、架构设计
2.1 DDD 领域驱动设计
领域驱动设计（Domain-Driven Design, DDD）强调以业务领域为中心进行软件设计，核心概念包括：
- 统一语言（Ubiquitous Language）：开发团队与业务团队使用相同的术语，消除沟通歧义。例如在 SAP 语境中，"采购订单"（Purchase Order）而非"买东西的表单"。
- 限界上下文（Bounded Context）：将大型系统划分为语义边界明确的子域。例如"订单管理"、"库存管理"、"财务管理"各自有独立的模型。
- 聚合（Aggregate）：一组必须保持一致性的对象集合。例如"采购订单"及其"行项目"构成一个聚合，行项目不能脱离订单独立存在。
- 领域事件（Domain Event）：记录业务中发生的重要事件，用于解耦模块间通信。例如"订单已创建"、"库存已扣减"。
2.2 微服务 vs 单体
| 对比项 | 单体架构 | 微服务架构 |
|---|---|---|
| 开发效率 | 初期高，后期降低 | 初期低，后期稳定 |
| 部署复杂度 | 简单（一个部署单元） | 复杂（多个服务独立部署） |
| 技术栈灵活性 | 统一技术栈 | 每个服务可选不同技术栈 |
| 扩展性 | 整体扩展 | 按服务独立扩展 |
| 故障影响 | 局部故障可能拖垮整体 | 故障隔离在单个服务 |
| 数据一致性 | 强一致性（本地事务） | 最终一致性（分布式事务） |
| SAP 场景建议 | SAP 核心内的开发 | SAP BTP 上的扩展开发 |
SAP 场景的建议：SAP S/4HANA 核心系统本身是单体架构，不建议拆分。但在 SAP BTP 上构建扩展应用时，应采用微服务架构，每个扩展功能作为独立服务部署在 Cloud Foundry 或 Kyma 上。
2.3 SAP BTP 扩展架构
SAP BTP 提供三种扩展模式：
| 扩展模式 | 适用场景 | 技术栈 | 部署环境 |
|---|---|---|---|
| In-App 扩展 | 轻量级 UI/逻辑调整 | SAP Fiori Embedding、Adobe Forms | S/4HANA 内部 |
| Side-by-Side 扩展 | 独立业务流程扩展 | Node.js / Java / Python | SAP BTP Cloud Foundry |
| Steampunk（ABAP Environment） | ABAP 开发者的云原生开发 | ABAP（云版本） | SAP BTP ABAP Environment |
Side-by-Side 扩展的典型架构：
- 前端：SAP Fiori Elements / SAP UI5，部署在 SAP BTP HTML5 Application Repository。
- 后端：Node.js/Java 微服务，通过 SAP BTP Destination 服务连接 S/4HANA 的 OData API。
- 数据库：SAP HANA Cloud 作为扩展数据存储。
- 事件：通过 SAP Event Mesh 实现与 S/4HANA 的事件驱动集成。
三、编码规范
3.1 Clean Code 原则
Clean Code 的核心原则在所有编程语言中通用：
- 有意义的命名：变量、方法、类的名称应清晰表达意图。避免
a1、temp、data等模糊命名。 - 单一职责：一个方法只做一件事，一个类只有一个变更原因。
- 短小精悍：方法不超过 20 行，类不超过 200 行（理想值）。
- 避免副作用：方法不应产生调用者预期之外的副作用。
- DRY（Don't Repeat Yourself）：消除重复代码，提取公共方法。
- 注释补充而非替代：好的代码自身可读，注释用于解释"为什么"而非"做什么"。
3.2 代码审查
代码审查（Code Review）是保障代码质量的核心实践：
- 审查范围：每次审查不超过 400 行代码，超过则分批审查。
- 审查重点：逻辑正确性 > 设计合理性 > 命名规范 > 代码风格。
- 审查态度：对代码不对人，提建设性意见而非批评。
- 审查工具：ABAP 开发使用 SAP ADT（ABAP Development Tools）的 Transport Request 审查；BTP 开发使用 GitHub/GitLab 的 Pull Request。
3.3 ABAP 编程规范
SAP 官方发布的 ABAP Programming Guidelines 核心规则：
- 优先使用 ABAP Objects：新代码使用面向对象方式（类和方法），而非过程式（FORM/PERFORM）。
- 使用新语法：ABAP 7.40+ 的新语法（内联声明、构造运算符、表表达式）更简洁安全。
- 避免访问全局数据：不直接读写全局变量和数据库表，通过方法参数传递数据。
- 错误处理：使用异常（CX_CLASS）而非返回码（SY-SUBRC），新代码使用基于类的异常。
- 不修改 SAP 标准对象：通过 BADI、Enhancement Spots 扩展，不修改标准程序。
- SAP S/4HANA 兼容性：避免使用已废弃的语法和功能模块，定期运行 ATC（ABAP Test Cockpit）检查。
" 不推荐：过程式 + 旧语法
DATA: lt_mara TYPE STANDARD TABLE OF mara,
ls_mara TYPE mara.
SELECT * FROM mara INTO TABLE lt_mara WHERE matnr IN s_matnr.
LOOP AT lt_mara INTO ls_mara.
WRITE: / ls_mara-matnr.
ENDLOOP.
" 推荐：面向对象 + 新语法
SELECT matnr, ersda, matkl FROM mara
INTO TABLE @DATA(lt_mara)
WHERE matnr IN @s_matnr.
LOOP AT lt_mara INTO DATA(ls_mara).
cl_demo_output=>write( |物料: { ls_mara-matnr } 类型: { ls_mara-matkl }| ).
ENDLOOP.
cl_demo_output=>display( ).四、测试策略
4.1 测试金字塔
测试金字塔是测试策略的经典框架：
| 测试层级 | 数量占比 | 执行速度 | 覆盖范围 | SAP 实现方式 |
|---|---|---|---|---|
| 单元测试 | 70% | 毫秒级 | 单个方法/函数 | ABAP Unit（CL_AUNIT_ASSERT） |
| 集成测试 | 20% | 秒级 | 模块间交互 | 手动 / ECATT |
| E2E 测试 | 10% | 分钟级 | 端到端业务流程 | SAP CBTA / Selenium |
4.2 ABAP Unit 测试
ABAP Unit 是 SAP 内置的单元测试框架，所有 ABAP 开发都应编写单元测试：
CLASS lcl_calculator DEFINITION.
PUBLIC SECTION.
METHODS: add IMPORTING iv_a TYPE i iv_b TYPE i
RETURNING VALUE(rv_result) TYPE i.
ENDCLASS.
CLASS lcl_calculator IMPLEMENTATION.
METHOD add.
rv_result = iv_a + iv_b.
ENDMETHOD.
ENDCLASS.
" 单元测试类
CLASS ltc_calculator DEFINITION FOR TESTING
RISK LEVEL HARMLESS DURATION SHORT.
PRIVATE SECTION.
METHODS: test_add FOR TESTING.
ENDCLASS.
CLASS ltc_calculator IMPLEMENTATION.
METHOD test_add.
DATA(lo_calc) = NEW lcl_calculator( ).
cl_abap_unit_assert=>assert_equals(
act = lo_calc->add( iv_a = 3 iv_b = 5 )
exp = 8
msg = '加法计算结果不正确' ).
ENDMETHOD.
ENDCLASS.4.3 测试替身（Test Double）
在单元测试中，被测代码依赖的外部资源需要用测试替身替代：
- Stub：返回预设值的轻量替身。
- Mock：可验证调用行为的替身。
- Fake：有实际工作逻辑的简化实现（如内存数据库替代真实数据库）。
在 ABAP 中，通过接口（INTERFACE）实现依赖注入，测试时注入 Mock 实现：
" 定义接口
INTERFACE lif_product_reader.
METHODS: get_product IMPORTING iv_matnr TYPE matnr
RETURNING VALUE(rs_product) TYPE mara.
ENDINTERFACE.
" 真实实现（从数据库读取）
CLASS lcl_product_reader_db DEFINITION.
PUBLIC SECTION.
INTERFACES: lif_product_reader.
ENDCLASS.
" 测试替身（返回预设数据）
CLASS lcl_product_reader_mock DEFINITION.
PUBLIC SECTION.
INTERFACES: lif_product_reader.
DATA: ms_stub_product TYPE mara.
ENDCLASS.五、持续集成/持续部署
5.1 CI/CD 流水线
持续集成（CI）确保每次代码变更都经过自动化验证，持续部署（CD）将通过验证的代码自动发布到目标环境：
| CI/CD 阶段 | ABAP 开发 | BTP 扩展开发 |
|---|---|---|
| 代码提交 | SAP Transport Request | Git Push / Pull Request |
| 自动构建 | abapGit / SAP ADT | npm / maven / pip build |
| 静态检查 | ATC（ABAP Test Cockpit） | ESLint / SonarQube |
| 单元测试 | ABAP Unit | JUnit / Jest / pytest |
| 集成测试 | eCatt | Postman / Newman |
| 部署 | 传输管理（STMS） | SAP BTP CLI / CF Push |
5.2 Git 与传输管理
SAP 开发中的版本管理策略：
- 传统方式：通过 SAP 传输管理系统（STMS）管理变更，Transport Request 在 DEV→QAS→PRD 链路中流转。
- 现代方式：使用 abapGit 将 ABAP 代码同步到 Git 仓库，利用 Git 的分支、合并、回滚能力增强版本管理。
- gCTS：SAP Git-Enabled Change and Transport System，将 Git 与 CTS 集成，实现 Git 工作流驱动的传输管理。
5.3 分支策略
推荐的 Git 分支策略（适用于 BTP 扩展开发）：
- main：生产就绪代码，始终可部署。
- develop：开发集成分支，包含下一个版本的所有功能。
- feature/*：功能分支，从 develop 创建，完成后合并回 develop。
- release/*：发布分支，从 develop 创建，用于最终测试和修复。
- hotfix/*：紧急修复分支，从 main 创建，修复后合并回 main 和 develop。
六、运维监控
6.1 日志管理
结构化日志是运维可观测性的基础：
- ABAP 日志：使用
BAL_LOG_CREATE/BAL_LOG_MSG_ADD写入应用日志（SLG1 查看），而非 WRITE 语句。 - BTP 应用日志：使用 SAP BTP Application Logging Service，日志自动收集到 SAP BTP Cockpit。
- 日志级别：ERROR（错误） > WARN（警告） > INFO（关键信息） > DEBUG（调试），生产环境设为 INFO。
6.2 告警机制
关键指标的告警设置：
| 监控指标 | 告警阈值 | 检查方式 |
|---|---|---|
| SAP 系统响应时间 | 平均 > 2 秒 | ST03N 工作负载监控 |
| 后台作业失败率 | 日失败 > 5% | SM37 作业监控 |
| 数据库 CPU 利用率 | 持续 > 80% | DBACOCKPIT |
| 短转储（Dump）数量 | 日新增 > 10 个 | ST22 转储分析 |
| BTP 应用实例状态 | 实例 Down | BTP Cockpit / Prometheus |
| 接口调用失败率 | 日失败 > 1% | SAP Integration Suite 监控 |
6.3 性能基线
建立性能基线（Baseline）是发现性能退化的关键：
- 基线建立：上线后 1 个月内，在正常业务负载下记录关键指标（报表执行时间、接口响应时间、批量作业运行时间）。
- 定期对比：每月将当前性能数据与基线对比，识别退化趋势。
- 性能回归测试：每次系统升级或大规模变更后，执行性能回归测试，确认关键流程响应时间未退化。
- 容量规划：基于业务增长趋势和性能数据，提前规划硬件/云资源扩容。
来源说明：本文综合了 Clean Code、DDD 等软件工程经典方法论，以及 SAP 官方 ABAP Programming Guidelines 和 SAP BTP 扩展架构最佳实践。