2026.09.03-小厂Agent面经与复盘

开发过程中遇到的比较难的问题以及定位解决流程

这里答了局域网传输工具中停止接收服务异常的问题，整理一下表述：

用户在前端点击停止按钮之后，按钮进入停止状态，但是一直无法恢复，前端看起来仍然像是服务没有停止

然后我开始逐层排查，首先通过前端请求和状态管理确认，停止请求已经正常发出，React也正确地进入了stopping状态

随后检查FastAPI的路由层，确认了请求已经通过asyncio.to_thread()调用了后端的ReceiveManager.stop()，并没有阻塞事件循环

接着继续检查从Python到C++核心逻辑之间的pybind层，gateway本身无异常

最后我在C++的ReceiveServerService::stop()定位到了问题，这个方法在收到停止请求之后，会调用std::jthread::request_stop()，并立即返回当前状态，但是接收线程真正退出，释放TCP Server并更新状态还需要一段时间，所以暂时返回的是stopping

原来的后端逻辑直接把这个返回结果发送给前端，但之后没有设计新的状态事件通知前端，导致前端持续停留在中止状态

所以我在ReceiverManager中轮询native的权威状态，知道状态变为stopped或者failed，到达终态之后，才发布事件返回前端

---

代码是自己写的还是AI写的

复盘感觉应该自信一点，整理表述：

大部分基础和模板化代码，通过AI生成，提高开发效率，但是在核心架构、业务逻辑以及复杂算法上，AI只是我的辅助工具，我会设计好架构并提供上下文，让AI生成初稿，然后由我进行代码审查、重构和性能调优

---

怎么验证AI代码的正确性

首先，核心逻辑由我设计测试规范，自主定义业务边界、极端情况和断言逻辑，再让AI根据我的Spec去补全单元测试

其次，使用静态检查和自动化CI/CD兜底，引入静态代码分析工具，像是Pylint、ESLint进行类型和语法的强制约束，结合自动化测试流水线，测试不通过就拒绝对接，强制AI根据错误日志进行自我纠错

最后，进行人眼审查和沙箱验证，对于涉及到并发、接口鉴权、数据库事务等核心逻辑，我一定会进行逐行的人工CR，并在隔离的本地环境跑真实的数据流测试

---

有没有了解过PDD这些测试方法

PDD即为Pattern-Driven Development，模式驱动开发，核心思想就是不要重复发明轮子，用成熟的模式来指导测试设计和代码编写

在做测试的时候，通常应用的是如下几种经典模式：

• AAA模式：即Arrange-Act-Assert，准备，执行，断言，是单元测试的标准骨架
• Page Object Pattern：将App或者Web的每个页面封装成一个类，UI元素和操作逻辑分离，适用于UI自动化测试
• Data-Driven Pattern：将测试逻辑和测试数据解耦，通过读取数据源跑多组数据，适用于接口自动化测试
• Mock Pattern：使用伪造对象来代替未完成或者不稳定的外部依赖完成测试

---

对像DDD这种设计方法论的了解

DDD曾经在之前的文章中记录过，但是显然现在忘得差不多了，回顾一下

简要来描述就是用代码来直接映射现实业务，主要分为战略设计和战术设计两大部分

战略设计解决的是如何拆分实际需求的问题，大致分为以下部分：

• 通用语言：首先设计出一套通用的语义清晰的语言，业务和技术用同一套名词
• 领域和子域：将整个业务逻辑拆分为核心域、支撑域、通用域，分别涵盖公司的核心竞争力、支撑核心业务所需的能力、以及到处都有的通用能力
• 限界上下文：就是模型的语境边界，例如对于商品，在物流中就代表重量、体积、包裹，在仓储中就代表大小长宽高、SKU以及货架号，合理划分边界，才能作为微服务拆分的前提
• 防腐层：调用老旧的第三方接口或者系统时，不要让它们污染了你的领域模型，做一层防腐层进行适配转换

随后是战术设计，解决类和对象如何落到代码中的问题

大致就是实体、值对象、聚合根、领域服务、领域事件、仓储这几个概念，代码架构呈现洋葱架构，遵循倒置原则，核心业务在最里层，基础设施在最外层