Two days ago, I said THAT I would write a project to keep iterating, and many friends expressed their support and encouragement. The first article of the project has come
I gave the project a name, English name is: Austin, Chinese name is: Austin
The name does not have any special meaning, I simply think the name is good-looking, to put it bluntly, I like it.
When naming projects, you can be a little less formal. Take the name of the system can be done according to their own ideas on the line, as long as the somebody else used your system, natural “do as the Romans do”.
Let’s cut to the subject of the day.
Starting a project from scratch, also have to build the technical environment, so today to talk about the content of building the technical environment
The topic outline of this article: Maven and SpringBoot and Git
What is MAVEN? Why MAVEN?
Maven is a “project management” tool
I remember when I was in college, I didn’t use Maven, and the biggest headache was the dependency JAR packages. When I learned about Maven, my first impression was that it was a dependency package management tool
After the first experience, it smells so damn good! No more searching for jar packages!
Maven is not only responsible for “dependency package management”, but also for “compilation”, “testing”, “packaging”, “deployment” and so on.
The maven command I often use in daily development:
MVN compile 2 MVN test 3 MVN clean 4 MVN pakage 5 MVN install 6 MVN deploy 7 MVN versions: set-dnewVersion = XXXX Dmaven.test.skip=true -dmaven.javadoc. Skip =trueCopy the codeMost Java back-end projects today use Maven as a “project management” tool, at least as far as I’m concerned.
Some people wonder: Isn’t there a rising star Gradle in recent years
To tell you the truth, I haven’t (but I did a little digging.
As far as I know, Gradle is generally more flexible and concise than Maven, and is currently used in Android projects. It is also important to note that Gradle costs more to learn than Maven.
Projects on the Java back end are becoming lighter and less flexible in many cases (Maven’s capabilities are mostly adequate). XML is not unreadable for brevity (everyone is developing on ides these days, after all). So, this time I built the project directly using Maven
However, since I haven’t used Gradle much, I can’t say I’m using Maven better than Gradle (at least for now, I think Maven will last for another 10 years)
Why SPRINGBOOT
This time, I choose SpringBoot as the basic environment of the project. As for the reason of SpringBoot, I will first share the dialogue in the group with you.
I remember one day, one of my friends asked me in the group: today I went to an interview, and the interviewer asked me what is the advantage of using SpringBoot
One of the best things about SpringBoot is that it allows crappy developers like me to work as programmers.
I learned SSH and SSM in college before Maven, and setting up environments was especially troublesome. (I even wrote a blog about how I integrated SSH and SSM.)
There are several technology stacks that can be used in a project, and each stack needs to have its own configuration (common Spring, SpringMVC, Mybatis, etc.), and then these technologies need to be compatible with the corresponding version (usually we integrate these technologies into Spring). When we introduce a new framework, we naturally need to align Spring versions and have corresponding configuration files.
It was configuration hell at the time (frameworks were flexible enough to allow us to write things that might need to be changed to the XML configuration, but over time, we realized that the XML configuration was no longer maintained…).
Based on this background, SpringBoot came into being, it is the most obvious is to simplify our development of configuration work. When a technology reduces development effort it has one characteristic: convention over configuration (right out of the box)
Once SpringBoot is introduced, you can quickly write the HTTP interface from zero in just a few lines of code.
We used to need to integrate SpringMVC, need to configure a Tomcat server, need to align their versions (compatible)….
I think there are two things to know about SpringBoot as a user:
Spring-boot-starter-parent = spring-boot-starter-parent; spring-boot-starter-parent = spring-boot-starter-parent; spring-boot-starter-parent = spring-boot-starter-parent This allows us to use it in projects without having to write versions (because SpringBoot already does it for us by default) and without worrying about version conflicts (:
Second, when starting the SpringBoot project, it also helps us initialize many of the default configurations. (This is also a place where interviews often look for “auto-configuration”). In general, @SpringBootApplication is equivalent to the following three annotations:
@SpringBootConfiguration@EnableAutoConfiguration@ComponentScan
The @enableAutoConfiguration file is loaded with the meta-INF/Spring. factories file, and then the data is filtered with the EnableAutoConfiguration key. Load into IOC container, realize automatic configuration function!
Most of the new Java backend projects written today use SpringBoot as their development environment
As a programmer, one of my biggest pet peeves is dealing with environment configuration and version dependency issues (real dirty work). Although I only have to do it once a lot of the time, it feels like it’s really like this:
Why is the project structure multi-module?
I set up the project, called it Austin, and created several New Maven Modules on the IDE, which are currently (and may be added later) :
- Common (Basic information ->POJO/ enumeration configuration)
- The support (Data acquisition – > DB/Redis/Elasticsearch)
- Service-api (Service Interface)
- Service-api-imp (Service Interface implementation)
- Web (HTTP interface)
When we first learned to write code, we were not so particular about it. We could just drop a shuttle into a package and do it.
Later, they said they were going to subcontract and write different modules into different packages. We will create a new package (folder) under the project, such as DAO /service/ Controller
Up to now, it’s basically modular, with different responsibilities assigned to different modules. Pom files under Austin are generally used only to manage dependencies (define dependencies and version information on the parent POM, depending on which submodule needs to be introduced)
<dependencyManagement>
<dependencies>
<! Mysql -->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.35</version>
</dependency>
</dependencies>
</dependencyManagement>
Copy the codeSo this kind of module is better than before subcontracting?
Assuming we’re subcontracting, that’s all the code on one module. Each time we make a change, we need to recompile the entire module (maybe I only changed one of the Dao package implementation classes, but compiled the entire module).
Skip =true MVN compile – dmaven.test. skip=true
However, this is only one aspect, it seems not very convincing. I think the most important thing is that we can reuse the modules later
For example, now I have the Austin project, and in order to process the data, I need to create the corresponding Flink application. Flink-related code may not be written under the Austin project due to circumstances
(This is just an example of what I’m trying to say: mature projects often have more than one Git address to cover the entire functionality. Most of the time, different functions are separated into different projects).
There is a good chance that the tasks I need to do will be repeated for different projects (e.g., I need to read the database to get the data). This is where the benefit of module splitting comes in: you can directly import the corresponding JAR packages (such as support and Common).
No need to write the same code on two different projects
Is there anyone wondering why API and API-IMPl are divided into two modules? The purpose here is: if RPC calls are introduced in the future, we just need to provide the API module out, the API module dependencies are generally very small.
(Resolving version conflicts is a dirty job, don’t give people a bunch of useless dependencies when they embed your SDK just to use your service to get the corresponding information.)
Why GIT
At this point, the project shelf has been set up. I’m going to upload the project to Gitee and have fun with everyone (:
Git is a version control tool. With Austin managed by Git, my submission will be seen every time (this is especially important in multi-player collaborations)
In addition, once you have the concept of “versioning”, you can use Git to roll back versions at will
When I started out as an intern, the company used SVN (I had a very vague understanding of version control tools at the time, but in my opinion, it meant uploading the code to a central server, only it could compare the similarities and differences of each change).
Since then, I have been in contact with Git in my company. (Now I can’t develop without Git, and it is easy to learn and enjoyable to use.)
Here are some Git commands I use every day:
Git add /git commit /git push 5. Git fetch 6. Git merge 7. Git pop 8. Git reset --hardCopy the codeI usually use half command line and half IDE integrated Git tools. In general, what is comfortable to do (there is no limit to say that must use the command line, I am my own operation is faster to do)
The biggest reason I’m using Git here for this project is that THERE are remote repositories that hold my code and you can see it (:
Gitee link: gitee.com/austin
GitHub link: github.com/austin
conclusion
To be honest, if you don’t already have a job, I recommend learning the basics of Maven and Git (so you don’t have to go to the office looking confused).
There is no end to learning SpringBoot. My personal understanding is that after learning how to use SpringBoot, you can try to learn for “interview questions” (after all, the content of interview questions are mostly core, at least not partial to useless).
Austin Project Construction:
- Maven: Dependency package size + Project Management (multiple modules)
- SpringBoot: Basic technology environment setup (out of the box)
- Git: version control tool (upload code to remote Gitee)
Let’s call it a day. It took me one night to build the shelf and two nights to write this article. Since coming up with the idea for this iterative project, evening productivity has gone up dramatically.
Follow my wechat official account [Java3y] to talk about something different!
Online Interviewers + Write Java projects from scratchContinuous high intensity update! O star!
Original is not easy!! Three times!!