Home  >  Article  >  Java  >  Development ideas for Java enterprise-level projects

Development ideas for Java enterprise-level projects

黄舟
黄舟Original
2017-09-30 10:07:422446browse

Java enterprise-level project development ideas. I met by chance and learned something from reading, so I share it with everyone. This article does not involve cases, but only talks about thoughts and concepts. Friends in need can refer to it.

What is enterprise-level project development

"Enterprise-level project", enterprise-level project development, Java is also enterprise-level project development, we say this everywhere, Listen, we talk about it every day, but what kind of project is considered "enterprise-level"? Can the small or large projects that I have been working on be considered enterprise-level? In other words, GXPT can be regarded as an enterprise-level project. Next, I will communicate and learn with you!

1. Current status of project development

We have been doing a lot of large and small projects in our improvement class. I have to work on projects all the time and catch up on projects. I believe that from the time we started working on projects until now, we have done many large and small projects, and there are more or less successful projects that we are very proud of. Now everyone looks back and thinks about how our projects are usually made! Even if each development team is different, our minimum implementation and overall design are still the same despite the project deadline, changes in customer needs, and various supervisions. It is more or less the same, but the scalability and flexibility are somewhat different.

Every time a project comes, after a few meetings, the project starts. People start to be assigned, and some requirements from customers start to be analyzed. Then some key developers start to set up the project for the project. shelf. So a project is underway. When it comes to building a framework for a project, professionally speaking, it means building an architecture. What we call architecture is actually dividing the project into several logical layers according to convention. As for whether this architecture is good, what are the risks, and whether it can adapt to future changes. , the risk and feasibility analysis of the technology used are rarely considered. The reason is very simple: it is generally developed in this way, and there should be no major problems. Indeed, many projects are indeed developed in this way, and many of them are successful. These are understandable. As for whether the standard is standard or not, and whether it follows any development principles, not many people care. No matter what, the project is successful.

In project development, we are very clear about many principles: single responsibility, dependency inversion, testability, maintainability... Many times, when coding, these Originality becomes redundant, and the project ends up becoming an accumulation of functional codes. Especially in the process of rushing the project, the effect of code accumulation becomes even more obvious: as long as the functions are completed, the rest will be discussed later. Sometimes this "say it later" becomes "never say it again" and just make do with it. There is nothing wrong with this.

In this way, year after year, we develop projects, do projects, and catch up on projects. Many people at Primary Key will become less interested in doing software development later as the project progresses: I originally thought that software development was a high-intelligence activity, but now I find it is a bit like manual labor. Year after year, month after month, we develop different systems for different customers.

The information shows: In the company...

I believe that many companies often put forward many very "attractive" slogans: by doing a large number of projects, accumulation and development Common components, the more components there are, the future development will just be a pile of blocks.... But in real projects, customers are constantly urging, and the superiors are also urging, and in the end no one cares about whether it is universal or not. Project development becomes more and more tiring. I believe this is one of the reasons why many developers change careers and transform.​

2. What is an enterprise-level project

Learning Java is getting closer and closer, do you often think about this issue? What is an enterprise-level project? Can a project developed for an enterprise, institution, or client company be considered an enterprise-level project? Is a very large project an enterprise-level project? Isn’t a small project considered an enterprise-level project? Is a code with tens of thousands or hundreds of thousands of codes an enterprise-level project? Confused!

In fact, I personally have not been very clear about the concept of "enterprise level". It’s just that I say this every day, and Teacher Mi also instilled in me the idea of ​​enterprise-level development. At first, I was really a little satisfied, and it sounded quite profound.

When it comes to enterprise-level projects, there are many concepts that come with it: enterprise-level architecture, enterprise-level development.

But no matter what: the concept of enterprise level has nothing to do with the size of the project. It can even be said to have almost nothing to do with it.

In fact, enterprise-level projects are actually projects with an "enterprise-level" mentality.

In the first part of the article, we arrived at the way we do projects now: the "stacking" of code functions. The code accumulated through this kind of accumulation is only used for this one project, and is almost useless for other projects in the future. This means that the code is not reused enough, and often in a project, a lot of code is miscellaneous. Yes, many similar functions require their own set of codes. Problems such as these have caused projects to become more and more generic, and many beautiful slogans have turned into bubbles.

Enterprise-level projects have at least the following characteristics:

Stability

Flexibility

Isolation

Reusability

Maintainability

I believe that these features are familiar to everyone. I won’t give a detailed analysis, everyone knows it. Having said all this, you may think that what I am saying is nonsense, but there is one thing that can be said: Nowadays, we do ignore these things when developing projects. Because of this neglect, the development of projects does speed up, but In the long run, project development will become increasingly tiring. If you think a little bit like this every time when developing, and try to write code that conforms to those characteristics, slowly, a kind of "Enterprise-level mind" will slowly come out, a A very similar metaphor: During a project, we encounter a difficult technical problem. We often spend a lot of time to overcome it, and finally solve it. Indeed, we can analyze this process of overcoming thinking like this: There is a wall between our thinking and the answer to the problem. When we try various solutions again and again to overcome the problem, our thinking hits this wall again and again. The wall finally breaks down and we get the solution to the problem.

 In the same way, we bring "enterprise-level" thinking to the project, and we hit the "wall" little by little, and finally The result is that common functions are encapsulated into common components, which can be accumulated for future projects.

Summary

My own feelings in this, and my own "enterprise-level mind", gradually But because I worked on projects with this idea in mind, I deeply realized that enterprise-level ideas can solve practical problems in the maintenance of personnel, the maintenance of Yonghe, the development of Kindness Commune, and the repair of problems in the examination system. I encountered repeated code modifications, website re-releases, flexible functions, and flexible addition of components. Through the universal website, Teacher Mi also patiently deepened this development concept for me over and over again. Personally, I think my thinking has improved, and it has also improved. I really got a lot of common components. Although the components need to be perfected, they already have some sweetness. The cost of later maintenance of the system is also greatly reduced. Enterprise-level development ideas are comprehensive in Java learning. GXPT middle school teachers also use this enterprise-level development concept to show off their talents.

The above is the detailed content of Development ideas for Java enterprise-level projects. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn