The methodology in JSP project design

js| Design | Project Author: luck
Email:webmaster@chinaspx.com

In designing JSP projects, the current methodology provides more restrictions than help. According to Casey Kochmer, the key to running a JSP project successfully is project management rather than design
。

Contrary to the general idea, the best design methodology is not the formal approach when running a project. Most design methodologies are bloated and impractical. If a design method requires a 200-page manual, it can only show that it is too complicated in practical use. I think the nature of the design method should be simple and holistic. In fact, for a successful design method, the most critical thing is even the design-related things, but the project management strategy. If you don't manage properly, you may fail even if you have the best design. The most important point in the design approach is the need to provide a simple framework that embraces the wide range of conflicts and contradictions in any successful design.

In the following guidelines, we will explain this issue and describe the most basic principles of composition in project management.

Project Management principles

There are several major factors that can cause the project to fail. We list the top 10 and include a simple explanation of each factor.
The project is too inflexible to make the necessary changes according to the user's needs.
The project has no principles and is often changed as a result of the user's will and cannot be completed within a reasonable time.
Lack of communication or poor communication between programmers and customers.
Have unrealistic expectations of goals.
The timetable is unrealistic.
The project is too large to manage successfully.
No tests or too many tests.
Use the wrong tool.
The technology used in the project is too advanced for the project and the user, ahead.
Projects are conducted without respect for project members.
Most of the following principles are proposed to address these issues. Of course, each project has its own balance point. Therefore, each project manager and the main programmer should be adjusted according to the internal characteristics of their own projects.

In the project design process, users must be allowed to propose changes to the design requirements. But at the same time a project must have a certain "rigidity", to make the design changes as little as possible. Balancing this contradiction requires very good design art, and the balance points of each project are different.
In the course of the project, the team needs to communicate directly with the customer, at least to ensure the minimum project review and problem clarification/analysis process.
The time of a project is not more than one year, to 6-9 months for the best. Any larger and longer items are best cut into small subprojects.
The project manager and the programming director must be two different people. The combination of two characters makes a person's burden too large, and two roles are not good.
The number of a project should not exceed 7, with 5 as the best.
A project team is best able to mix senior and young developers
I've found that if a development team is full of senior developers, the team can easily get bogged down in stale and habitual situations. A team of completely young developers has a clear lack of experience. Young beginners may often ask why this is the case, as younger members of the team can eliminate the inertia of older senior staff. Such problems often lead to good improvements. At the same time, senior developers can train novices to regularly check their designs, which can also lead to improvements. 7. The tools used by the project must be easy to use and control for project members, or those who can provide assistance in this regard must be easily found.
In the beginning, we should set a realistic timetable. If the timetable is found to be unreasonable after the start, adjust the person or schedule as quickly as possible. The mistake of most projects is to simply increase resources to speed up progress. This is usually wrong. If it is unreasonable to find a timetable, most of its errors are more than just lack of resources. Check the schedule and also check the project objectives, methods and options. Make sure you work under reliable conditions and information. After completing this review, readjust the project to your own ideas.
The major participants in the project must feel comfortable, free to ask questions and communicate freely. Projects that lack effective communication often fail quickly. The first sign of a problem is usually a problem when exchanging information. Silence is not a sign of a project to be completed, but rather a statement that your members are working in a real air that is not communicating.
All members of the project team are aware of these principles in order to keep the project situation under regular review. If a project does not conform to these principles, then all members have an obligation to find out the problem as soon as possible. I often make mistakes in my projects, but I try to find them quickly. When the problem is discovered before the outbreak, or when it is discovered at the initial stage of the project, the usual solution to the problem is simple. However, ignoring these problems often leads to more serious problems that cause the project to fail. If there are projects that do not embody these principles, I will not accept such projects.
These principles are some of the basic points I've summed up for the success of the project. My personal experience tells me that ignoring any of these principles is likely to lead to serious results.

Design principles

Although the principle of excessive rigidity in design is harmful, we still propose some basic principles that we can follow.

Avoid becoming a group that uses new technologies. Be sure to wait until the technology and product support information is ripe for consideration. But how can you tell if a technology is mature enough? Look at the richness and depth of support information on the Internet. A new tool that is only good when you can easily find the help information.
If you have to use newer techniques, remember that you have to be prepared for a backup plan to use when problems arise in the implementation of new technologies. My feeling is that the new technology has about 50% chance of going wrong at the key point of your project. Preparing a back-up plan from the start will prevent future problems from widening. When using new technology, be sure to use it early in the project to gain more time to evaluate its feasibility.
Ensure that the technical level of the user can use a variety of technology in your project, for example, if the user is using a 3.x version of the browser, you do not use the client's xml/xsl. Of course, you can still use server-side xml/xsl, because users will not be affected.
To meet the minimum requirements, this can prevent the project from becoming bloated, while speeding up the process and making it easier to test. And users should only ask for the functionality they really need.
In coding, the main goal is to make maintainable code, and the second goal is to make reusable code. With Java, object-oriented is the most important tool for us to achieve success. But do not rely entirely on object-oriented technology, with the simplest templates, function libraries or good design methods can also be good for the reuse of code. Object oriented is just one of the many techniques we can choose to program.
Testing and probation are important parts of success. The trial is a very important part and must be given sufficient time to have the opportunity to correct the errors found.
After the main project is completed, a small second phase can be given in which the project can be modified in a part that is not complete enough to meet the expected level.
Think about the concept of multiple projects. A project team often has to deal with multiple projects. Project personnel in different projects, to constantly change their responsibilities, on the one hand, as for the future use of personnel added back-up. And because every project team member keeps doing new things, it also reduces the likelihood of burnout (which means your project team can remain relatively stable for a long time).
Plan ahead to make it possible for multiple people to continue to process a piece of code. To do this, I reuse code between different projects. In fact, we do more than just code reuse. In each project, there may be a new person using an existing part of the code. New people may continue to modify and optimize the code. As a result, the code can continue to increase efficiency, while there are few opportunities for problems. The efficiency of the code can be improved, and the document can be improved continuously. Not only the code itself can be constantly modified, improve, with the advent of new technologies, code can continue to apply new technology, and thus improved.
If possible, use open source as much as possible
Turn JSP's distributed environment into your advantage. Use client script to leverage client capabilities. Truly relies on the database's stored processes to save data-processing logic centrally. Use the Java server to generate XML and XSL data templates to produce HTML output. Avoiding the concentration of processing in a single point and distributing the processing work is the most effective way to accomplish the job.
Avoid putting too much logic into a single JSP page. The more things you do with a JSP page, the greater the impact when you need to upgrade or modify the project. Try to make each JSP page complete only one of the most basic small operations. You can also use the advantages of the tag and JavaBean libraries to build reusable modules. These tools help make JSP pages easier to maintain.