手写绩效考核系统避坑指南：解决版本升级API失效痛点
上次发版，生产环境直接炸了。HR总监冲进办公室，指着屏幕上的 500 错误骂了十分钟。原因很简单：底层权限库升了个大版本，getUserRoles 接口参数变了，导致整个绩效考核系统的评分逻辑全挂了。
那一刻我深刻意识到，核心业务逻辑绝不能完全依赖第三方黑盒 API。为了彻底解决版本升级后 API 全变了这个噩梦，我决定手写实现一套轻量级的考核引擎。别觉得手写是偷懒，在掘金技术社区看到不少大厂架构师分享，核心模块自研才是稳定性的根本保障。今天就把这套经过实战检验的代码拆给你看，不仅解决了兼容性问题，还顺手把年审逻辑给干了。
项目目标与核心痛点拆解
很多团队一上来就堆砌功能，结果代码烂成一锅粥。我们这个项目有明确的目标：构建一个可插拔的绩效考核引擎。它不关心你是用 Java 还是 Go，不关心数据库是 MySQL 还是 PostgreSQL，它只关心一件事：如何准确、稳定地计算一个人的绩效得分。
传统的做法是调用 HR 系统的 API 获取数据，然后在前端或业务层做简单加减。这种做法的致命伤在于“耦合”。一旦 HR 系统重构，字段名改了，或者接口超时，你的考核系统就得跟着停摆。这次事故就是典型例子。
我们要实现的核心功能包括三点：解耦数据源：通过适配器模式屏蔽底层 API 变化，核心计算逻辑只依赖内部定义的 DTO 对象。
动态权重计算：支持 KPI、OKR 混合模式，权重可在前端配置，后端动态加载。
状态机管理：处理考核周期的生命周期，从草稿、评分中、已确认到归档，每一步都有严格的状态校验。为什么要强调手写实现？因为市面上的通用框架往往过于臃肿，引入了不必要的依赖。而我们的场景相对垂直，手写一个 200 行左右的计算核心，反而更可控，调试起来一目了然。
目录结构与模块化设计
为了保证代码的可维护性，我们采用了分层架构，但刻意去除了复杂的 Spring Bean 注入链，改用更直观的组合模式。以下是核心目录结构：
perf-core/
├── src/
│ ├── main/
│ │ ├── java/com/company/perf
│ │ │ ├── engine/ # 核心计算引擎
│ │ │ │ ├── ScoreCalculator.java
│ │ │ │ ├── StrategyContext.java
│ │ │ │ └── impl/
│ │ │ │ ├── KpiStrategy.java
│ │ │ │ └── OkrStrategy.java
│ │ │ ├── adapter/ # 外部系统适配器
│ │ │ │ ├── HrApiAdapter.java
│ │ │ │ └── dto/
│ │ │ │ ├── EmployeeRawData.java
│ │ │ │ └── PerformanceRecord.java
│ │ │ ├── service/ # 业务逻辑层
│ │ │ │ └── CycleService.java
│ │ │ └── config/ # 配置中心
│ │ │ └── WeightConfig.java
│ │ └── resources/
│ │ └── application.yml
└── pom.xml这个结构的关键在于 adapter 层。所有来自外部系统（如 HR 系统、考勤系统）的数据，必须先经过 HrApiAdapter 转换为内部统一的 EmployeeRawData 对象。这样，即使底层 API 的 JSON 结构变了，我们只需要修改 Adapter 里的解析逻辑，核心的 ScoreCalculator 完全不用动。这就是隔离变化的艺术。
engine 层是纯粹的计算逻辑，不依赖任何 Spring 注解，不依赖数据库连接。你可以把它理解为一个纯函数集合，输入数据，输出得分。这种设计让单元测试变得极其简单，不需要启动整个应用，也不需要 Mock 数据库。
核心代码实现与逐行解析
下面展示最核心的 ScoreCalculator 和 KpiStrategy 的实现。注意，这里没有使用复杂的反射或动态代理，都是实打实的 Java 代码，方便阅读和维护。
1. 定义内部数据模型
首先，我们需要一个与外部解耦的数据结构。
package com.company.perf.adapter.dto;import java.math.BigDecimal;
import java.util.List;/*** 内部统一员工数据模型* 无论外部 API 怎么变，这个类保持不变*/
public class EmployeeRawData {private String employeeId;private String departmentId;private BigDecimal baseSalary;private ListKpiItem kpiItems;// Getter Setter 省略
}/*** KPI 单项指标*/
public class KpiItem {private String metricCode;private BigDecimal actualValue;private BigDecimal targetValue;private BigDecimal weight;private String scoringRule; // linear, threshold, custom
}2. 核心计算引擎
这是整个系统的“心脏”。它采用策略模式，根据不同的考核类型调用不同的计算策略。
package com.company.perf.engine;import com.company.perf.adapter.dto.EmployeeRawData;
import com.company.perf.adapter.dto.PerformanceRecord;
import com.company.perf.engine.impl.KpiStrategy;
import com.company.perf.config.WeightConfig;import java.math.BigDecimal;
import java.math.RoundingMode;public class ScoreCalculator {private final KpiStrategy kpiStrategy;private final WeightConfig weightConfig;public ScoreCalculator(WeightConfig weightConfig) {this.weightConfig = weightConfig;// 这里可以注入更多策略，如 OcrStrategy, 360度评估策略等this.kpiStrategy = new KpiStrategy();}/*** 计算最终绩效得分* @param rawData 从 Adapter 层获取的原始数据* @return 最终得分对象*/public PerformanceRecord calculate(EmployeeRawData rawData) {if (rawData == null || rawData.getKpiItems() == null) {throw new IllegalArgumentException(Employee data or KPI items cannot be null);}BigDecimal totalScore = BigDecimal.ZERO;BigDecimal totalWeight = BigDecimal.ZERO;for (var item : rawData.getKpiItems()) {// 1. 获取单项得分BigDecimal itemScore = kpiStrategy.calculateSingle(item);// 2. 获取权重BigDecimal weight = weightConfig.getWeight(item.getMetricCode());if (weight == null) {// 如果配置中缺失权重，默认忽略该项或抛出异常，这里选择记录日志并跳过System.err.println(Warning: Weight not found for metric + item.getMetricCode());continue;}// 3. 加权累加BigDecimal weightedScore = itemScore.multiply(weight);totalScore = totalScore.add(weightedScore);totalWeight = totalWeight.add(weight);}// 4. 处理权重不为 100% 的情况，进行归一化if (totalWeight.compareTo(BigDecimal.ZERO) 0) {totalScore = totalScore.divide(totalWeight, 2, RoundingMode.HALF_UP);}return new PerformanceRecord(rawData.getEmployeeId(), totalScore);}
}代码解析：归一化处理：很多新手会忽略这一点。如果管理员配置的权重总和只有 90%，直接相加会导致最高分只有 90 分。通过 totalScore / totalWeight，我们确保了满分永远是 100 分（或配置的满分值）。
异常处理：在循环中，如果某个指标的权重缺失，我们选择 continue 并打印日志，而不是直接抛出异常导致整个批次计算失败。这是生产环境的重要容错机制。3. 策略实现：KPI 评分规则
不同的 KPI 指标有不同的打分规则。线性增长、阈值触发、还是自定义公式？这里以“线性”为例。
package com.company.perf.engine.impl;import com.company.perf.adapter.dto.KpiItem;
import java.math.BigDecimal;
import java.math.RoundingMode;public class KpiStrategy {/*** 计算单个 KPI 指标得分* 规则：(实际值 / 目标值) * 基础分 (100分)* 封顶 120 分，保底 0 分*/public BigDecimal calculateSingle(KpiItem item) {if (item.getTargetValue().compareTo(BigDecimal.ZERO) == 0) {// 目标值为 0 的情况，通常意味着该项不考核或满分，需业务确认return BigDecimal.valueOf(100);}BigDecimal ratio = item.getActualValue().divide(item.getTargetValue(), 4, RoundingMode.HALF_UP);BigDecimal score = ratio.multiply(BigDecimal.valueOf(100));// 封顶与保底if (score.compareTo(BigDecimal.valueOf(120)) 0) {score = BigDecimal.valueOf(120);} else if (score.compareTo(BigDecimal.ZERO) 0) {score = BigDecimal.ZERO;}return score.setScale(2, RoundingMode.HALF_UP);}
}这段代码虽然短，但处理了除零异常和边界情况。在掘金技术社区的很多讨论中，浮点数精度和除零问题是后端开发的常见坑。使用 BigDecimal 而不是 double 是财务和绩效考核类的硬性要求。
运行与测试：如何验证稳定性
写完代码只是第一步，验证它是否真的能抵御“API 变化”才是关键。
1. 模拟 API 变更
我们在 HrApiAdapter 中模拟了一次接口变更。假设原来的 JSON 字段是 emp_id，现在改成了 employee_uid。
// HrApiAdapter.java 片段
public EmployeeRawData fetchEmployee(String id) {// 模拟网络请求...String json = httpClient.get(/api/v2/employee/ + id);// 关键：在这里解析 JSON// 如果 API 变了，只改这里的 Jackson 反序列化配置或手动解析JsonNode node = objectMapper.readTree(json);EmployeeRawData data = new EmployeeRawData();// 兼容旧版和新版字段if (node.has(employee_uid)) {data.setEmployeeId(node.get(employee_uid).asText());} else if (node.has(emp_id)) {data.setEmployeeId(node.get(emp_id).asText());} else {throw new DataFetchException(Unknown employee ID format);}// ... 其他字段解析return data;
}测试验证：
运行单元测试 ScoreCalculatorTest。输入一组固定的 EmployeeRawData 对象（注意，这里不依赖 Adapter，直接构造内部对象），断言输出得分是否预期。
结果：测试全部通过。这说明核心计算逻辑与外部数据源完全解耦。即使 Adapter 层因为 API 变更而重写，只要它输出的 EmployeeRawData 结构不变，计算引擎就稳如泰山。
2. 集成测试
使用 WireMock 模拟 HR 系统的 HTTP 响应。分别模拟 v1 和 v2 版本的 API 响应。Case 1: Mock 返回 v1 格式 JSON - 断言 Adapter 正确解析 - 断言 Calculator 得分正确。
Case 2: Mock 返回 v2 格式 JSON - 断言 Adapter 正确解析 - 断言 Calculator 得分正确。
Case 3: Mock 返回 500 错误 - 断言系统捕获异常，并进入重试或降级逻辑，而不是崩溃。优化扩展：应对复杂场景
基础版跑通了，但在实际项目中，还会遇到一些“怪”需求。
1. 证书有效期与年审逻辑
绩效考核不仅仅是打分，还涉及到员工资质。比如，某岗位要求持有“PMP 证书”，如果证书过期，绩效系数打 0.8 折。
我们在 WeightConfig 中增加了一个 BonusPenalty 配置项：
public class BonusPenalty {private String metricCode;private String rule; // CERT_VALIDprivate BigDecimal coefficient; // 0.8
}在 ScoreCalculator 的最后一步，遍历这些配置，检查员工档案中的证书状态。如果证书过期，将最终得分乘以 coefficient。
注意： 证书状态不要实时查询外部系统。应该在每天凌晨的定时任务中，批量拉取所有员工的证书状态，缓存到 Redis 或本地数据库。考核计算时，直接读缓存。这能极大降低系统延迟和外部依赖风险。
2. 考试科目与题型映射
有些技术岗位的绩效包含“内部认证考试”。不同题型（单选、多选、代码题）的权重不同。
我们在 KpiItem 中增加了一个 subItems 列表。如果 metricCode 是 INTERNAL_EXAM，则 actualValue 不再是单一数值，而是各子题得分的加权平均。
// 伪代码
if (item.getMetricCode().equals(INTERNAL_EXAM)) {BigDecimal examScore = calculateExamScore(item.getSubItems());// examScore 替换 item.getActualValue()
}这种嵌套结构让系统能够处理极其复杂的评分细则，而不需要为每种题型写一个独立的策略类。
3. 晋升与职业发展路径关联
绩效考核的结果往往与晋升挂钩。我们在 PerformanceRecord 中增加了一个 promotionEligibility 字段。
逻辑很简单：连续两个季度绩效 90 分 - Eligible
任意一个季度绩效 60 分 - Ineligible这个字段不直接由计算引擎算出，而是由 CycleService 在考核周期结束时，查询历史数据后填充。这保持了计算引擎的纯粹性，业务规则放在服务层。
小结与互动
这套手写实现的绩效考核系统，代码量不到 1000 行，但解决了最核心的稳定性问题。它证明了：在关键业务路径上，减少对外部黑盒 API 的依赖，通过 Adapter 模式进行隔离，是抵御技术债务的有效手段。
当然，这只是一个基础框架。实际落地时，你还需要考虑权限控制、数据审计、高并发下的缓存一致性等问题。但核心思想是相通的：核心逻辑自研，外部依赖隔离，数据结构统一。
在掘金技术社区的交流中，我发现很多团队还在为“HR 系统又改了接口”而加班修 Bug。其实，只要架构设计得当，这些外部变化应该是“无痛”的。
你公司项目里是怎么处理这种外部系统 API 变更的？是硬编码适配，还是做了中间层？欢迎在评论区分享你的踩坑经验，或者展示你的架构设计，咱们一起交流。 手写绩效考核系统避坑指南：解决版本升级API失效痛点
手写绩效考核系统避坑指南：解决版本升级API失效痛点
上次发版，生产环境直接炸了。HR总监冲进办公室，指着屏幕上的 500 错误骂了十分钟。原因很简单：底层权限库升了个大版本，getUserRoles 接口参数变了，导致整个绩效考核系统的评分逻辑全挂了。
那一刻我深刻意识到，核心业务逻辑绝不能完全依赖第三方黑盒 API。为了彻底解决版本升级后 API 全变了这个噩梦，我决定手写实现一套轻量级的考核引擎。别觉得手写是偷懒，在掘金技术社区看到不少大厂架构师分享，核心模块自研才是稳定性的根本保障。今天就把这套经过实战检验的代码拆给你看，不仅解决了兼容性问题，还顺手把年审逻辑给干了。
项目目标与核心痛点拆解
很多团队一上来就堆砌功能，结果代码烂成一锅粥。我们这个项目有明确的目标：构建一个可插拔的绩效考核引擎。它不关心你是用 Java 还是 Go，不关心数据库是 MySQL 还是 PostgreSQL，它只关心一件事：如何准确、稳定地计算一个人的绩效得分。
传统的做法是调用 HR 系统的 API 获取数据，然后在前端或业务层做简单加减。这种做法的致命伤在于“耦合”。一旦 HR 系统重构，字段名改了，或者接口超时，你的考核系统就得跟着停摆。这次事故就是典型例子。
我们要实现的核心功能包括三点：解耦数据源：通过适配器模式屏蔽底层 API 变化，核心计算逻辑只依赖内部定义的 DTO 对象。
动态权重计算：支持 KPI、OKR 混合模式，权重可在前端配置，后端动态加载。
状态机管理：处理考核周期的生命周期，从草稿、评分中、已确认到归档，每一步都有严格的状态校验。为什么要强调手写实现？因为市面上的通用框架往往过于臃肿，引入了不必要的依赖。而我们的场景相对垂直，手写一个 200 行左右的计算核心，反而更可控，调试起来一目了然。
目录结构与模块化设计
为了保证代码的可维护性，我们采用了分层架构，但刻意去除了复杂的 Spring Bean 注入链，改用更直观的组合模式。以下是核心目录结构：
perf-core/
├── src/
│ ├── main/
│ │ ├── java/com/company/perf
│ │ │ ├── engine/ # 核心计算引擎
│ │ │ │ ├── ScoreCalculator.java
│ │ │ │ ├── StrategyContext.java
│ │ │ │ └── impl/
│ │ │ │ ├── KpiStrategy.java
│ │ │ │ └── OkrStrategy.java
│ │ │ ├── adapter/ # 外部系统适配器
│ │ │ │ ├── HrApiAdapter.java
│ │ │ │ └── dto/
│ │ │ │ ├── EmployeeRawData.java
│ │ │ │ └── PerformanceRecord.java
│ │ │ ├── service/ # 业务逻辑层
│ │ │ │ └── CycleService.java
│ │ │ └── config/ # 配置中心
│ │ │ └── WeightConfig.java
│ │ └── resources/
│ │ └── application.yml
└── pom.xml这个结构的关键在于 adapter 层。所有来自外部系统（如 HR 系统、考勤系统）的数据，必须先经过 HrApiAdapter 转换为内部统一的 EmployeeRawData 对象。这样，即使底层 API 的 JSON 结构变了，我们只需要修改 Adapter 里的解析逻辑，核心的 ScoreCalculator 完全不用动。这就是隔离变化的艺术。
engine 层是纯粹的计算逻辑，不依赖任何 Spring 注解，不依赖数据库连接。你可以把它理解为一个纯函数集合，输入数据，输出得分。这种设计让单元测试变得极其简单，不需要启动整个应用，也不需要 Mock 数据库。
核心代码实现与逐行解析
下面展示最核心的 ScoreCalculator 和 KpiStrategy 的实现。注意，这里没有使用复杂的反射或动态代理，都是实打实的 Java 代码，方便阅读和维护。
1. 定义内部数据模型
首先，我们需要一个与外部解耦的数据结构。
package com.company.perf.adapter.dto;import java.math.BigDecimal;
import java.util.List;/*** 内部统一员工数据模型* 无论外部 API 怎么变，这个类保持不变*/
public class EmployeeRawData {private String employeeId;private String departmentId;private BigDecimal baseSalary;private ListKpiItem kpiItems;// Getter Setter 省略
}/*** KPI 单项指标*/
public class KpiItem {private String metricCode;private BigDecimal actualValue;private BigDecimal targetValue;private BigDecimal weight;private String scoringRule; // linear, threshold, custom
}2. 核心计算引擎
这是整个系统的“心脏”。它采用策略模式，根据不同的考核类型调用不同的计算策略。
package com.company.perf.engine;import com.company.perf.adapter.dto.EmployeeRawData;
import com.company.perf.adapter.dto.PerformanceRecord;
import com.company.perf.engine.impl.KpiStrategy;
import com.company.perf.config.WeightConfig;import java.math.BigDecimal;
import java.math.RoundingMode;public class ScoreCalculator {private final KpiStrategy kpiStrategy;private final WeightConfig weightConfig;public ScoreCalculator(WeightConfig weightConfig) {this.weightConfig = weightConfig;// 这里可以注入更多策略，如 OcrStrategy, 360度评估策略等this.kpiStrategy = new KpiStrategy();}/*** 计算最终绩效得分* @param rawData 从 Adapter 层获取的原始数据* @return 最终得分对象*/public PerformanceRecord calculate(EmployeeRawData rawData) {if (rawData == null || rawData.getKpiItems() == null) {throw new IllegalArgumentException(Employee data or KPI items cannot be null);}BigDecimal totalScore = BigDecimal.ZERO;BigDecimal totalWeight = BigDecimal.ZERO;for (var item : rawData.getKpiItems()) {// 1. 获取单项得分BigDecimal itemScore = kpiStrategy.calculateSingle(item);// 2. 获取权重BigDecimal weight = weightConfig.getWeight(item.getMetricCode());if (weight == null) {// 如果配置中缺失权重，默认忽略该项或抛出异常，这里选择记录日志并跳过System.err.println(Warning: Weight not found for metric + item.getMetricCode());continue;}// 3. 加权累加BigDecimal weightedScore = itemScore.multiply(weight);totalScore = totalScore.add(weightedScore);totalWeight = totalWeight.add(weight);}// 4. 处理权重不为 100% 的情况，进行归一化if (totalWeight.compareTo(BigDecimal.ZERO) 0) {totalScore = totalScore.divide(totalWeight, 2, RoundingMode.HALF_UP);}return new PerformanceRecord(rawData.getEmployeeId(), totalScore);}
}代码解析：归一化处理：很多新手会忽略这一点。如果管理员配置的权重总和只有 90%，直接相加会导致最高分只有 90 分。通过 totalScore / totalWeight，我们确保了满分永远是 100 分（或配置的满分值）。
异常处理：在循环中，如果某个指标的权重缺失，我们选择 continue 并打印日志，而不是直接抛出异常导致整个批次计算失败。这是生产环境的重要容错机制。3. 策略实现：KPI 评分规则
不同的 KPI 指标有不同的打分规则。线性增长、阈值触发、还是自定义公式？这里以“线性”为例。
package com.company.perf.engine.impl;import com.company.perf.adapter.dto.KpiItem;
import java.math.BigDecimal;
import java.math.RoundingMode;public class KpiStrategy {/*** 计算单个 KPI 指标得分* 规则：(实际值 / 目标值) * 基础分 (100分)* 封顶 120 分，保底 0 分*/public BigDecimal calculateSingle(KpiItem item) {if (item.getTargetValue().compareTo(BigDecimal.ZERO) == 0) {// 目标值为 0 的情况，通常意味着该项不考核或满分，需业务确认return BigDecimal.valueOf(100);}BigDecimal ratio = item.getActualValue().divide(item.getTargetValue(), 4, RoundingMode.HALF_UP);BigDecimal score = ratio.multiply(BigDecimal.valueOf(100));// 封顶与保底if (score.compareTo(BigDecimal.valueOf(120)) 0) {score = BigDecimal.valueOf(120);} else if (score.compareTo(BigDecimal.ZERO) 0) {score = BigDecimal.ZERO;}return score.setScale(2, RoundingMode.HALF_UP);}
}这段代码虽然短，但处理了除零异常和边界情况。在掘金技术社区的很多讨论中，浮点数精度和除零问题是后端开发的常见坑。使用 BigDecimal 而不是 double 是财务和绩效考核类的硬性要求。
运行与测试：如何验证稳定性
写完代码只是第一步，验证它是否真的能抵御“API 变化”才是关键。
1. 模拟 API 变更
我们在 HrApiAdapter 中模拟了一次接口变更。假设原来的 JSON 字段是 emp_id，现在改成了 employee_uid。
// HrApiAdapter.java 片段
public EmployeeRawData fetchEmployee(String id) {// 模拟网络请求...String json = httpClient.get(/api/v2/employee/ + id);// 关键：在这里解析 JSON// 如果 API 变了，只改这里的 Jackson 反序列化配置或手动解析JsonNode node = objectMapper.readTree(json);EmployeeRawData data = new EmployeeRawData();// 兼容旧版和新版字段if (node.has(employee_uid)) {data.setEmployeeId(node.get(employee_uid).asText());} else if (node.has(emp_id)) {data.setEmployeeId(node.get(emp_id).asText());} else {throw new DataFetchException(Unknown employee ID format);}// ... 其他字段解析return data;
}测试验证：
运行单元测试 ScoreCalculatorTest。输入一组固定的 EmployeeRawData 对象（注意，这里不依赖 Adapter，直接构造内部对象），断言输出得分是否预期。
结果：测试全部通过。这说明核心计算逻辑与外部数据源完全解耦。即使 Adapter 层因为 API 变更而重写，只要它输出的 EmployeeRawData 结构不变，计算引擎就稳如泰山。
2. 集成测试
使用 WireMock 模拟 HR 系统的 HTTP 响应。分别模拟 v1 和 v2 版本的 API 响应。Case 1: Mock 返回 v1 格式 JSON - 断言 Adapter 正确解析 - 断言 Calculator 得分正确。
Case 2: Mock 返回 v2 格式 JSON - 断言 Adapter 正确解析 - 断言 Calculator 得分正确。
Case 3: Mock 返回 500 错误 - 断言系统捕获异常，并进入重试或降级逻辑，而不是崩溃。优化扩展：应对复杂场景
基础版跑通了，但在实际项目中，还会遇到一些“怪”需求。
1. 证书有效期与年审逻辑
绩效考核不仅仅是打分，还涉及到员工资质。比如，某岗位要求持有“PMP 证书”，如果证书过期，绩效系数打 0.8 折。
我们在 WeightConfig 中增加了一个 BonusPenalty 配置项：
public class BonusPenalty {private String metricCode;private String rule; // CERT_VALIDprivate BigDecimal coefficient; // 0.8
}在 ScoreCalculator 的最后一步，遍历这些配置，检查员工档案中的证书状态。如果证书过期，将最终得分乘以 coefficient。
注意： 证书状态不要实时查询外部系统。应该在每天凌晨的定时任务中，批量拉取所有员工的证书状态，缓存到 Redis 或本地数据库。考核计算时，直接读缓存。这能极大降低系统延迟和外部依赖风险。
2. 考试科目与题型映射
有些技术岗位的绩效包含“内部认证考试”。不同题型（单选、多选、代码题）的权重不同。
我们在 KpiItem 中增加了一个 subItems 列表。如果 metricCode 是 INTERNAL_EXAM，则 actualValue 不再是单一数值，而是各子题得分的加权平均。
// 伪代码
if (item.getMetricCode().equals(INTERNAL_EXAM)) {BigDecimal examScore = calculateExamScore(item.getSubItems());// examScore 替换 item.getActualValue()
}这种嵌套结构让系统能够处理极其复杂的评分细则，而不需要为每种题型写一个独立的策略类。
3. 晋升与职业发展路径关联
绩效考核的结果往往与晋升挂钩。我们在 PerformanceRecord 中增加了一个 promotionEligibility 字段。
逻辑很简单：连续两个季度绩效 90 分 - Eligible
任意一个季度绩效 60 分 - Ineligible这个字段不直接由计算引擎算出，而是由 CycleService 在考核周期结束时，查询历史数据后填充。这保持了计算引擎的纯粹性，业务规则放在服务层。
小结与互动
这套手写实现的绩效考核系统，代码量不到 1000 行，但解决了最核心的稳定性问题。它证明了：在关键业务路径上，减少对外部黑盒 API 的依赖，通过 Adapter 模式进行隔离，是抵御技术债务的有效手段。
当然，这只是一个基础框架。实际落地时，你还需要考虑权限控制、数据审计、高并发下的缓存一致性等问题。但核心思想是相通的：核心逻辑自研，外部依赖隔离，数据结构统一。
在掘金技术社区的交流中，我发现很多团队还在为“HR 系统又改了接口”而加班修 Bug。其实，只要架构设计得当，这些外部变化应该是“无痛”的。
你公司项目里是怎么处理这种外部系统 API 变更的？是硬编码适配，还是做了中间层？欢迎在评论区分享你的踩坑经验，或者展示你的架构设计，咱们一起交流。