Go 和 Java 面试的架构任务

架构面试挑战：检验开发者的系统设计思维

本任务旨在评估候选人对SOLID原则、单一职责原则（SRP）及系统灵活性的理解。题目要求扩展一个已有的员工薪资计算结构（或类），使其支持生成PDF报告的同时，还能适配管理层角色。关键约束条件包括：与基础薪资挂钩的KPI和奖金比例保持一致，但管理层的基础薪资更高。系统需具备未来变更的低侵入性支持能力。

对于Go语言，这意味着创建一个结构体；对于面向对象语言，则需定义一个类。表面看似简单，实则考察候选人识别设计缺陷与构建可扩展架构的能力。

常见错误与AI驱动的解决方案

多数候选人在初始阶段忽略了SRP违反问题：原始结构将薪资计算与报告生成混杂在一起。正确做法是明确职责分离。

AI推荐方案采用组合与接口设计：

• 定义一个基础 Employee 结构体，包含共享字段（费率、KPI百分比、奖金百分比）及方法（CalculateBase、CalculateKPI、CalculateBonus）。
• 声明 SalaryCalculator 接口，包含 CalculateSalary() *Report 方法。
• Manager 组合 Employee 并通过乘数提升基础薪资。
• 专门的 ReportGenerator 可接收任意 SalaryCalculator 实例。
• 使用 NewEmployee 和 NewManager 构造函数完成初始化。

潜在问题：单一报告生成器难以应对未来差异（如直属下属人数、不同KPI考核周期）。这迫使使用条件判断或重构代码，违背开闭原则（OCP）。

题目中的隐藏陷阱

题目刻意设置多个认知误区：

• SRP违规："一个类同时负责薪资计算和报告生成"——候选人应提出拆分建议。
• 过度泛化："KPI与奖金比例相同"——不同岗位的计算公式可能独立演进。
• 角色简化："仅基础薪资不同"——管理层是独立业务实体，拥有独特的KPI指标与责任范围。

优秀候选人会主动提问：公式如何变化？报告需要哪些数据？是否计划新增角色？

候选人评估标准

评分重点在于思维方式，而非代码实现：

• 提问质量：澄清需求，揭示隐含假设。
• 论证逻辑：解释设计选择依据（SOLID原则、组合优于继承）。
• 可扩展性：考虑系统未来演进（新增角色、报告格式）。
• 优劣分析：对自身方案进行自我批判。
• 可测试性：组件设计支持独立单元测试。

推荐架构方案

一种可行的解决方案（Go风格，可适配类语言）：

• 接口定义：

- SalaryCalculator：提供基础薪资、KPI、奖金、总薪资的计算方法。

- ReportDataProvider：为报告提供数据（薪资及其他字段）。

- ReportTemplate：Generate(ReportDataProvider) PDF。

• 具体实现：

- EmployeeSalary 和 ManagerSalary 实现 SalaryCalculator 接口。

- EmployeeReport 和 ManagerReport 实现 ReportTemplate 接口，各自持有对应 SalaryCalculator 的引用。

• 工厂模式：NewReport(templateType string, calc SalaryCalculator) ReportTemplate。

优势：

• 新增角色（如 DirectorSalary + DirectorReport）极为简便。
• 报告生成器无需条件分支逻辑。
• 组合机制实现跨组件复用，提升系统韧性。

核心启示

• 严格遵守SRP：计算与报告属于不同关注点。
• 符合开闭原则：新增角色无需修改已有代码。
• 优先组合而非继承：保障系统长期适应性。
• 工厂模式封装创建逻辑：隐藏复杂实例化过程。
• 候选人的提问能力：反映其深度思考与系统化分析水平。

— Editorial Team