一名实习生的复盘：技术与规划的经验教训

Asthenia04122025-04-05 14:06

一名实习生的复盘：技术与规划的经验教训

这篇文章是对一名实习生在开发工作中经验教训的复盘总结（不是我本人的复盘，而是基于他/她的记录整理）。通过分析他在实习期间遇到的问题，结合代码示例，我尝试详细梳理技术细节和项目管理的经验，希望对其他开发者有所启发。

1. 年前开发年后CR，没提前看不熟悉

这位实习生在年前赶工开发功能，年后进行代码审查（CR）时，发现自己对代码逻辑已经模糊。原因是没有提前复习，导致CR时效率低下，甚至被指出一些低级错误。

教训

  • 提前回顾：CR前至少提前一天重温代码，梳理关键逻辑。
  • 文档支持：提交代码时附上简要说明，代码中写好注释。

示例

他之前写的代码：

java 复制代码 
public String processData(List<String> input) {
    String result = "";
    for (String s : input) {
        result += s.split(",")[0];
    }
    return result;
}

改进后：

java 复制代码 
/**
 * 处理输入列表，提取每个字符串逗号前的部分并拼接
 * @param input 输入列表，格式如 "abc,def"
 * @return 拼接结果，如 "abc"
 */
public String processData(List<String> input) {
    StringBuilder result = new StringBuilder();
    for (String s : input) {
        result.append(s.split(",")[0]);
    }
    return result.toString();
}

改进后不仅逻辑清晰，还避免了字符串拼接的性能问题。

2. 如果不是主流程，try/catch不应该阻塞

这位实习生习惯对所有代码块都用try/catch包裹，但后来发现，如果是非主流程的逻辑（如日志记录或次要功能），过度捕获异常可能会掩盖问题，甚至阻塞主流程的执行。

教训

  • 明确主次：主流程要保证执行，非主流程的异常可以记录后继续运行。
  • 精准捕获 ：只处理特定异常，避免用Exception捕获所有问题。

详细解释

比如他在某个服务中既处理核心业务，又记录操作日志，结果日志失败导致整个服务中断。正确的做法是分开处理，让主流程独立运行。

示例

之前代码：

java 复制代码 
public void processOrder(Order order) {
    try {
        saveOrder(order); // 主流程：保存订单
        logOperation(order); // 非主流程：记录日志
    } catch (Exception e) {
        log.error("Processing failed", e);
        throw new RuntimeException("Order processing failed");
    }
}

改进后：

java 复制代码 
public void processOrder(Order order) {
    saveOrder(order); // 主流程直接执行
    try {
        logOperation(order); // 非主流程单独捕获
    } catch (Exception e) {
        log.warn("Failed to log operation, continuing", e); // 记录警告但不中断
    }
}

private void saveOrder(Order order) { /* 保存订单 */ }
private void logOperation(Order order) { /* 记录日志 */ }

这样即使日志记录失败，订单保存也不会受影响。

3. join别用，干大数据联表习惯了回来被提醒

这位实习生之前参与过大数据项目，习惯用SQL的JOIN操作处理表关联。回到业务开发后，他不自觉地在Java代码中用String.join拼接字符串，结果被提醒这不是SQL场景，性能和适用性都不佳。

教训

  • 区分场景 ：SQL的JOIN适合数据库操作，Java中字符串拼接用StringBuilder更高效。
  • 调整思维：从大数据切换到业务开发时，要适应不同技术栈的习惯。

示例

他之前写的代码：

java 复制代码 
public String combineNames(List<String> names) {
    return String.join(",", names); // 模仿SQL JOIN的思维
}

改进后：

java 复制代码 
public String combineNames(List<String> names) {
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < names.size(); i++) {
        sb.append(names.get(i));
        if (i < names.size() - 1) sb.append(",");
    }
    return sb.toString();
}

StringBuilder在小数据量下更高效，且逻辑更直观，与SQL的JOIN完全是不同场景。

4. 传参还是要VO/DTO

他在开发网关调用时没理解规范，跟着老代码用Map做返回值，结果被指出不规范。应该用VO（View Object）或DTO（Data Transfer Object）定义明确的接口。

教训

  • 结构化数据 ：用VO/DTO替代Map，提高代码可读性和维护性。
  • 理解而非模仿：不要盲目抄老代码，要弄清设计意图。

示例

之前代码：

java 复制代码 
public Map<String, Object> getUserInfo(String userId) {
    Map<String, Object> result = new HashMap<>();
    result.put("id", userId);
    result.put("name", "John");
    return result;
}

改进后：

java 复制代码 
public class UserVO {
    private String id;
    private String name;
    // Getters and Setters
}

public UserVO getUserInfo(String userId) {
    UserVO vo = new UserVO();
    vo.setId(userId);
    vo.setName("John");
    return vo;
}

VO让接口字段一目了然，后续扩展也更方便。

5. 多考虑能不能用Lion配置

公司使用Lion配置中心管理参数，但他经常硬编码配置项，后来发现很多值可以用Lion动态调整。

教训

  • 动态管理：优先用配置中心替代硬编码。
  • 灵活性：减少代码修改，提高环境适应性。

示例

之前代码：

java 复制代码 
private static final String API_URL = "http://localhost:8080/api";

改进后：

java 复制代码 
@Value("${api.url}")
private String apiUrl; // 从Lion读取

通过Spring注解动态获取配置，环境切换更顺畅。

6. 不同环境配置要注意

他在开发中引用了SET（某种工具集）和中心服务的依赖，但没注意开发、测试、生产环境的配置差异，导致上线时依赖版本冲突或配置不生效。

教训

  • 环境隔离：不同环境的依赖版本和配置要明确区分。
  • 提前验证：上线前检查依赖和配置的兼容性。

详细解释

比如他在开发时用的是SET的本地版本，但生产环境依赖中心服务的远程版本，结果上线后报错。他后来意识到，应该在POM文件中通过属性控制版本，并在配置文件中区分环境。

示例

之前配置：

xml 复制代码 
<dependency>
    <groupId>com.example</groupId>
    <artifactId>center-service</artifactId>
    <version>1.0.0</version>
</dependency>

改进后：

xml 复制代码 
<properties>
    <center.service.version>1.0.0</center.service.version> <!-- 开发环境 -->
</properties>

<dependency>
    <groupId>com.example</groupId>
    <artifactId>center-service</artifactId>
    <version>${center.service.version}</version>
</dependency>

同时在配置文件中区分环境：

yaml 复制代码 
# dev.yml
center:
  service:
    version: 1.0.0

# prod.yml
center:
  service:
    version: 2.0.0

通过Maven属性和配置文件动态管理，避免硬编码带来的问题。

7. ST/QA/Prod要注意相关域名和参数

他在ST（系统测试）、QA（质量保证）和Prod（生产）环境切换时，没仔细检查域名和参数，导致生产环境部分功能不可用。

教训

  • 逐一核对：上线前检查每个环境的域名和参数。
  • 自动化工具：用脚本验证配置一致性。

示例

之前代码：

java 复制代码 
private static final String DOMAIN = "qa.example.com";

改进后：

java 复制代码 
@Value("${app.domain}")
private String domain; // 从配置中心读取

配置文件：

yaml 复制代码 
# qa.yml
app:
  domain: qa.example.com

# prod.yml
app:
  domain: prod.example.com

通过配置中心管理域名，确保环境切换无误。

8. 时间上要早规划

他计划离职前三周备机上线，但因各种杂事拖延，最后三周都没和前端在备机验证，导致上线仓促。

教训

  • 预留缓冲：重要节点要提前规划时间。
  • 主动推进：尽早和相关方确认进度。

示例时间表

diff 复制代码 
- T-3周：完成开发，提交CR
- T-2周：备机部署，与前端联调
- T-1周：修复问题，上线验证

9. 做决定记得艾特主R

他和前端约好备机联调，但主R（负责人）后来觉得不合适，临时改到QA联调，导致进度混乱。

教训

  • 提前确认：关键决定要@主R确认。
  • 沟通留档：用IM或邮件记录，避免误解。

示例沟通

python 复制代码 
@主R：计划下周二在备机上与前端联调，涉及功能X，请确认是否可行？

总结

这位实习生的经历反映了从技术细节到项目管理的成长过程。代码上，他学会了规范和优化；规划上，他明白了提前准备和沟通的重要性。这些经验教训对任何开发者来说都值得借鉴。

相关推荐
代码与野兽3 分钟前
AI交易，怎么让LLM自己挑选数据源？
前端·javascript·后端
天天摸鱼的java工程师20 分钟前
JDK 25 到底更新了什么？这篇全景式解读带你全面掌握
java·后端
非鱼feiyu25 分钟前
自关联数据表查询优化实践：以 Django + 递归 CTE 构建树结构为例
数据库·后端·django
零日失眠者30 分钟前
这5个Python库一旦掌握就离不开
后端·python
幌才_loong34 分钟前
.NET8 × Redis 实战宝典：从配置到落地，搞定高并发缓存就这篇！
后端·.net
用户83562907805137 分钟前
如何使用 Python 从 Word 文档中批量提取表格数据
后端·python
l***37091 小时前
spring 跨域CORS Filter
java·后端·spring
aiopencode1 小时前
APP 公钥与 MD5 信息在工程中的价值 一次签名排查过程带来的经验总结
后端
ServBay2 小时前
Django 6.0 发布，新增原生任务队列与 CSP 支持
后端·python·django
用户2190326527352 小时前
Spring Boot 4.0 整合 RabbitMQ 注解方式使用指南
后端
热门推荐
01GitHub 镜像站点02React CVE-2025-55182漏洞排查与修复指南03【超详细教程】手把手教你从微软官网免费下载Windows 10官方原版ISO镜像（2025最新版）04UV安装并设置国内源05安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）06BongoCat - 跨平台键盘猫动画工具07本地部署阿里最新开源的Z-Image08Linux下V2Ray安装配置指南09在VSCode配置Java开发环境的保姆级教程（适配各类AI编程IDE）10智能库存管理的需求预测模型：从业务痛点到落地代码的完整实践