Java 新人入职试用期生存指南从环境搭建到独立完成需求前言https://zystudy.cn/documents/8很多 Java 新人入职后都会遇到这些问题电脑环境不知道怎么配置项目拉下来却启动不了看不懂公司的项目结构接到需求后不知道从哪里开始出现 Bug 只会到处搜索不敢问同事又怕耽误进度代码写完了却不知道怎么测试和提交。其实试用期并不是要求你什么都会。公司更看重的是能不能听懂需求、完成任务、及时反馈并且尽量不给团队制造新的问题。本文按照实际工作的顺序整理一套 Java 新人可以直接执行的工作流程。一、入职后先调整心态刚进入一家新公司看不懂项目很正常。因为你缺少的不一定是 Java 技术而是以下信息公司业务是什么项目为什么这样设计每个模块负责什么数据库表之间是什么关系团队有哪些开发规范项目经历过哪些历史改动。这些内容不可能一天全部掌握。因此刚入职时不要追求“立刻看懂全部代码”而要先完成三个目标把开发环境配置好把项目成功运行起来跟着一个简单接口走完整个流程。试用期最危险的心态有两种1. 不懂也不问自己卡了一整天最后才告诉领导项目没启动起来。2. 什么都不查直接问报错信息都没看就把一句“这个为什么不行”发给同事。比较合适的方式是先自己排查一段时间整理清楚现象、日志和尝试过的方法再向同事请教。二、入职第一天需要收集哪些资料不要等遇到问题后再一个个询问。建议建立一份自己的《项目入职说明》记录以下内容。1. 开发环境JDK版本 Maven版本 Maven配置文件 Maven本地仓库 IDEA版本 Node.js版本 数据库类型 Redis地址 注册中心地址 配置中心地址 消息队列地址2. 项目资料Git仓库地址 开发分支 测试分支 项目启动顺序 接口文档地址 数据库文档地址 产品原型地址 日志平台地址 测试环境地址3. 团队规范分支怎么命名 提交信息怎么写 数据库脚本放在哪里 代码需要谁审核 测试环境由谁发布 上线需要经过哪些步骤这些内容最好写进自己的笔记不要完全依赖记忆。三、配置 Java 开发环境常见的 Java 后端开发环境包括JDKMavenIntelliJ IDEAGitMySQLRedisNavicatPostman 或 Apifox公司使用的中间件。第一步确认 JDK 版本不要看到自己电脑里有 JDK 就直接使用。不同项目可能使用JDK 8 JDK 11 JDK 17 JDK 21先查看项目中的pom.xmlpropertiesjava.version17/java.version/properties或者查看maven.compiler.source17/maven.compiler.sourcemaven.compiler.target17/maven.compiler.target检查本机版本java-version第二步配置 Maven检查 Mavenmvn-version重点确认settings.xml使用哪个文件公司有没有私服本地仓库保存在哪里是否需要配置用户名和密码。公司项目依赖下载失败不一定是代码问题也可能是 Maven 私服没有配置。第三步配置 Git先设置基本信息gitconfig--globaluser.name你的名字gitconfig--globaluser.email你的邮箱然后确认自己有仓库权限。拉取项目gitclone 仓库地址四、如何把本地项目运行起来项目启动失败时不要一看到红色日志就慌。按照下面的顺序检查。第一步看项目说明优先寻找README.md docs目录 部署文档 启动说明 项目Wiki第二步确认启动顺序微服务项目通常不能随便启动一个服务就使用。可能需要先启动注册中心 配置中心 网关服务 认证服务 业务服务例如Nacos ↓ Gateway ↓ Auth ↓ System ↓ Order第三步确认配置文件常见配置文件application.yml application-dev.yml bootstrap.yml bootstrap-dev.yml重点检查当前激活的是哪个环境数据库地址是否正确Redis 是否可访问配置中心是否连接成功端口是否被占用。例如spring:profiles:active:dev第四步观察启动日志常见错误可以先按类型分类。依赖下载失败Could not resolve dependencies通常检查 Maven 配置和私服。数据库连接失败Communications link failure通常检查数据库地址、端口、账号和网络。端口被占用Port 8080 was already in useWindows 可以执行netstat-ano|findstr8080Bean 创建失败BeanCreationException从最底部的Caused by开始看不要只看最上面一行。第五步验证项目是否真正可用服务启动成功不代表业务一定正常。还需要访问健康检查接口 Swagger或接口文档 登录接口 简单查询接口五、工作中常用工具怎么学新人不需要一开始就精通所有工具但至少要会基本操作。1. IDEA需要掌握全局搜索 查找类 查找方法 查看方法调用 打断点 单步调试 查看Git修改 解决简单冲突常见快捷操作Search Everywhere Find Usages Go to Definition Debug Evaluate Expression最重要的是Find Usages。修改一个公共方法前先查看它被哪些地方调用避免改完一个需求却影响了其他模块。2. Navicat需要掌握查看数据库和表查看表结构执行 SQL查看索引导入、导出数据修改测试数据开启事务后再执行危险操作。新人不要直接在生产数据库执行UPDATEDELETEDROPTRUNCATE即使是在测试库执行更新前也建议先写查询SELECT*FROMordersWHEREid1001;确认数据正确后再执行修改。3. Linux常用命令pwdlscdmkdircpmvrmcattailgreppstopdffree查看实时日志tail-fapplication.log搜索错误grepERRORapplication.log查看 Java 进程ps-ef|grepjava查看端口netstat-tunlp使用rm命令一定要谨慎尤其不要随便执行rm-rf六、如何快速熟悉公司项目不要从第一行代码开始把整个项目按顺序阅读。这种方式非常慢而且很容易看了后面忘了前面。正确方式是先看业务再顺着一个接口看代码。第一步了解项目模块例如gateway 网关 auth 登录和认证 system 用户、角色、权限 order 订单业务 payment 支付业务 inventory 库存业务 common 公共模块先弄清楚每个模块是干什么的。第二步了解核心业务可以向同事确认系统主要给谁使用最重要的业务流程是什么哪几个模块最核心自己将负责哪一部分。第三步选择一个简单接口例如根据订单ID查询订单详情按照调用链向下查看请求地址 ↓ Controller ↓ Service ↓ Mapper ↓ 数据库 ↓ 返回结果第四步画出简单流程用户请求订单详情 ↓ OrderController ↓ OrderService ↓ 查询订单主表 ↓ 查询订单商品表 ↓ 组装OrderVO ↓ 返回前端只要能把一个接口完整走通后面的接口就会越来越容易理解。七、如何梳理一个接口的业务逻辑看到一个接口时可以从七个问题开始。1. 接口地址是什么GetMapping(/orders/{id})2. 接收什么参数PathVariableLongid还要确认参数能不能为 null参数是数据库主键还是业务编号是否需要登录是否需要权限。3. 调用了哪个 ServiceorderService.getOrderDetail(id);4. Service 做了哪些判断例如订单是否存在 订单是否被删除 当前用户是否有权限 订单状态是否允许查询5. 查询了哪些表例如order order_item payment_record user6. 返回什么对象OrderDetailVO7. 异常怎么处理例如订单不存在 没有访问权限 数据库异常 第三方服务异常最后可以把接口整理成下面的格式接口名称查询订单详情 请求方式GET 请求参数订单ID 主要流程 1. 校验订单ID 2. 查询订单 3. 校验用户权限 4. 查询订单商品 5. 组装返回对象。 异常情况 1. 参数为空 2. 订单不存在 3. 用户无权限 4. 订单已删除。八、接到需求后应该怎么做很多新人收到需求后第一反应是立即写代码。这样很容易出现一个问题代码写完了但做的不是产品真正想要的功能。建议按照以下步骤处理需求。第一步确认需求背景先问清楚为什么要做这个功能谁会使用现在有什么问题最终希望达到什么效果。第二步确认输入和输出例如需求是根据项目ID查询设备列表需要继续确认项目ID是数据库主键还是第三方项目编号 是否需要分页 是否只查询正常设备 没有设备时返回空集合还是报错 是否需要权限校验第三步确认特殊情况需要考虑参数为空数据不存在数据已删除用户没有权限重复请求第三方服务失败数据量太大。第四步用自己的话复述需求可以这样表达我确认一下接口接收系统内部的项目 ID只查询正常状态的设备需要分页项目不存在时返回提示没有设备时返回空列表对吗复述可以及时发现理解偏差。第五步拆分开发任务例如1. 新增请求参数对象 2. 增加Controller接口 3. 编写Service业务逻辑 4. 增加Mapper查询 5. 添加权限校验 6. 编写测试数据 7. 完成接口自测。第六步评估影响范围开始修改前先检查是否修改公共方法 是否修改数据库字段 是否影响已有接口 是否需要前端配合 是否需要其他服务配合 是否需要新增配置九、如何根据需求设计数据库表设计表时不要直接想到什么字段就加什么字段。可以按照下面的顺序。第一步找到业务对象例如二手车订单业务中可能有用户 车辆 订单 支付记录 退款记录通常一个核心业务对象对应一张主要数据表。第二步设计主键一般可以使用idBIGINT注意区分数据库主键 业务订单号 第三方交易号例如id 数据库主键 order_no 业务订单号 third_trade_no 第三方支付流水号这三个字段的作用不同不能混用。第三步设计业务字段订单表示例CREATETABLEorders(idBIGINTPRIMARYKEY,order_noVARCHAR(64)NOTNULL,user_idBIGINTNOTNULL,vehicle_idBIGINTNOTNULL,amountDECIMAL(12,2)NOTNULL,statusTINYINTNOTNULL,created_atDATETIMENOTNULL,updated_atDATETIMENOTNULL);金额不要使用float或double可以使用DECIMALJava 代码中通常对应BigDecimal第四步设计状态字段不要只写status 1要明确每个状态的含义0待支付 1已支付 2已取消 3退款中 4已退款Java 中可以使用枚举统一管理。第五步考虑索引经常作为查询条件的字段可以考虑建立索引order_no user_id vehicle_id status created_at但索引也不是越多越好需要根据实际查询场景设计。第六步保留审计字段常见字段created_at created_by updated_at updated_by deleted十、写代码前先分析旧代码修改旧代码前至少做四件事。1. 查看方法被谁调用使用 IDEA 的Find Usages。2. 判断是不是公共方法例如原方法publicListDevicelistAllDevices(){returndeviceMapper.selectAll();}新需求只需要查询某个项目的设备不要直接改变原方法含义。可以新增publicListDevicelistDevicesByProjectId(LongprojectId){returndeviceMapper.selectByProjectId(projectId);}3. 确认字段真实含义看到projectId时不能只根据名字猜。需要确认它是本系统主键 业务项目编号 第三方平台项目ID4. 列出影响范围Controller Service Mapper 数据库表 定时任务 消息消费者 其他微服务十一、如何使用 Debug 调试Debug 不是随便打一个断点然后不停地点下一步。建议按照下面的步骤。第一步确定问题入口先确认问题发生在哪个接口、哪个任务或哪个消息消费者中。第二步在关键位置打断点可以打在Controller入口 Service业务判断 数据库查询结果 异常发生位置 返回结果位置第三步观察关键变量重点查看请求参数用户信息数据库查询结果状态值循环次数返回对象。第四步单步执行常用操作Step Over执行当前行 Step Into进入方法 Step Out跳出当前方法 Resume继续运行第五步验证自己的判断Debug 的目的不是“看看代码怎么运行”而是验证一个猜测。例如我怀疑传入的是第三方项目ID 我怀疑数据库查询返回了空集合 我怀疑订单状态判断写反了 我怀疑事务没有生效。十二、解决 Bug 的通用流程遇到 Bug 后可以按照以下顺序排查。第一步先复现问题确认问题是否必现使用了什么参数在什么环境发生哪个用户发生正常结果应该是什么。第二步查看完整报错重点关注Exception Caused by ERROR SQL 请求参数 调用链Java 异常通常要从最底层的Caused by开始分析。第三步确定问题范围可以先判断问题属于哪一类前端传参问题 后端代码问题 数据库数据问题 配置问题 网络问题 第三方接口问题 权限问题 缓存问题第四步查看最近改动gitloggitdiff如果原来正常、最近突然出问题优先检查最近修改。第五步逐层排查请求有没有到达服务器 ↓ 参数是否正确 ↓ 业务判断是否正确 ↓ SQL是否正确 ↓ 数据库数据是否正确 ↓ 返回结果是否正确第六步修复后进行回归测试不仅要测试出错的场景还要测试原来正常的功能有没有受到影响。十三、如何排查线上问题线上问题和本地 Bug 最大的区别是不能随便改数据、重启服务或添加断点。线上问题通常按照以下步骤处理。第一步收集基本信息发生时间 用户账号 请求地址 请求参数 订单号或业务编号 错误提示 影响范围第二步查看日志根据时间和业务编号搜索grep订单号application.log或者grepERRORapplication.log第三步查看数据库确认数据是否存在状态是否正确是否出现重复数据数据更新时间是否异常。第四步确认服务状态检查服务是否存活 CPU是否过高 内存是否不足 磁盘是否已满 网络是否正常 依赖服务是否可用第五步先止损再定位根因严重问题发生时优先考虑临时关闭入口 回滚版本 降级功能 限制流量 人工修复数据不要为了找到“最完美的原因”让问题继续扩大。十四、需要了解的基础网络知识Java 后端至少要理解下面这些概念。IP服务器或设备在网络中的地址。端口同一台服务器上不同程序使用的入口例如MySQL3306 Redis6379 HTTP80 HTTPS443域名方便人记忆的地址最终会解析成 IP。HTTP 和 HTTPSHTTPS 可以简单理解为在 HTTP 的基础上增加了加密和身份验证。请求常见组成请求地址 请求方法 请求头 请求参数 请求体常见状态码200请求成功 400请求参数有问题 401没有登录 403没有权限 404资源不存在 500服务器内部错误十五、代码写完后怎么测试至少测试以下场景。正常场景正常参数 正常用户 正常数据 预期状态异常场景参数为空 参数格式错误 数据不存在 状态不允许 第三方服务异常 数据库异常权限场景未登录 普通用户 管理员 查询其他用户的数据边界场景金额为0 超大数据量 重复请求 分页第一页 分页最后一页 空集合建议记录自测结果1. 正常项目查询通过 2. 项目不存在通过 3. 参数为空通过 4. 无权限访问通过 5. 无设备数据通过 6. 分页查询通过十六、提交代码前的检查流程第一步查看修改文件gitstatus确认有没有遗漏文件有没有误提交本地配置有没有提交日志有没有提交target有没有提交 IDEA 文件。第二步查看代码差异gitdiff已经加入暂存区后gitdiff--cached重点检查有没有误删代码 有没有调试代码 有没有System.out.println 有没有测试账号和密码 有没有无关格式修改第三步编译和测试mvn clean compile或者mvn cleantest第四步提交代码gitadd指定文件gitcommit-mfeat: 新增项目设备查询接口新人阶段尽量谨慎使用gitadd.避免把所有本地文件一起提交。十七、遇到问题应该怎么问同事不要只问这个怎么不行可以按照下面的格式提问我正在做什么 根据项目ID查询设备列表。 目前的问题 接口可以收到参数但数据库查询结果为空。 我已经确认 数据库中存在关联数据 SQL本身可以执行 请求参数不为空。 我的判断 传入的可能是第三方项目ID 但SQL使用的是系统内部主键。 想确认 这里应该使用哪个项目ID好的提问包含四部分你在做什么出现了什么问题你已经检查了什么你希望别人帮助确认什么。十八、试用期如何做好工作汇报不要只在任务完成时汇报。遇到风险时也要及时说明。每日计划今日计划 1. 完成订单查询接口 2. 补充权限校验 3. 完成接口自测 4. 提交代码审核。每日总结今日完成 1. 完成订单查询接口 2. 完成参数和权限校验 3. 完成6个场景的自测。 当前问题 测试环境缺少部分车辆数据。 下一步 补充测试数据后进行前后端联调。任务出现风险时可以这样表达接口主体逻辑已经完成目前测试环境缺少关联数据可能影响下午联调。我正在补充测试数据完成后会重新验证。领导最担心的不是出现问题而是问题已经很严重了他却完全不知道。十九、Java 新人完整工作流程以后接到开发任务可以按照下面的流程执行。听需求 ↓ 记录需求 ↓ 复述确认 ↓ 分析旧代码 ↓ 梳理调用链 ↓ 确认数据库 ↓ 拆分任务 ↓ 编写代码 ↓ Debug调试 ↓ 功能自测 ↓ 检查Git文件 ↓ 提交代码 ↓ 汇报结果可以记成一句口诀听、记、复、查、拆、写、测、提、报。解释听听清楚需求 记记录关键信息 复复述需求并确认 查查看旧代码和影响范围 拆把任务拆成小步骤 写开始编写代码 测完成正常和异常测试 提检查并提交代码 报汇报进度和风险二十、试用期每日检查清单开始工作前[ ] 今天要完成什么 [ ] 任务优先级是什么 [ ] 是否已经拉取最新代码 [ ] 是否存在没有解决的问题 [ ] 是否需要其他人配合开发过程中[ ] 需求是否确认清楚 [ ] 是否查看了旧方法调用关系 [ ] 是否确认了数据库字段含义 [ ] 是否考虑了异常情况 [ ] 是否及时反馈风险提交代码前[ ] 项目能否正常编译 [ ] 正常场景是否通过 [ ] 异常场景是否测试 [ ] git status是否检查 [ ] git diff是否检查 [ ] 是否误提交配置和日志 [ ] 是否说明了改动内容总结Java 新人想顺利度过试用期最重要的并不是背多少八股文而是养成稳定的工作习惯。核心可以总结为五点不懂很正常但不要一直憋着。接到需求先确认不要立即写代码。修改旧代码前先查看调用关系和影响范围。代码写完不等于完成还要测试、检查和提交。出现问题及时反馈不要等到截止时间才说。最后记住一句话试用期不要求你什么都会但要求你做事有记录、有确认、有检查、有结果、有反馈。