In this article, I will describe the pitfalls and dangers of the Spring Boot CRUD template taught at Bootcamp. Let me make it clear that I am not against bootcamps. I simply know from my own experience what my students who have learned or not learned at Bootcamp how to create CRUD applications using Springframework are struggling with. Yes, many people at various stages of Bootcamp contact me.

Preface

Why am I mentioning Bootcamp? This is where the idea of "CRUD projects" began and spread to other areas of the Internet, and then they were copied and duplicated. I explained what CRUD is and how to write its code in the article First-class CRUD service – Java code, IntelliJ, step-by-step.

Repeatability and universality of solutions replicated in projects

The first trap is the repeatability and universality of solutions duplicated in projects implemented at Bootcamp. Why is this such a big problem? Let's look at it from the perspective of a recruiter who reviews a large number of CVs. When a recruiter sees another project on your CV with a similar name and looks similar to the previous ones. You start to wonder what makes a given person stand out from others like them? Why should this CV go to the next stage of selection?

As I wrote in Jak find your first job as a Junior Java Developer? "When reviewing your CV, the recruiter can create two groups: one is students, e.g. after IT studies, and the other group is people finishing Bootcamp. Unfortunately, students have priority. If our CV advances to the next stage, we should do everything to stand out from others with the CRUD template from Bootcamp.

How to solve the problem??

How to solve the problem of the commonness of CRUD applications duplicated at Bootcamp? I have already written about it in Your own portfolio – how to build a good portfolio and where to place it?. "In my opinion, a good portfolio should contain both one "larger" project using the Spring Framework as well as "smaller" projects presenting, for example, the properties of the Java language. A project in the Spring Framework is not necessarily the previously mentioned CRUD. If we do CRUD, it is important that it has good documentation in the READ.ME file and that the code itself contains unit tests, e.g. in JUnit and is compatible with SOLID and DRY. ". The solution is simply unconventional design.

I described an example of an unconventional project in How to find your first job as a Junior Java Developer?. “The project will consist of a server application and a mobile application connecting to it. We can, for example, create a mobile application that will prepare a clothing suggestion for a given day based on the current weather and location. It sounds complicated, but it really isn't.

Schematic and literal reflection of the learned template

Trap number two is "schematic and faithful reflection of the learned CRUD template." People who see the code from the article First class as a CRUD service - Java code, IntelliJ, step by step I am often asked "why write code like this and not the way I learned at Bootcamp or from a tutorial?" I encounter the same questions during my classes with students.

Let's think about the above questions. Why did I name the methods: create, read, update and delete, instead of: createCar, getCar, modifyCar, removeCar. Why didn't I use the Dto or Model suffix for the classes? Why is the main class called CarService and not CarCrud? I will answer the above questions in a moment, but first I will illustrate it using Java code.

// 1. poprawna konwencja nazewnicza według mnie
public class CarService {
    public Car create(Car car) {
        return null;
     }
}
// 2. poprawna konwencja nazewnicza według Bootcamp, tutorial
public class CarCrud {
    public CarDto createCar(CarDto carDto) {
        return null;
     }
}

In the code snippet above, the problem is the schematic approach to the naming convention. It's rare for different projects to have a naming convention that is the same or even similar to what we have seen in another project or been taught. A naming convention indicates, not dictates, how classes, methods, and variables should be named. This schematic approach obscures and blurs the meaning of creating a CRUD class.

As I wrote in First-class CRUD service - Java code, IntelliJ, step-by-step: "Very many applications are so-called CRUD, i.e. it provides basic operations of creating (create), reading (read), modifying (update) and deleting (delete) objects of some class. For example, let's take a car catalog, where we have the Car class. This is what you should focus on and adapt the CRUD template to the project.

Let me explain why “1. correct naming convention in my opinion' is a better solution. Adding "Car" to the method name, which gives us "createCar()", is redundant. First of all, we operate within the CarService classes and pass a "Car" type parameter to the method, i.e. create(Car car). In my opinion, this is enough to know that the "create()" method applies to objects of the "Car" class, i.e. it is in the context of a given class. This is a duplication of already existing information.

Of course, using names such as CarDto, CarModel, etc. makes sense if we are creating a multi-layer application, and I assume that we are creating one. Then we will have several different classes with the same name, e.g. Car. I wrote more about applications that have layers in Java applications have layers like a birthday cake - three-tier app.

How to solve the problem??

How to solve the problem of schematically and faithfully reflecting a learned CRUD template? First of all, you should treat the template as a set of guidelines that solve a specific problem, and not as a way to solve all programming issues. It's like installing a door, you know that in most cases it will be a rectangle that should be mounted in the wall. Then the customer appears and says that they want it to be, for example, a sliding door with a window for his cats.

Summary

Creating CRUD applications should be practiced. You need to find several tutorials and courses showing how to do it and follow each of them. If possible, you can separate a common part from them and create your own recipe for a CRUD template.