In my experience as a developer, senior developer, architect, I have encountered good, poor, and even ugly enterprise-class Java projects. When I ask myself what makes a project successful and another failure, I find it hard to get a perfect answer, as if it's hard to define all the software projects with success. The Java EE project is no exception. Therefore, the project is divided into different levels of success or failure. In this article, I want to reveal to you--the reader friend--the biggest 10 dangers that affect enterprise-class Java projects.
Some of the dangers are simply delays in project progress, some are signs of error, and some hope that the project will be completely unsuccessful. Nevertheless, if there is good preparation, the journey begins before the relevant knowledge and the familiar terrain of the wizard, all can be avoided.
This article is simple in structure and I will reveal the various crises in the following ways:
As noted above, we will examine each of the risks in the context of the Enterprise Java Project and its major phases. These project phases include:
Figure 1 illustrates these project phases and the various factors that affect them (especially those "sudden [knock-on]" effects)
Figure 1. Enterprise Java Project Phases
And their most likely reasons for failure.
Click on thumbnail to view full-size
Image. (KB)
Crisis 1: No understanding of Java, no understanding of EJB, no understanding of EE
OK, now I'm going to break it down into 3 small topics for further elaboration.
Description: Do not understand Java
Project phase: Development phase
Involved in the project phase: design, stability phase, existence phase
Affected system characteristics: maintainability, measurable (scalability), executive
Sign:
Solution:
You need to improve your Java knowledge, especially to understand its strengths and weaknesses. The presence of Java is far beyond the language itself, and it is equally important to understand the platform (JDK and tools). Specifically, you should qualify as a Java programmer (if you haven't)-you'll be amazed at how much you don't know. Further, it's also fun to take it as part of your team and promote it to others. Further, create a mailing list, focus on Java technology and keep it going. (All the companies I've worked with have these lists, most of them are at risk of not being updated) learn from your peers-they're your best resources.
Note:
How can you expect to build a successful enterprise-class Java application if you or other members of your team don't understand the programming language and the platform? Robust Java programmers for EJB and EE if ducks are for water. In contrast, poor inexperienced programmers will build a poor-quality Java EE application.
Description: EJB not understood
Project phase: Design
Project phase involved: development, stability phase
Affected system Features: maintainability
Sign:
Solve:
To improve your EJB knowledge, spend a weekend reading the EJB Specification (1.1 specification has 314 pages). Then read the 2.0 specification (524 pages) To see why the 1.1 specification no longer applies and what 2.0 specifications can bring to you. Focus on the parts of the specification that tell you--the application developer--What is the legal behavior in the EJB. Sections 18.1 and 18.2 are a good place to start.
Note:
Don't look at the EJB world in the eyes of your provider, the application server or the provider of other software developers. Make sure you understand the difference between a compliant EJB model and a special implementation. This will ensure that you can bring your technology to your provider (or other version) when you need it.
Description: Do not understand Java EE
Project phase: Design
The project phase involved: development
Affected system Features: maintainability, Scalability (scalability), executive
Sign:
Solve:
Learn about the advantages and disadvantages of the key components of Java EE and each component. The services are involved in turn, and the knowledge and capabilities are as important here.
Note:
Only knowledge can solve these problems. A good Java developer makes a good EJB developer--one step at a point where you can be a perfect leader. The more java/j2ee knowledge you gain, the more you will be able to design and implement it. Things'll start to slot into the place for you in design time. (Thought for half a day also do not know how to translate:-{)
Crisis 2: Excessive design (whether or not it is for EJB)
Project phase: Design
The project phase involved: development
Affected system characteristics: maintainability, measurable (scalability), enforceability
Sign:
Solve:
Solutions to excessive design can be found directly from XP (Extreme Programming): local scope, design, and coding to achieve minimal exposure [bare minimum] to meet demand without too much. When you need to be aware of future needs, such as average load requirements and behavior at the peak of the system load, do not attempt to "second guessing" [second-guess] systems will need to be in the future. In addition, the Java EE platform defines features such as scalability and task errors that need to be captured at the bottom of the server.
Note:
In addition to the solution above, use design patterns-they can significantly improve your system design. The EJB model itself uses design patterns extensively. For instance, the home interface in each EJB is an example of a finder and a factory pattern [the Factory and]. The remote interface of an EJB serves as the proxy for the implementation of the actual bean, and is the key to container interception calls and the ability to provide services such as transparent load balancing. Ignoring the value of design patterns is dangerous.
Another danger I keep stressing is that it is used for EJB use. Some parts of your application are designed as EJB models when they are not suitable to be used as EJB models, and your entire application seems to use EJBS to gain unlimited value. This is extreme design, I have seen the perfect servlet and JavaBean application in the use of EJBS when there is no good technical reasons, the mess, have to redesign.
Crisis 3: Discrete presentation logic and business logic
Project phase: Design
The project phase involved: development
The impact of system performance: maintainability, scalability, enforceability
Symptoms:
Solve:
The Java EE platform gives you the opportunity to represent logic separated from navigation and control and ultimately separated from business logic, which is called the MODEL2 structure (see Resources). If you have fallen into a trap, a more rigid approach may be useful. You should at least keep most of your self-contained fragments "vertically skinny" [thin vertical slices] (which is to say, how I lay out a fragment to be separated from how I changed my username and password). Use this approach in your system to rearrange.
Note:
Using a solid design that connects to a UI framework (such as a tag library) in your project will help you avoid logical separation problems and not worry about your own GUI framework design, which can give you a lot of implementation benefits. Evaluate each frame in turn and choose the one that works best for you.
Crisis 4: Not deployed where you are developing
Project phase: Developing
Project phase affected: stable phase, parallel phase, existence stage
System characteristics Affected: normal mind (Your sanity)
Sign:
Solve:
The solution to the crisis 4 is to replicate the environment of your product to your development environment. Develop the exact environment in which you intend to place the product-not on red Hat Linux with JDK1.3, and then on JDK 1.2.2 and Solaris 7. Further, do not develop on this application server but deploy to another server. At the same time, get a rough impression of the data in your product's database, and test it on it, not relying on artificially created data. If the product data is sensitive [sensitive], reduce its sensitivity, load it. Unexpected product data will be broken:
In the worst case scenario, each item will cause an exception, a null pointer, and a behavior you have never seen before.
Note:
Developers often come to the stage of stability to remember security ("Yes! The screen is normal, let's add the user as a confirmed employee "). Spend the same amount of time avoiding the pitfalls of security, as you do when you separate business logic.
Implementation is a complex process fraught with political and technical issues. You will encounter problems that you do not expect, and that is the whole of the implementation. The development environment and the stability environment give you the space to make mistakes and find problems before you implement them, and using this will reduce your pain and risk during application implementation.
The more projects you experience, the easier it is to know what to run and what not to keep a project Notepad for you and your partner. In the implementation process, your goal should be to make the same mistake no two times.
Crisis 5: Select the wrong (development tool) provider
Project phase: Provider Selection
Project phases involved: design, development, stability/load testing, implementation
System characteristics Affected: measurable, performance, maintainability, stability
Sign:
Solve:
To avoid a crisis of 5, you need a good supplier selection process. The crisis 10 is applicable here.
For Ides, the only way to evaluate it is to use it. The only way to evaluate the Java EE is to build an implementation of the features you use in your conceptual framework. In fact, when you spend 3 months developing and investing in a special training session, you don't want to have bugs between the tools.
So what happens when you run into trouble with a toolset on the halfway point of your development? Some tools seem to be more important than others. If you choose an application server that is not appropriate for your needs, you should accept it and change the specification. If the IDE is disgusting, set a minimum level of code specification (tabs for spaces, and so on), and let developers look for configurations that maximize productivity.
Note:
Knowing the best suppliers and tools as a special task is not a "just once" job. You need to constantly evaluate the market. For example, I have used 4 different ides in the past 12 months, depending on my application server platform rather than whether I write EJB code.
Crisis 6: Don't know your supplier
Project phase: Supplier selection
Project phase involved: All stages after vendor selection
Affected system characteristics: maintainability, measurable, executive
Sign:
Solve:
To avoid problems that may arise from not knowing the vendor, subscribe to the resources that all vendors can provide, such as mailing lists, newsgroups, and release notes (especially those revisions bugs); you'll get invaluable information.
Once you have selected the supplier, invest in the training immediately, then build a quick concept to break it. [Once ' ve picked your vendors, invest in training as soon as possible, ideally-OK before the project kicks off. Next, build a quick proof of concept to break the team in gently. So, the translation of the depressed:-{] Create two ejbs and deploy them, and then through your display layer technology (Swing Gui,jsps, etc.) Call them. If you try to build your development environment and try to meet a project goal, the setting of the environment will be unsatisfactory. In fact, I've seen a project without a deployment process, because "we don't have time". The significance of this is especially important when the team has to do 11 points every night just to get a published application. Therefore, spend some time in advance to deal with these details, you will save a lot of time on the way. For those who say "our plans don't give us so much time", I'm going to say, "Your plan doesn't give you time to do it." ”
Note:
What about the scalability [transferable] of the technology of the tool provider in the Java EE world? Let's take a look at the specific examples of two vendors--IBM and BEA Systems Company--the different application servers that support EJB1.1. Indeed, how much similarity does BEA WebLogic 5.1 and IBM WebSphere 3.5 have?
Here are just a few differences, there are many. Summary: The similarity between most suppliers is similar to that of chalk and cream. Becoming an expert on an application server does not mean that you are an expert on all servers. The above discussion is suitable for anything: IDEs, debugger, compiler tool, configuration management, and so on. Having experience with a particular tool is a good thing for evaluating a competitor. But that doesn't mean you can smooth over from one tool to another. Try to give yourself time to familiarize yourself with your tools.
Crisis 7: No design for measurable or enforceable
Project phase: Design
Project phases involved: development, testing, lifetime
Affected system characteristics: measurable, executable, maintainable
Sign:
Solve:
For crisis 7, you need to be aware of the performance and measurement of your system during the analysis phase--before you go into development, you need to know the numbers you want to get. If you know that you need to process 50 transactions per second, but all entity beans are designed to provide only 40 transactions/sec, then you need to look for alternatives to your system, such as stored procedures, batch processing or rewritten OLTP aspects [reworked OLTP aspects].
Try to turn to your tool suppliers-they should know the pros and cons of their products and help you.
Note:
No measurable or enforceable design is often inconsistent with crisis 2 (excessive design). In fact, they complement each other. For the crisis 2 My solution is to deploy only when absolutely necessary. For determining scalability and enforceability, you can set the maximum possible value when needed.
If you determine that a large number of measures are a required requirement, you can specify a single application server that supports maximum aggregation, possibly providing a transaction cache for your execution. Further, you can design business objects such as EJBS to maximize the use of the server architecture. XP does not have such a problem and you can still deploy it when you have to.
I look back in this way and think about the way that provides this balance. When I think of a simple system, that system needs to provide the functionality and behavior that the customer requires.
Crisis 8: The old development process
Project phase: Developing
Project phases involved: stability, lifetime
Affected system Features: maintainability and coding quality
Sign:
Solve:
A good software design approach will save your life. I often mention XP; The following resource contains one such link (resources). You'll find that XP covers a lot of detail.
Note:
I didn't go through JUnit unit tests and the experience of not using ant deployments--two free tools that would strengthen the XP approach. See also: Resources.
Crisis 9: Use framework failure
Project phase: Developing
Project phases involved: development process, stable performance, lifetime
Affected system Features: maintainability, scalability, and coding quality
Sign:
The following tasks require the developer to work on a large number of occasions, and should be the primary task of using the framework:
Solve:
I firmly believe in the use of lightweight frameworks in heavy applications. In fact, my first article in Javaworld, "Frameworks Save the day", discussed the use of frameworks in an enterprise development environment. If you are already developing, using the framework right now will still yield significant benefits. You will experience the pain of a new job, like logging and abnormal capture, but in the long run you will save a lot of time and money.
Note:
When you use frameworks and component-oriented programming, consider different levels of reuse. In the first layer, remodeling (plumbing) uses 0.9 or higher reuse factors (reuse factor), which means that 90% of the project will use it. The more special The service, the lower the reuse factor. Yes, I might set up an account service to manage the use of resources, I hope 50% of the project to use it. But for the projects that need it--the boys who make the development will be glad it's there!
Crisis 10: Project planning and design based on market advertising, not technical reality
Note:
The crisis 10 did not appear in my list until I realized there were a lot of people and not just me a misunderstanding of enterprise Java, especially those new areas.
Project phase:
All project stages, especially supplier selection is more obvious.
The project phase affected by:
All stages
Project characteristics affected by:
maintainability, scalability, design quality, code quality
Sign:
Solve:
Don't trust anyone with a vested interest outside your project. This is said: Do not trust suppliers (unless you already know them), do not trust the vendor to provide the White paper. If you want some real application server suggestions, check the previous links: resources. Further, download the tools you want to evaluate, roll up your sleeves and design prototypes. Run by the example provided (any good provider has an example).
In short, it takes time to choose the right vendor and toolset, even though your time may not be sufficient. Focus your choices on 3-4, and then try each one. Spend a week validating your application server, IDE, deployment process, and so on, until you can meet your development plan with these tools.
Note:
If you are unfamiliar with Java EE, you will be hit hard at the beginning of the project. The decisions made at the outset will have a huge impact on the success of the project as a whole. A good Java EE advisor may want to make a significant supplier selection process and bring you into the design and development state.
Only these 10 crises?
10 is only an arbitrary number, just as a breakpoint-there are countless other crises. Indeed, I still know one more crisis than this. Even so, if you guard against what is listed here, I guarantee that your project will be perfect and successful.
If you only draw one thing from this article, my advice is: there is nothing to replace experience and planning [There is no substitute for experience and planning]. If you have no experience, then you go and try and get it. In the course of the project, do not bet on your work and your team's training at the start of the project. Before the development of some coding, better to do before the design coding. Bring your Java and EE teams to experienced people to make sure that the direction of the project and the less experienced members of your team can grow along this path.
In the end, the more I write, the more I know what I want to say:
Alas, I do not have so much room, the next article will come out soon. No matter what, good luck!
Conclusion
All right, that's all. The 10 crises that affect each other are the cause of most, if not all, of the problems you will face or have faced in enterprise Java development. Naturally, there are many problems in your journey, but I believe I have revealed the main reason. In retrospect, these 10 crises are divided by importance:
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
