How It Started

When I was learning Java before, I always had a strange feeling: I could understand the syntax, and I could follow along with videos, but when it came to actually building something myself, I did not know where to start.

So later I simply put a bunch of exercises and small projects into one repository, stacking them up from Java basics, JDBC, and Servlet/JSP all the way to Spring, Spring MVC, and Spring Boot. It looks a bit messy, but it happens to record my process from “being able to write code” to “being able to get a business system running.”

Project URL: yfgug/project

What Is in This Repository

The repository is mainly divided into four parts:

Directory Content Tech Stack
java-basics/ Java basics and JDBC exercises JDBC, PreparedStatement
ecommerce-platform/ A traditional e-commerce platform demo Servlet, JSP, DBUtils, connection pool
spring-experiments/ A collection of Spring ecosystem experiments Spring, Spring MVC, AOP, transactions
dormitory-system/ Campus dormitory management system Spring Boot, MyBatis, MySQL

This is not one of those projects that immediately throws in microservices, gateways, and a full message-queue stack. It is more like a learning path: first get database connectivity straight, then get web requests working end to end, then understand layering, and finally use Spring Boot to integrate all of it.

Why I Think It Is Useful

Many tutorials break knowledge points into very small pieces: today JDBC, tomorrow Servlet, the day after tomorrow Spring Bean. No single concept is hard, but the real difficulty is connecting them.

For example, behind the most ordinary “query student list” there is actually a whole chain:

  1. The page sends a request.
  2. The Controller receives parameters.
  3. The Service handles business rules.
  4. The Mapper/DAO queries the database.
  5. Data is returned in a unified format.
  6. The frontend then renders the result.

Once this chain works end to end, the annotations in Spring no longer feel so mysterious. @Controller, @Service, and @Mapper are not there to look fancy; they simply put different responsibilities in different places.

CRUD Is Nothing to Be Ashamed Of

I used to think CRUD projects were ordinary and not worth writing about.

Later I realized CRUD is not simple at all. Create, read, update, and delete are only the surface; the real trouble is all the edge cases:

  • Should queries support combinations of multiple conditions?
  • Should deletion support batch operations?
  • Should file uploads restrict format and size?
  • Should login be locked after too many failures?
  • Should the data format returned to the frontend be standardized?
  • Is the shopping cart in the Session still there after the page is refreshed?

These things do not appear in “Hello World,” but they appear in every slightly more realistic project.

What AI Did in It

Quite a bit of the code in these projects was generated with AI assistance, especially the highly template-like parts: entity classes, Controllers, Services, Mappers, DAOs, and some frontend interaction snippets.

But I increasingly feel that AI writing code is not about “completing the project for you”; it is more like “pulling you out of repetitive work.”

It can help me quickly generate a first version, but in the end I still have to review it myself:

  • Does the SQL query the wrong table?
  • Are parameters validated?
  • Are there security issues in file uploads?
  • Can the business flow actually work end to end?
  • Does the code merely run, or can it still be changed later?

This step cannot be skipped. Otherwise, the project may look complete while being full of pitfalls inside.

Final Thoughts

This repository is not advanced, but it matters a lot to me.

It confirmed one thing for me: learning backend is not about memorizing framework names or stacking tech stacks; it is about running through the relationships among data, requests, business logic, and pages again and again.

From Java SE to Spring Boot, the real change is not that the code got shorter, but that I began to know how a project should be split, connected, and delivered.

That is probably the point of practicing with projects.