J2ee| project in the past period, I have worked as a programmer, senior designer and architect, and have seen excellent enterprise-class Java projects, and have seen bad, even ugly, projects. Sometimes I ask myself, why can one project succeed and the other fail? It is difficult to define a rule or standard to show how the different projects should be successful, and the Java project is no exception. On the contrary, we can look at the reasons for the failure of the project from all angles and levels, and if the risk is well avoided, the project can succeed. In this article, I will present the top 10-bit Enterprise Java Project risk for readers ' reference.
In a variety of risks, some risks only delay the progress of the project, some bring some unnecessary work, while others will completely eliminate the possibility of success. However, if there is sufficient preparation and sober understanding beforehand, then there is no inevitable thing. It's like if you're a traveler, you know exactly where the road ahead is, you're ready, and there's a guide who knows where the danger is, so you can get to your destination more smoothly.
This article uses the following structure to describe the risk:
Risk Name: The title of the risk (using bold)
Project phase: at which project stage risk occurs
Impact Stage: Which phases will affect later
Symptoms: Symptoms when risk arises
Avoidance scheme: How to avoid risk or minimize its impact on the project
NOTES: Risk-related supplemental notes and hints
Through careful inspection of enterprise-class Java projects, this article will decompose the process into the following phases:
Provider selection: Before starting your Java EE project, select the most appropriate provider, from the application server to the development tool portfolio, to the manufacturer of the coffee you enjoy at work.
Design: In line with a series of strict specifications and software engineering methods, you can start a sufficient design, and then naturally into the development phase. Before you develop, think carefully about what you're doing and how to do it. In addition, I used some design templates to make sure that all the problems and possible solutions were thought up before I went into development. However, I sometimes do some coding at this stage, sometimes it can answer some questions and effectively judge the problem of performance and module partitioning.
Development: That is, the process development phase, choose some good development tools, excellent design, etc., in this stage will show its advantages, and can bring great help to development.
Stability/Load testing: At this stage, system architects and project managers should freeze product features and focus on quality as well as product parameters (number of concurrent users allowed, failure recovery, and so on). Quality and performance should be given sufficient attention at this stage. Of course, it's a good idea to avoid writing bad, slow-running code in the first phase and making a lot of changes at this stage.
Maturity: This is not a real project phase, but a fixed stage of preparation. Past-lurking errors (from poor design and development, faulty vendor selection) can appear and affect your system.
Risk 1: No real understanding of Java, EJB, and EE
This problem can be broken down into 3 parts to facilitate analysis.
Description: No real understanding of Java
Project phase: Developing
Impact Stage: Design, stability testing, maturity
Impact on system performance: maintainability, scalability, performance
Symptoms:
Repeated development of features or classes in the JDK core API
Not knowing some of the items in the following list (this is just a few topics or practical examples):
Garbage collectors (train, generational, incremental, synchronous, asynchronous)
When the object can be garbage collected--dangling references
The inheritance mechanism used and its trade-offs
Over-riding and Over-loading methods
Why Java.lang.String (in place of the class you prefer) offers poor performance
Comparison of semantics between pass-by reference semantics in Java and pass-by values in EJB
Use = = or use the Equals () method for Nonprimitives
How the Java threads run sequentially on different platforms (for example, whether they are preemptive)
Comparison of new and local threads
Hotspot Technology (and why the old performance tuning technology reduces the hotspot optimization effect)
JIT, and when good JIT becomes bad (not installed Java compiler, and your code is running just good enough)
API Collection
Rmi
Avoidance scheme:
You need to constantly improve your knowledge of Java, especially with a deep understanding of the strengths and weaknesses of Java. The value of Java is much more than a language, and understanding the platform (JDK and tools, etc.) is equally important. Specifically, you should be a certified Java programmer, and if you're not, you may sometimes be amazed at the amount of content you don't know. In addition, you can join the Java mailing list. Every company I've ever been to has joined the mailing list and learned the technology from peers, which will be your best resource.
Note:
If you or a member of your team don't really understand the programming language and platform, how can you keep the promise of success? Stronger Java programmers are to EJB and EE, just as ducks are to water. By contrast, weaker, inexperienced programmers can only develop poor-quality Java-EE applications.
Description: No real understanding of EJB
Project phase:
Design
Impact phase:
Development, stabilization
Impact on the system:
Maintenance
Symptoms:
The EJB was not used after the first invocation (especially the stateless session bean)
EJB with no reuse value
Do not understand what the developer wants to do, what the container provides
EJB is not defined according to specification (fire thread, loading local library, trying to perform I/O, etc.)
Solution:
To improve your knowledge of EJBS, you can find a weekend to read the EJB specification (1.1 has 314 pages), and then read the 2.0 specification (524 pages!) so that you can learn what 1.1 does not define and what is added to the 2.0 specification. It is appropriate for the EJB developer to start reading from chapters 18.1 and 18.2.
Note:
Instead of looking at the EJB from a provider's perspective, be sure to know the difference between the standard EJB models supported by the specification and the special applications based on those models. This will also help you migrate to other providers.
Description: No real understanding of Java EE
Project phase:
Design
Impact phase:
Development
Impact on the system:
Maintenance, scalability, performance
Symptoms:
How to Design "Everything is an EJB"
Replace container-provided mechanism with manual transaction management
The security processing of the custom way--the Java-EE platform has the most complete integrated security architecture in enterprise computing, from presentation logic to background processing, but rarely uses all of its functions.
Solution:
Learn the key components of Java EE, and understand their strengths and weaknesses, and use them in turn to replace each service; "Knowledge is power" is effective here.
Note:
Only knowledge can remedy these problems. A good Java developer will become a good EJB developer, and it should be a great master of EE since then. The more Java and EE knowledge is mastered, the better the design and development work will be. In the design phase everything will be orderly.
Risk 2: Over-design (over-engineering) (EJB or EJB not used)
Project phase:
Design
Impact of the project phase:
Development
Impact on the system:
Maintenance, scalability, performance
Symptoms:
An overly large EJB
Developers can't explain what EJB does, and the connection between them
EJB, component, or service that cannot be reused
The EJB started a new transaction that was supposed to be started by an existing EJB
For security, the data separation level is set too high
Solution:
The solution to the problem of over engineering comes directly from the Extreme Programming (XP) approach: to meet demand with minimal design and programming, nothing else. Unless you need to be clear about future requirements, such as future load requirements, or the performance of the system under the maximum load, you don't have to do too much thinking or guessing about the future of the system. In addition, the Java EE platform has defined scalability and error recovery features, you can let the server system for you to deal with.
In the smallest system, contains only a small set of components, these components do only one thing, as long as the implementation of these requirements, system stability has been improved, and your system maintainability will become very strong, in the future to add functionality to meet new requirements will become easier.
Note:
In addition to the programs listed above, design patterns can be implemented-they can significantly improve your system design. The EJB model itself is also widely used in design patterns. For example, the home interface with each EJB is an instance of the Finder and factory patterns. The remote interface of EJBS acts as a proxy for actual bean implementations and is critical to the ability to provide containers that intercept call signals and provide services such as transparent (transparent) load balancing. Ignoring design patterns is also part of the danger.
Another danger I often mention to oppose is that EJB is used only for EJB use. Some part of your application may not require EJBS, even your entire application. This is the extreme of being overly engineered, and I did see some good servlet and JavaBean apps being refactored into EJBs, and there's no good technical justification for that.
Risk 3: No separation of business rules from logical representations
Project phase:
Design
Impact of the project phase:
Development
Impact on the system:
Maintenance, scalability, performance
Symptoms:
Too large, no marginal JSP program
You must modify the JSP when the business logic changes
Need to modify and reconfigure EJB and other backend components when required to change the display of the interface
Avoidance scheme:
The Java EE platform gives you the opportunity to separate the presentation logic from the navigation control and then separate from the business rules. This is called Mode 2 structure.
Note:
You can use a consistent design to connect to the user interface framework. (For example, you can use Taglib), which will help you avoid the problem of logical separation. There are many good methods available to choose from. Evaluate each one separately, then use the most appropriate framework.
Risk 4: Not properly configured in the development environment
Project phase:
Development
Impact of the project phase:
stabilization, concurrency, maturity
Impact on the system:
Your balance.
Symptoms:
Transition to mature systems over days or weeks
Risk existence and transition period, with a lot of uncertainty, some major functional scenarios have not been tested to
The data in the actual system is different from the data in development and test
Unable to build on the developer machine
Application behavior is different in development, stabilization and product environment
Avoidance scheme:
The solution is to faithfully configure the actual environment in the development environment so that the environment for development is close to the environment in which the product is to be implemented. If the future environment is JDK 1.2.2 and Solaris 7, do not develop on JDK 1.3 and Red Hat Linux. The same is true for the application servers used. Again, take a quick look at the data in the product database and use such data for testing. Do not rely on data that is created manually. If the product data is sensitive, make it insensitive, and then configure it. Product data that is not expected in development will cause damage to the following processes:
Data validation rules
System test Behavior
System component Building (specifically including: EJB-EJB and ejb-databases)
Worst of all, it can also produce exceptions, null pointers, and problems you've never seen before.
Note:
Developers often put security issues into the stabilization phase before they begin to solve them. To prevent such traps from being created, you can also spend the same amount of time improving security in your business logic.
Maturity is a complex process, full of technical and non-technical problems. You may be caught up in a lot of unexpected problems, which is what maturity means. The development and stabilization of the environmental process provides you with the problems of creating more of these issues and finding such problems, and constantly doing so can greatly reduce the risk.
The more work you do, the more you will be able to understand what is feasible and what is not. You can keep track of engineering problems to avoid repetition of the same mistakes.
Impact on the system:
Scalability, performance, maintainability, and stability
Symptoms:
Developers need to spend more time dealing with tool issues rather than using these tools productively
Significant system redesign is necessary to cope with known and unknown problems
It is difficult to integrate between different tools (application server and IDE tools, IDE tools and debuggers, source control and compositing tools, etc.)
For IDE tools and debuggers, developers tend to reject them, while advocating the tools they like
Avoidance scheme:
In order to avoid the risk of 5, you need a good provider selection process, risk 10 evasion also applies to this.
The most appropriate way to really measure an IDE tool is to really use it. The only way to evaluate a Java EE application is to set up a concept test to prove it and include your application framework in the experiment. In fact, you don't want to spend 3 months training and development, and then find bugs when you use them.
Let's say that when you're halfway through, you suddenly find that your toolset is problematic, and you should have known that some tools are really more important than others. If your chosen application server does not fully meet your needs, you will have to modify the original settings. If the IDE is not good, you need to set minimum code standards and allow developers to arbitrarily select the tools they think are most effective.
Note:
It's not a one-time decision to really know which supplier is the most appropriate for a particular task. You need to keep track of and evaluate the market. For example, over the past year I have used 4 different IDE tools, depending on what application server, platform, EJB, etc. i use.
Risk 6: Don't know your provider
Project phase:
Provider Selection
Impact phase:
All stages following the provider selection phase: design, development, stabilization/load testing, maturity
Impact on the system:
maintainability, scalability, performance
Symptoms:
The period of development is more than 1/3 of the worst forecast period
The provider has provided a feature, but the developer has restarted the functionality without knowing it
Avoidance scheme:
To avoid this risk, you can subscribe to the provider's online resources as much as possible, such as mailing lists, newsgroups, version information (especially the description of bug fixes in them, etc.), and you can get immeasurable gains from it.
Once you have selected a provider, invest in the training immediately and as soon as possible before the project starts. Then, gradually build up the knowledge and trust of this provider in the team. Try to build a few ejbs and deploy them, and then use your presentation layer technology (Swing GUI, JSP, etc.) to invoke them. If you have to build a development environment and also achieve the project goals, there will be some unnecessary conflicts. In fact, I've seen a situation where the build process has not been done: "We don't have time." "Therefore, these efforts must be carried out earlier." Some people will say: "Our plan does not provide us with these times." "My answer is:" Your plan does not give you time to make you not do so. ”
Note:
What is the technical compatibility of each provider's products in the Java-ee world? Let's take a look at IBM and Bea's specific analysis. Both support EJB 1.1, respectively, in their respective application servers. So how much similarity does BEA WebLogic 5.1 and IBM WebSphere 3.5 actually have?
The system configuration and management methods of BEA WebLogic and IBM WebSphere are almost entirely different.
IBM has a comprehensive GUI environment in WebSphere, and in contrast, BEA provides a complete set of command lines in WebLogic.
IBM WebSphere uses IIOP to communicate with CORBA exceptions, which are visible to programmers, WebLogic do not have CORBA constructs, and the T3 protocol is used by default.
WebSphere and visual age converge tightly, and WebLogic is not IDE-independent, in fact, you can almost use any development tools.
This shows that the difference is still quite a lot. If you're an expert on application servers, it doesn't mean you're an expert on all application servers. This distinction is reflected in Ide,debugger,build tools, configuration management, and so on. Experience with the use of a particular tool from a provider can be handy when evaluating a competitor's product. However, do not expect seamless transfer or convergence between different products. Therefore, you have to spend enough time in mastering these tools.
Risk 7: Scalability and product performance are not fully considered in the design
Project phase:
Design
Affected Project phase:
Development, load testing and maturity
Impact on the system:
Scalability, performance, maintainability
Symptoms:
Can't stand the slow pace
The system adds a heavy burden to the server, and cannot use some clustering techniques.
Avoidance scheme:
Focus on performance and scalability requirements and identify the performance metrics to be achieved in development. If you need 50 transactions per second, and your EJB design can provide only 40, then you need to consider alternatives, such as stored procedures, batching, or reconsider the design of OLTP.
Get your providers involved as much as possible, and they should be very clear about their strengths and weaknesses, and then give you the most direct help.
Note:
There seems to be some conflict between this risk and risk 2 (over-engineering). In fact, they affect each other. My solution to risk 2 is to build only when absolutely necessary. And for performance and scalability, you have to prioritize what you have to do.
If you realize that the system needs to be highly scalable and as a more critical requirement, you first need to select an application server with strong cluster support and transactional caching. In addition, you should design your business objects as EJBS so that you can take advantage of the server architecture. XP is no problem, you are still only doing the absolutely necessary work.
I think of this as a way of checking and balancing. All we need is the simplest possible system, which only provides the functionality and behavior that the customer needs.
Risk 8: A stale development process
Project phase:
Development
Impact phase:
Stabilized, maturing
Impact on the system:
maintainability, Code Quality
Symptoms:
The project plan seems to resemble the waterfall model: "First the design of the grass, and then in a very long cycle of development." ”
Since there is no build process, each build is like a nightmare
The date of the build is equal to the date of the loss development, because nothing is made
Before integration, components were not fully tested separately, and integration testing meant putting 2 of unstable components together and looking at the trace results on the stack.
Avoidance scheme:
A good software methodology will improve your software life cycle. I have mentioned the XP method before, you can find a lot of this information on the Internet.
Note:
JUnit can be used for unit testing, and ant tools can be compiled and built, and these 2 tools have good support for XP methods.
Impact on the system:
maintainability, scalability, quality of code
Symptoms:
Bugs are found in core libraries that have been used many times in your code.
There is no logging standard--so the output of the system is difficult to read or parse.
Bad inconsistent exception handling. In some sites, we can even see that the error message is directly exposed to the end user, such as sending a SqlException stack trace when the user is in his shopping cart, and what will the user do next? Do you want to call the database administrator to fix the primary KEY constraint?
The following tasks have been handled countless times by developers in a variety of ways, all of which need to be placed in the first target of any architectural design.
Log
Exception handling
Connection to resources (database, name service, etc.)
Building JSP Pages
Data legality check
Avoidance scheme:
I am a believer and practitioner of light methodology. My first article on Javaworld-"frameworks Save the Day"-is a discussion of architecture in the enterprise Java environment. Even if you have started developing, it is still worthwhile to consider the architecture at this point. You may have to endure the exception handling and log processing of refactoring, but it is worthwhile in the long run, which saves time and money.
Note:
Let's think about the different levels of reusability that are based on component development in the architecture. The first level is plumbing, with a reusable ratio of more than 0.9, that is, 90% of projects can be reused. The more detailed the service definition, the lower the reuse ratio. In other words, I need to build an accounting service, but provide the management of these resources and usage so that they can be reused in other 50% projects. But for those projects, it's great to have access to these resources.
Risk 10: Project planning and design is based on market effects and is divorced from technological reality
Note: There are always new entrants to the JAVA/EJB development field, and the number of people who don't understand Java is generally more than imagined.
Project phase:
All phases will be affected, including provider selection
Impact phase:
All phases will be affected.
Impact on the system:
maintainability, scalability, design quality, code quality
Symptoms:
Making technical decisions lightly, thinking that ejbs are just for the convenience of portable processing
The product was not tried immediately when the provider was selected
Replacement tools are also required during the life cycle of the project
Avoidance scheme:
Don't trust anyone outside the project, these people may already have some vested interests, don't trust the provider's claim (unless you already know it), and don't trust the white paper. If you want to get advice from the real world about the application server, you can get it online. You can also download these tools for evaluation, use them to make prototypes, and run the examples. (Good providers have such examples).
In general, it takes time to choose the best provider and tool for your project, and you may not have much time. You can limit your selection to 3-4 objects and then compare and test them for a week. Finally, the more satisfactory tools and products are selected from them.
Note:
If you lack the experience of Java, you may have problems in the early stages of the project. Decisions that are determined in the early stages affect the entire process and, in turn, the success of the project. Good Java EE Consulting experts will be able to help you choose a good provider, and design and development to carve a good configuration.
10 is only a specific number, and obviously, there are more and more risks. Just what I can guarantee is that if you overcome all the risks listed, your project will have a good performance and the foundation for success.
Another thing to note is that there is nothing to replace experience and planning. If you have no experience, then you must find a way to get and accumulate. Do not train while doing the project. Be prepared well in advance prior to development, preferably before design. It allows your team to accept the guidance of the JAVA/J2EE advisor and ensure that such guidance can be delivered to the entire team of other members.
Finally, it is necessary to mention the following points:
External impact of software engineering
When do unit tests and when are integration tests performed?
Design Patterns
Exception handling
Conclusion
Overall, the above 10 major risks are the major challenges you will face in the development of enterprise-class Java projects. I also believe that there must be more pitfalls in your journey, but I am more certain that the risks I have mentioned cover the main issues. And finally, let's recount the top 10 risks by Priority:
Don't really understand Java, don't really understand EJB, don't really understand EE
Over Design (over-engineering)
No separation of business rules from logical representations
Not properly configured in the development environment
The wrong provider was selected
I don't know your provider.
Scalability and product performance are not fully considered in the design
The old development process
No good architectural approach
Project planning and design is based on market effect and is divorced from the technical reality
Finally, let me wish you good luck!
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
