Java-EE project crisis "translation"-avoid these 10 EE crisis to ensure your business success

Source: Internet
Author: User
Tags date exception handling garbage collection implement interface stack trace thread

J2ee| Project

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:

    • The name of the crisis
    • Project phase: The project phase of the crisis
    • Implicated in the project phase (Project phase (s) affected): In most cases, these crises have an incidentally (knock-on) impact on the subsequent "Project phase"
    • Solutions: Ways to avoid crises and how to minimize their impact
    • Comments: I would like to disclose the views of the crisis, but not suitable for the previous classification

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:

    • Supplier selection: Before you start the Java EE Project, the process of selecting your best combination of tools-whether it's an application server or a coffee brand
    • Design: Whether it's a strict waterfall model or a "code it and see" (Try translating as: coding and running view), I have this view of design: I have done a full design, so I can easily enter the development phase. When I knew exactly what I was building and how to build it, I thought my design phase was complete. Also, before I go into the development phase, I use a design template to make sure I ask all the right questions for myself and have a suggested solution. However, I am also not afraid to write code at this stage; sometimes this is the only way to answer the question, execute and modularize (performance or modularity).
    • Development: There is a lot of work to be done early in this phase. Choosing a good tool plus a good design does not always mean that the development phase will be very smooth, but it will be useful.
    • Stability/Load testing: At this stage, system architects and project administrators will focus on system robustness and build quality, such as ensuring critical statistics for the system-concurrent user numbers, failed scenarios, and so on. However, until this stage, code quality and operation should not be ignored. In fact, you can't leave some bad or slow code to the robustness phase to change.
    • Existence phase [live]: This is not a real project phase, it's a date set in stone (think for a long time also do not know how to translate:-{) This is about the stage of preparation, but also the previous error of the ghosts haunt the place, whether the poor design, Development is still the wrong (development tool) seller's choice.

    • Supplier selection: Before you start the Java EE Project, the process of selecting your best combination of tools-whether it's an application server or a coffee brand
    • Design: Whether it's a strict waterfall model or a "code it and see" (Try translating as: coding and running view), I have this view of design: I have done a full design, so I can easily enter the development phase. When I knew exactly what I was building and how to build it, I thought my design phase was complete. Also, before I go into the development phase, I use a design template to make sure I ask all the right questions for myself and have a suggested solution. However, I am also not afraid to write code at this stage; sometimes this is the only way to answer the question, execute and modularize (performance or modularity).
    • Development: There is a lot of work to be done early in this phase. Choosing a good tool plus a good design does not always mean that the development phase will be very smooth, but it will be useful.
    • Stability/Load testing: At this stage, system architects and project administrators will focus on system robustness and build quality, such as ensuring critical statistics for the system-concurrent user numbers, failed scenarios, and so on. However, until this stage, code quality and operation should not be ignored. In fact, you can't leave some bad or slow code to the robustness phase to change.
    • Existence phase [live]: This is not a real project phase, it's a date set in stone (think for a long time also do not know how to translate:-{) This is about the stage of preparation, but also the previous error of the ghosts haunt the place, whether the poor design, Development is still the wrong (development tool) seller's choice.

    • Supplier selection: Before you start the Java EE Project, the process of selecting your best combination of tools-whether it's an application server or a coffee brand
    • Design: Whether it's a strict waterfall model or a "code it and see" (Try translating as: coding and running view), I have this view of design: I have done a full design, so I can easily enter the development phase. When I knew exactly what I was building and how to build it, I thought my design phase was complete. Also, before I go into the development phase, I use a design template to make sure I ask all the right questions for myself and have a suggested solution. However, I am also not afraid to write code at this stage; sometimes this is the only way to answer the question, execute and modularize (performance or modularity).
    • Development: There is a lot of work to be done early in this phase. Choosing a good tool plus a good design does not always mean that the development phase will be very smooth, but it will be useful.
    • Stability/Load testing: At this stage, system architects and project administrators will focus on system robustness and build quality, such as ensuring critical statistics for the system-concurrent user numbers, failed scenarios, and so on. However, until this stage, code quality and operation should not be ignored. In fact, you can't leave some bad or slow code to the robustness phase to change.
    • Existence phase [live]: This is not a real project phase, it's a date set in stone (think for a long time also do not know how to translate:-{) This is about the stage of preparation, but also the previous error of the ghosts haunt the place, whether the poor design, Development is still the wrong (development tool) seller's choice.

    • Supplier selection: Before you start the Java EE Project, the process of selecting your best combination of tools-whether it's an application server or a coffee brand
    • Design: Whether it's a strict waterfall model or a "code it and see" (Try translating as: coding and running view), I have this view of design: I have done a full design, so I can easily enter the development phase. When I knew exactly what I was building and how to build it, I thought my design phase was complete. Also, before I go into the development phase, I use a design template to make sure I ask all the right questions for myself and have a suggested solution. However, I am also not afraid to write code at this stage; sometimes this is the only way to answer the question, execute and modularize (performance or modularity).
    • Development: There is a lot of work to be done early in this phase. Choosing a good tool plus a good design does not always mean that the development phase will be very smooth, but it will be useful.
    • Stability/Load testing: At this stage, system architects and project administrators will focus on system robustness and build quality, such as ensuring critical statistics for the system-concurrent user numbers, failed scenarios, and so on. However, until this stage, code quality and operation should not be ignored. In fact, you can't leave some bad or slow code to the robustness phase to change.
    • Existence phase [live]: This is not a real project phase, it's a date set in stone (think for a long time also do not know how to translate:-{) This is about the stage of preparation, but also the previous error of the ghosts haunt the place, whether the poor design, Development is still the wrong (development tool) seller's choice.

    • Supplier selection: Before you start the Java EE Project, the process of selecting your best combination of tools-whether it's an application server or a coffee brand
    • Design: Whether it's a strict waterfall model or a "code it and see" (Try translating as: coding and running view), I have this view of design: I have done a full design, so I can easily enter the development phase. When I knew exactly what I was building and how to build it, I thought my design phase was complete. Also, before I go into the development phase, I use a design template to make sure I ask all the right questions for myself and have a suggested solution. However, I am also not afraid to write code at this stage; sometimes this is the only way to answer the question, execute and modularize (performance or modularity).
    • Development: There is a lot of work to be done early in this phase. Choosing a good tool plus a good design does not always mean that the development phase will be very smooth, but it will be useful.
    • Stability/Load testing: At this stage, system architects and project administrators will focus on system robustness and build quality, such as ensuring critical statistics for the system-concurrent user numbers, failed scenarios, and so on. However, until this stage, code quality and operation should not be ignored. In fact, you can't leave some bad or slow code to the robustness phase to change.
    • Existence phase [live]: This is not a real project phase, it's a date set in stone (think for a long time also do not know how to translate:-{) This is about the stage of preparation, but also the previous error of the ghosts haunt the place, whether the poor design, Development is still the wrong (development tool) seller's choice.

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:

    • Duplicate implementations already included in the JDK core APIs function functions and classes

 

    • I don't know what or what the following list is and what they can do (some examples are listed below)

       

      • Garbage collection (train, generational, incremental, synchronous, asynchronous)
      • When can objects be "garbage collected"-
      • Use of inherited features in Java (and its tradeoffs)
      • Method overload
      • Why Java.lang.String (replacing your favorite class here) seems to be a poor performance
      • Ignores the semantics of Java references (as opposed to the semantics of ignoring values in EJBS)
      • Use = = instead of implementing the Equals () method for a nonprimitives type ()
      • How is the progress of the Java thread on different platforms (for example, pre-emptive or not)
      • Green Thread vs Local thread
      • Hot [Hotspot] (Hotspot <and Why old performance tuning techniques negate Hotspot)
      • JIT and when good jits (not installed Java compiler and your code is still running well)
      • The collections API
      • Rmi

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:

    • EJBS is no longer in control after the first invocation (especially the stateless session BEANS in the Ready pool [ready pool])
    • Non-reused (nonreusable) EJBs
    • Developers don't know what to rely on compared to what the container provides
    • Non-compliant EJBS (fire threads, calling local libraries, attempting to complete I/O operations, etc.)

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:

    • The design of "What is EJB"
    • Manually configured rather than using a container-provided mechanism
    • Customer security Implementation of the--J2EE platform may be the most complete and complete security architecture in enterprise computing, from performance to backstage; its full capabilities are rarely used entirely

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:

    • Large Type EJBs
    • Developers can't explain what their ejbs do and how they relate to each other.
    • Non-reusable EJBS, components, or services--when they should be reused
    • EJBs starts a new transaction when a transaction that already exists can complete a task
    • Data independence set too high (for security purposes)

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:

    • A large and clumsy JSPs
    • When the business logic changes, you find that you need to edit the JSP file
    • Show changes in requirements force you to edit and redeploy ejbs and backend components

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:

    • Migration to a real application system for days and 1 weeks
    • The risks associated with the runtime are inherent, accompanied by a number of not-tested uncertainties and major episodes
    • Data in the Run-time system is not the same as for development and stabilization periods
    • Unable to run build on the developer machine [builds]
    • The application of the behavior in the development environment, stable environment, product environment is inconsistent

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:

    • Data validation rules
    • System behavior that has been tested
    • Contracts between system components (especially between EJB-EJB and Ejb-db)

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:

    • Developers spend a lot of time and tools "Wrestling" [wrestling] instead of using them effectively
    • In the process of implementation, important systems need to be redesigned to avoid bugs that are known or unknown.
    • Integration of differences between tools (application servers and ide,ide and debugging tools, source control and construction tools, etc.)
    • For the IDE, the debugger, and so on, the developer simply chooses or abandons his or her personal preferences.

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:

    • Development time is 33% longer than the worst estimate time
    • Developers reinvent the wheel when the supplier or implementation provides more functionality than the "circle" [the author uses box to understand the translator]. [Developers reinvent the wheel when the vendor or implementation provides the required-out of the box]

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?

    1. The configuration management style of BEA WebLogic is very different from IBM WebSphere.
    2. IBM has a full GUI environment for WebSphere, and BEA provides full command-line control tools for WebLogic.
    3. IBM WebSphere for programmers to use IIOP to communicate and throw CORBA visible exceptions, WebLogic There is no CORBA layer, by default, T3 protocol.

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:

    • Slow and unacceptable system
    • System of excessive utilization of service-side state and inability to fully utilize supplier cluster technology

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:

    • A project plan is like a suspicious waterfall model: "First, we do the overall design, and then we sit down and spend a lot of time coding." ”
    • Deployment has become a nightmare because the deployment process does not exist.
    • The number of days deployed is equal to the number of development days spent, because nothing has been done.
    • Components are not fully tested during consolidation. In fact, overall testing means tying two of unstable components together and looking at their stacks.

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:

    • Bugs in the core library are reused in your code
    • No logging standard is set-so the system's output is unreadable or cannot be converted to scripts
    • Poor or uncoordinated exception handling. On some sites I see that end users are exposed to some low-level errors, such as a sqlexception stack trace when a user tries to checkout a shopping cart. What do users do next? Call the database Administrator and force report this error?

The following tasks require the developer to work on a large number of occasions, and should be the primary task of using the framework:

    • Record log
    • Exception handling
    • Get links to related resources (database, name service, etc.)
    • Create a JSP page
    • Data validation

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:

    • Technical decisions take on a very light weight, as EJBS are designed to be lightweight
    • Supplier selection for the test of whether the product is portable or not
    • Need to select tools during Project lifetime

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:

    • Social aspects of software engineering
    • Unit Test and overall test (when is the test completed?) )
    • Design Patterns
    • Exception capture

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:

    1. No understanding of Java, no understanding of EJB, no understanding of EE
    2. Overly designed (whether for EJB or not)
    3. No separation of presentation logic and business logic
    4. Not deployed in your area of development
    5. Select the wrong (development tools) provider
    6. I don't know your supplier.
    7. Not designed for measurable or executable
    8. The old development process
    9. Failed to use frame
    10. Project planning and design based on market advertising rather than technical reality



Related Article

Contact Us

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.

Tags Index: