Shulou(Shulou.com)06/02 Report--

This article shows you what are the suggestions for the development and maintenance of large-scale Java projects, which are concise and easy to understand, which will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Suppose you are a Java developer who is developing and maintaining 2000 classes and uses a lot of frameworks. How do you understand the code? In a typical Java enterprise project team, most of the senior engineers who can help you seem busy. There are also very few documents. You need to deliver the results as soon as possible and prove your ability to the project team. How would you deal with this situation? This article provides some advice for Java developers to start a new project.

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

Think about it, why do you understand that the project code is * bit? In most cases, you are asked to fix a bug or enhance the existing functionality of the system. The only thing you need to do is not to understand the structure of the whole project. This (understanding the entire project architecture) can put a lot of pressure on you when maintaining the project.

Even Java developers with 10 years of reliable programming experience may not understand the core workings 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, for authentication mechanisms or transaction management mechanisms.

How did they do it? They know a lot about what they are responsible for and are able to deliver value to the team. The value of daily delivery is far more important than knowing something that you are not sure about later.

2. Focus on delivering value as soon as possible

Have I denied 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 set up a development environment, you shouldn't take a week or two to deliver anything, regardless of its size. If you are an experienced programmer with no delivery for two weeks, how does your manager know if you are really working or watching the news?

So delivery can make it easier for everyone. Don't think you have to understand the whole project before you can make a valuable delivery. This is completely wrong. Adding a piece of javascript verification code is valuable to the business, and the manager can trust you through your delivery. In this way, you can prove your contribution and employee value to your superiors.

Day after day, after you keep fixing bug and enhancements, you can slowly begin to understand the project architecture. Don't underestimate the time it takes to understand all aspects of the system. It takes 3-4 days to understand the authentication machine and 2-3 days to understand the management of things. These are based on the experience of previous similar projects, but the key is to take time to understand thoroughly. Squeeze time out of your daily work and don't ask the manager for a specific time to do it.

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

If you can understand something well, write some notes, or draw some class diagrams, sequence diagrams, and data model diagrams for you or other developers to maintain in the future.

3. Skills necessary for maintaining large projects

If you can do your current job, you must already have good java technology. Let's talk about other skills that will enable you to perform well in a new project. Most of the time, your task in the project is to fix bug and enhance functionality.

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

3.1 be able to quickly find the classes you need

In any maintenance activity, whether it's fixing the bug or enhancing the functionality, the * actions are to identify the classes called in the current fixed or enhanced use case. When you locate the class / method that needs to be fixed or enhanced, it is half done.

3.2 ability to analyze the impact of changes

After you have made the necessary changes or enhancements, the most important thing is to make sure that your changes do not break the rest of the code. You need to use your java technology and your understanding of other frameworks to find out what the changes may affect. Here are two simple examples that describe the situations mentioned in * in detail:

A) when the equals () method of class A changes, it will be affected when a contains () method that protects the List of the An instance is called. If there is not enough knowledge of Java, it is difficult to consider such an impact.

B) in a web project, we assume that "user id" is saved in session. A new programmer may add some information to "user id" as a way to fix bug, but does not know that it will affect the use cases associated with "user id".

When you improve these two skills, although you don't know much about the project, most maintenance tasks become much easier. If you fix a bug, you will locate and fix the bug and make sure that the changes do not damage the rest of the project. If you enhance or add a feature, basically you only need to mimic existing features and use similar designs.

In an online banking project, why does the design of "view account summary" and "view transaction history" need to be so different? If you understand the design of "View account Summary", you can imitate the function of "View transaction History".

In terms of fixing bug and enhancements, you don't have to fully understand the work of all 2000 classes and how the code works to drive the system. If you have the above skills, you can quickly locate the parts of the code that need to be modified and fix them with good java and framework skills to ensure that the changes do not damage the rest of the project and deliver, although you may only know a small part of the design of the project.

4. Use tools to find the changes you need and the impact of the changes

To continue the theme we delivered as soon as possible, you should look for tools that can help you implement delivery as soon as possible by knowing as little as possible about the project.

4.1 quickly identify tools that need to change content

Whether it's fixing bug or system enhancements, first find the classes and methods you need to modify that use case calls. There are basically two ways to understand how a use case works, static code analysis and run-time analysis.

Source code analysis statistics scan all code and show the relationship between classes. There are many equipment and tools on the market. For example: Architexa, AgileJ, UModel, Poseidon and so on.

The disadvantage of all static code analysis tools is that they cannot accurately show the runtime calls of a class or method in a use case. So new features have been added to Java, such as the callback mechanism (callback patterns). For example, the static analysis tool cannot infer which Servlet is called when the page submit button is clicked.

The runtime analysis tool can show the state of classes and methods at use case run time. Tools include: MaintainJ, Diver,jSonde,Java Call Tracer, etc. These tools can capture the stack state of the runtime and use it as a use case to generate sequence and class diagrams.

The sequence diagram shows all the methods that are invoked by the use case at run time. If you are fixing a bug, the bug is probably one of these called methods.

If you are enhancing the existing functionality, use the sequence diagram to understand the call flow and then modify it. It may be to add a verification, modify DAO, etc.

If you are adding new features and find some similar features, use sequence diagrams to understand the call flow and then imitate the development of new features.

Choose run-time analysis tools carefully. Too much information is a major problem with such tools. Choose some tools that provide simple filtering of invalid information and make it easy to view various views.

4.2 quickly identify tools that need to change content

If the unit test is valid, you can find out whether the change has broken other test cases by running the unit test. There are relatively few unit tests that effectively maintain and cover large enterprise applications. Here are some tools for this situation.

There are still two techniques available for static code analysis and run-time analysis. There are many static code analysis tools available in the market. Such as: Lattix, Structure101, Coverity, nWire and IntelliJ's DSM.

Given a changed class, the above tools can identify a collection of classes that are dependent on the class. Developers need to "guess" the use cases that may have an impact based on this information, because these tools do not show the invocation relationships between runtime classes.

There are not many tools available for runtime impact analysis on the market, with the exception of MaintainJ. MaintainJ first captures all the classes and methods that are called in a use case. When all the above information for the use case is captured, it is easy to see the impact of class changes on the use case. The prerequisite for MaintainJ to work effectively is that all use cases of the project should be run first so that runtime dependencies can be obtained.

In short, you can still get limited help from the tools in analyzing the impact of changes quickly and accurately. First, perform some impact analysis as needed, and then judge the impact of the change based on your own review or review by other senior members of the team. You may need the tools mentioned above to repeatedly confirm your judgment.

5. Two pieces of advice on the above

5.1 do not reduce the quality of the code

In order to deliver quickly, the architecture is not fully understood, but it must not be conditional on reducing the quality of the code. Here are some code quality issues that you may have because you only think about fast delivery.

Because a lot of dependencies are involved in modifying the code, the risk of adding new code is relatively low. For example, there are five use cases that call a method. In order to improve a use case, you need to modify the implementation of this method. The easiest thing to do is to copy the method, rename it, and then call the new method in the improved use case. Please don't do this. Code redundancy is absolutely harmful. It is a better way to try to wrap or rewrite the method, or even modify it directly, and then retest 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 call it. Try not to expose non-essential parts. If refactoring is needed for better design, it should be done.

Most applications have definite structures and patterns to implement. When fixing or enhancing the program, make sure you are not deviating from this pattern. If you are not sure about the agreement, ask other senior developers to review your changes. If you have to do some implementation that violates the convention, try to place it in a smaller class (private functions in a class with 200 lines of code should not affect the overall design of the application)

5.2 Don't stop having a deep understanding of the project architecture

Assuming that you can deliver and continue with little knowledge of the project in the way listed in this article, you may stop having an in-depth understanding of the project architecture. This won't help your career in the long run. As your experience increases, you should take on larger module tasks. Such as building a complete new feature or modifying some of the basic design of the project and other major improvements. When you can make these improvements, you should have a good understanding of the overall structure of the project. The method listed in this article is to improve yourself in the shortest possible time, not to prevent you from fully understanding the whole project.

If you fix a bug, locate and fix it quickly. Runtime analysis tools can be used if necessary. If you add a close-up, you can look for similar close-ups, understand the process (it is necessary to use tools), and write it.

It may sound simple, but is it practical? That's for sure. But only if you have good java technology and know enough about the framework to modify the code first, and then analyze the impact of the change. Analyzing the impact of a change requires more skill than implementing it. You may need senior developers to assist you in analyzing the impact of changes.

Approximately 50% of the IT operational budget is spent on simple bug fixes and enhancements. According to the recommendations in the article, it should be very helpful to save money in maintenance activities.

What are the above suggestions for developing and maintaining large-scale Java projects? have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.