[ERP]SpringBoot集成Swagger技术(☆)

简介: 本文介绍如何从Gitee克隆项目并运行代码,涵盖JDK、Maven等环境配置问题的应对策略,强调新人应主动请教同事。要求使用Swagger优化接口文档,实现参数校验与功能描述,并遵循Git分支命名及提交规范,提升开发效率。

1.代码运行

git仓库地址:https://gitee.com/Herbbbb/erphome-work

请你完成以下步骤

方案一:

  • 克隆代码到Idea,如果你时间允许不妨试试SSH拉取方式

方案二

  • 下载Zip包,不建议,但如果上班后短时间拉不下来优先这种方式让代码跑起来

入职后,对于JDK、Maven、Git、Idea....软件安装类你应该请教谁?

  • 以上问题,是大家面临的第一道坎,15K大佬一样一天配置不好maven仓库,请认真思考该请教谁?

当你意识到,公司的环境配置类问题都可以问同事、组长的时候你应该怎么问?

  • 不知道该不该问?不敢问?这是多数新人最纠结的一个点,请认真思考你会怎么问

当你把项目运行起来之后,此时一个全新的工程在你面试,组长立马就给你如下的需求,你会怎么处理?

  • 现在的公司愈发需要即战力,一个陌生的环境、工程、团队,紧急的任务,请认真思考你将怎么着手?

2.需求描述

现有的三层架构代码,前端反馈看不懂,需要通过swagger包装一下,请你完成

  • 所有接口的入参、出参都能够看懂
  • 所有接口都有功能描述
  • 所有请求入参,做好非空校验
  • 注意,不是自己手动if-else,而是借助于@NotNull或者@NotEmpty注解

以上这句话你可能不理解,上班也存在大量这样一句话需求,怎么保证自己能知道做什么是很重要的。

最终参考实现效果:

2.1 多说一句(做完再看)

  • 你是否考虑过此次修改需要创建新的分支
  • 你是否知道创建分支、代码提交的规范
  • 分支创建默认:
  • feature-姓名缩写-需求描述
  • 如:feature-hb-addSwaggerDoc
  • 代码提交规范
  • 新增功能提交注释:feat:需求描述
  • 如:feat:新增swagger
  • 修改功能提交注释:fix:需求描述【最常用】
  • 如:fix:修改原订单逻辑,增加Redis缓存
  • 重构功能提交注释:refactor:需求描述
  • 如:refactor:重构商品模块

3.涉及技术点

阶段二核心:git、maven、springboot、swagger


相关文章
|
6月前
|
监控 Java 测试技术
OOM排查之路:一次曲折的线上故障复盘
本文记录了一次Paimon数据湖与RocksDB集成服务中反复出现的内存溢出(OOM)问题排查全过程。通过MAT、NMT、async-profiler等工具,结合监控分析与专家协作,最终定位到RocksDB通过JNI申请的堆外内存未释放是根因,并分享了转向Flink写入Paimon的解决方案及排查思路,为类似技术栈提供借鉴。(239字)
|
6月前
|
负载均衡 算法 Java
5-微服务篇
本文详解SpringBoot自动装配原理、启动流程、核心注解@SpringBootApplication组成,以及SpringCloud微服务中注册发现、负载均衡、限流熔断等机制,涵盖常用组件如Nacos、Ribbon、Feign、Sentinel及Gateway的使用与配置,适用于面试与实战。
|
6月前
|
消息中间件 监控 Java
RocketMQ:底层Netty频繁OS OOM
本文记录了一例Java应用因Netty多ClassLoader加载多个PooledByteBufAllocator实例,导致堆外内存超限引发OS OOM的排查过程。通过NMT、Arthas等工具分析,发现多个中间件独立加载Netty,各自绕过JVM直接内存限制分配堆外内存,总量远超MaxDirectMemorySize。最终定位RocketMQ客户端为主要内存占用者,建议短期调小Java堆让出内存,长期优化中间件内存使用。
 RocketMQ:底层Netty频繁OS OOM
|
6月前
|
存储 缓存 运维
一场FullGC故障排查
本文记录了一次由Full GC引发的CPU使用率飙升至104%的问题排查过程。通过分析JVM堆内存,发现大对象(List<Map>)导致老年代频繁被占满,进而触发Full GC。利用JProfiler定位到问题根源:Excel数据以低效结构加载至内存且长期驻留,造成内存膨胀。最终提出“治本”与“治标”两类解决方案,并总结了线上高CPU问题的排查思路与经验。
 一场FullGC故障排查
|
6月前
|
测试技术
发布模式
蓝绿部署通过两套并行系统实现零停机发布,绿色为现役系统,蓝色为新版本。测试无误后切换流量,支持快速回滚。适用于系统内聚、数据解耦场景,保障发布稳定性。
|
6月前
|
SQL 监控 机器人
钉钉通知
本文介绍如何通过Java代码调用钉钉机器人API,实现系统告警消息的实时发送。涵盖机器人创建、Webhook配置、Postman测试及Java代码实现,并提供限流提示与常见失败原因分析,助力高效集成钉钉通知。
 钉钉通知
|
6月前
|
安全 Java 测试技术
从Google线上故障,谈灰度发布的重要性
2025年6月12日,Google Cloud因未灰度发布的新配置引发空指针异常,导致Gmail、YouTube等服务中断超7小时。本文剖析故障根源,详解配置灰度发布的重要性及Nacos等工具的实践方案,强调通过IP、标签、流量等多路径实现安全发布,保障系统稳定性。
 从Google线上故障,谈灰度发布的重要性
|
6月前
|
存储 运维 NoSQL
Redis:内存陡增100%深度复盘
本次事故因大KEY调用量随业务高峰增长,导致带宽占满、Redis内存使用率迅速达100%,缓冲区膨胀致使SET/GET超时。根本原因为输出/输入缓冲区失控,而非数据存储溢出,最终引发服务全面不可用。
 Redis:内存陡增100%深度复盘
|
6月前
|
SQL 分布式计算 运维
XXLJOB:超长定时任务慢节点优化实践
本文针对ODPS大宽表任务运行缓慢问题,通过定位耗时卡点、解决数据倾斜与计算堆积,提出视图落表、节点拆分、前置裁剪、中表关联等优化方案,显著提升任务效率,产出时间提前4小时以上,并降低回刷成本与资源消耗。
|
6月前
|
自然语言处理 fastjson Java
FastJson:大面积故障规避案例
本文记录了一次由Kotlin与Java混编工程中误用`{}`赋值引发的FastJson反序列化崩溃问题。因将空对象误写为lambda表达式,导致FastJson内部静态标记位`kotlin_error`被置为true且无法恢复,进而使整个应用反序列化链路瘫痪。问题隐蔽性强,排查耗时两天,最终通过源码分析定位。文章反思了多语言混编下的语法混淆风险、框架信任边界及灰度发布的重要性,强调Bug是成长的阶梯。
 FastJson:大面积故障规避案例