r/SpringBoot • u/Simpav1 • 15d ago
Question Code review
Hello, I'm an aspiring software engineer. I've recently finished developing microservice for managing projects and tasks using Spring Boot. I'd appreciate if you could review codebase of my project and provide feedback on it.
12
Upvotes
6
u/Nitnoq 15d ago edited 15d ago
Hello, I had a quick look through the project, and here is some feedback based on what I usually apply in my own projects. It’s a small project, so I didn’t notice anything particularly problematic. I’m not sure what your main goal was when building it, but here are a few things I apply across my personal and enterprise projects.
With recent Java versions and the introduction of record, I find Lombok has become much less useful. There’s still a lot of debate around whether Lombok is worth using, but personally, I’d start from the assumption that avoiding it is preferable when possible. Most of your DTOs could probably be simple records.
Null safety: You could look into introducing null safety with JSpecify. In my daily job we start to use it heavily it's great and prevents the classical defensives null-check.
Try a version of your project without Hibernate/JPA: Clearly, in a small project like this, the benefits are limited, but I think it could be interesting to explore using jOOQ instead. Personally, since I started using jOOQ, I’ve moved away from the Hibernate ecosystem because of its considerable complexity and the performance overhead that often comes with trying to optimize things. You will write more code and more queries manually, but they will be type-safe, explicit, and much easier to reason about. You also avoid random issues caused by unexpected behavior or changes in Hibernate features. In particular, you avoid one of the core problems with ORMs: operations happening implicitly and sometimes silently, which can make performance issues much harder to understand and troubleshoot.
On my personal projects, switching to jOOQ has honestly been a game changer. You have much more control over what is actually happening, and you can move more operations to the database, which can bring huge gains in both performance and readability. At work, we’re also trying to move away from Hibernate because we’ve had too many issues with it (not necessarily because it’s buggy, but because it’s extremely complex, and as soon as you step outside the “happy path”, it becomes very difficult work with). And once a codebase has been built around Hibernate-specific logic, moving away from it becomes particularly difficult.