Programmer's tips for developing large applications _php tutorials

If you are a Java developer, you are developing and maintaining applications that contain 2000 of classes and use many frameworks. How do you understand the code? In a typical Java Enterprise Project team, most of the engineers who can help you look busy and have very few documents. You need to deliver results as quickly as possible and prove your ability to the project team. How would you deal with this situation? This article provides some suggestions for Java developers who are starting to develop new projects.

1. Don't try to understand the whole project at once

Think about it, why would you want to understand the project code first? In most cases, someone is asking you to fix a bug or to enhance the system's functionality. The first thing you need to do is not to understand the architecture of the whole project. Doing this (understanding the entire project architecture) can be stressful for you when maintaining the project.

Even Java developers with 10 years of programming experience do not understand the core work of the project, although they may have been working on the project for more than a year (assuming they are not the original developers). For example, the authentication mechanism or the transaction management mechanism still lacks the exact understanding.

How did they do it? They are well aware of the parts they are responsible for and are able to deliver value to the group. The daily delivery value is much more important than knowing something that is not yet certain.

2. Focus on delivering value as quickly as possible

So do I want to dispel your enthusiasm for understanding the project architecture? Not at all. I'm just asking you to deliver value as soon as possible, and once you start a project and build a development environment, you shouldn't spend one or two weeks delivering content, regardless of its size. If you are an experienced programmer and have no deliveries for two weeks, how does your manager know that you are really working or watching the news?

So delivery can make things easier. Don't assume that you have to understand the whole project before you make a worthwhile delivery. This is completely wrong. Adding a piece of JavaScript validation code is valuable to the business, and the manager is able to trust you more through your delivery. This will prove your contribution and the value of your employees to your superiors.

Day after day, after fixing bugs and enhancements, you can slowly start to understand the project architecture. Don't underestimate the time it takes to understand the system in all its aspects. Take 3-4 days to understand the authentication mechanism and 2-3 days to understand transaction management. These are all based on previous experiences of similar projects, but the key is to take time to get a thorough understanding. To squeeze time out of your daily routine, don't ask the manager for a specific time to do this.

Find out if the project has some unit test cases that are effectively maintained. Effective unit test cases are a good way to understand large project code. Unit tests can help you understand code snippets, including the external interface of a unit (how cells are called and what is returned) and their internal implementations (debugging unit tests are much simpler than debugging the entire actual use case).

If you can understand some of the content well, write some notes, or draw class diagrams, time series diagrams, data model diagrams, and so on, so that you or other developers in the future can maintain them.

3. Skills necessary to maintain a large project

You can work in the current job and must already have good Java technology. Let's talk about other skills that will allow you to perform well in your new project. Most of the time, your task in the project is to fix bugs and enhance features.

There are two important skills that can help you maintain a large project code.

3.1 can quickly discover the required classes

In any maintenance activity, whether fixing bugs or enhancements, the first thing to do is identify the classes that are called in the current fix or enhanced use case. When you locate a class/method that needs to be repaired or enhanced, half of it is finished.

3.2 ability to analyze the impact of changes

When you are done with the necessary modifications or enhancements, it is important to make sure that your changes do not break other parts of the code. You'll use your Java technology and the understanding of other frameworks to find out what changes might be affected. The following two simple examples describe the last mentioned cases in detail:

• When the Equals () method of Class A changes, the call to save the contains () method of the list of a instances is affected. If Java knowledge is not enough, it is difficult to consider such an impact.
• In the Web project, we assume that the "user ID" is saved in the session. The newly added programmer may have added some information to the user ID to fix the bug, but did not know that it would affect the use case associated with the user ID.

Therefore, it is necessary to have an in-depth understanding of the Java language and a deep understanding of the framework that you use in your application in order to analyze the impact of a change.

When you increase your skills by two, though you are not very knowledgeable about the project, most maintenance tasks become much simpler. If you want to fix a bug, you will locate and fix the bug and make sure that the change does not break the rest of the project. If you want to enhance or add features, basically you just need to imitate the existing features and use similar designs.

Why is there a big difference in the design of "View account Summary" and "View trading history" in an online banking project? If you understand the "View account Summary" design, you can mimic the ability to develop "view trading history".

For fixing bugs and enhancements, you don't have to fully understand the work of all 2000 classes and how code-driven systems operate. With the above skills, you can quickly locate the code that needs to be modified, fix it with good Java and framework skills, make sure that the change does not break the rest of the project, and then deliver it, although you may only know a small part of the project's design.

4. Use the tool to find the required changes and the impact of the changes

To continue with the topics we deliver as soon as possible, you should look for tools as an aid, with little understanding of the project to help you deliver as quickly as possible.

4.1 tools to quickly discover what you need to change

Whether you are fixing a bug or strengthening your system, you first need to find the classes and methods that the use case calls and needs to modify. There are basically two ways to understand how use cases work, static code analysis, and run-time analysis.

The source analysis statistic scans all the code and shows the relationships between the classes. There are many tools on the market. For example: Architexa, Agilej, UModel, Poseidon and so on.

The disadvantage of all static code analysis tools is that they do not accurately represent the runtime invocation of a class or method in a use case. As a result, Java has added some features, such as a callback mechanism (callback patterns). For example, the static analysis tool cannot infer which servlet is called when the current page Submit button is clicked.

Run-time Profiling tools can show the state of classes and methods as they run in a use case. Such tools include: MaintainJ, Diver, Jsonde, Java call Tracer, and so on. These tools can capture the stack state of the runtime and generate sequence diagrams and class diagrams for use cases.

The sequence diagram shows the methods that are all called at run time for the use case. If you are fixing a bug, then this bug is probably one of those called methods.

If you are enhancing an existing feature, perhaps adding validation, modifying DAO, and so on, then you can understand the invocation process and then modify it using a sequence diagram.

If you are adding new features, you can find similar features, use sequence diagrams to understand the invocation process, and then mimic the development of new features.

Carefully select the run-time analysis tool. Too much information is a major problem with this type of tool. Select tools to provide simple information, filter out invalid information, and easily view various views.

4.2 tools to quickly discover what you need to change

If the unit tests are valid, you can run unit tests to see if the changes have broken other test cases. Unit tests that are effectively maintained and cover large enterprise applications are still relatively small. Here are some tools for that situation.

Here, there are still two techniques-static code analysis and run-time analysis-that can be used. There are many static code analysis tools available in the market. such as: Lattix, Structure101, Coverity, Nwire and IntelliJ ' s DSM.

For a changed class, the tools above identify a collection of classes that have dependencies on the class. Developers need to "guess" based on this information for use cases that might have an impact, because these tools cannot demonstrate the invocation relationship between runtime classes.

There are not many tools available on the market that can be used for runtime impact analysis, and may only be maintainj. Maintainj first captures all classes and methods that are called in the use case. When the above information is captured for all use cases, it is easy to see how changes to the class affect the use case. The precondition for Maintainj to work effectively is that all use cases of a project should be run one at a time to be able to obtain runtime dependencies.

In summary, you can still get limited help from tools to quickly and accurately analyze the impact of changes. First, perform some impact analysis as needed, and then judge the impact of the change based on your own or other senior team member reviews. You may need to use the above tools to confirm your judgment repeatedly.

5. Two advice on the above-mentioned content

5.1 Do not reduce code quality

For fast delivery, you can not understand the architecture in a holistic way, but it must not be conditional on reducing the quality of the code. Here are some of the code quality issues you might be raising because you're only considering quick delivery.

Because modifying the code involves a lot of dependencies, the new code is relatively risky. For example, there are five use cases that call a method. To improve a use case, you need to modify the implementation of this method. The simplest way to do this is to copy the method, rename it, and then invoke the new method in the improved use case. Don't do this. Code redundancy is definitely very harmful. It's a good way to try wrapping or rewriting a method, even modifying it, and then re-testing all the use cases, usually stopping to think about it and then implementing it yourself.

Another example is to change the "private" method to "public" so that other classes can also be called. Try not to expose the non-essential parts. If refactoring is needed for better design, then you should start doing it.

Most applications have a defined structure and pattern to implement. When you repair or enhance a program, you make sure that you do not deviate from this pattern. If you are unsure of the statute, ask other senior developers to review your changes. If you have to do something that violates the statute, try to place it in a smaller class (a private function in a class of 200 lines of code should not affect the overall design of the application)

5.2 Don't stop in-depth understanding of project architecture

By the way the article is listed, assuming that you are able to deliver with less knowledge of the project and continue to do so, you may end up with an in-depth understanding of the project architecture. This is not helping your career in the long run. When your experience increases, you take on larger module tasks. such as building a complete new feature, or modifying some of the project's basic design and other major improvements. When you are able to make these improvements, you should have a good understanding of the overall architecture of the project. The method listed here only allows you to elevate yourself in the shortest possible time, rather than preventing you from fully understanding the whole project.

6. Conclusion

The whole article focuses on understanding the project and then delivering it quickly. You can do this without compromising the quality of your code.

If you want to fix the bug, locate and fix it quickly. You can use the run-time profiling tools when necessary. If you want to add features, you can look for similar features, understand the process (using the tool when necessary), and write it.

Maybe it sounds simple, but is it practical? Of course. The premise is that you have good Java technology and enough knowledge of the framework before you can modify the code and then analyze the impact of the change. It is more tricky to analyze the impact of changes than to implement change. You may need advanced developers to help you analyze the impact of changes.

There are about 50% of it operational budgets for simple bug fixes and enhancements. The recommendations in this paper should be helpful for saving money in maintenance activities.

Articles you may be interested in

• A classic dialogue between programmers and testers. These are the foreign programmers to share, said the global general?
• SEO issues that programmers should pay attention to when doing web site development
• Why there is always an error in the time the programmer estimates and when the project actually finishes
• Eight classic tricks for Linux OS applications
• PHP Programmer's question--common basic questions (1)
• JS Address bar effect (displays the size of all linked images within the page and the height of the current browser)
• PHP Programmer's Shift: now resigned in selling fruit
• The principle of exchanging friend chain with PHP Programmer's note-taking website

http://www.bkjia.com/PHPjc/764174.html www.bkjia.com true http://www.bkjia.com/PHPjc/764174.html techarticle If you are a Java developer, you are developing and maintaining applications that contain 2000 of classes and use many frameworks. How do you understand the code? In a typical Java Enterprise Project team ...

