Suggestions for developing and maintaining Java for large projects

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

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

Consider why understanding project code comes first? In most cases, you are asked to fix a bug or enhance the existing functions of the system. The first thing you have to do is not understand the architecture of the whole project. When maintaining the project, this (understanding the whole project architecture) may put great pressure on you.

Even Java developers with 10 years of reliable programming experience may not understand the core working mechanism of the project, although they may have worked on the project for more than one year (assuming they are not original developers). For example, for authentication mechanism or transaction management mechanism.

How did they do it? They have a good understanding of 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 you're not sure about later.

2. Focus on delivering value as soon as possible

Have I determined your enthusiasm for project architecture understanding? Not at all. I just ask you to deliver value as soon as possible. Once you start a project and build a development environment, you shouldn't spend a week or two delivering anything, regardless of its size. If you're an experienced programmer and haven't delivered anything for two weeks, how can your manager know whether you're really working or watching the news.

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

Day after day, after you continue to fix bugs and enhance functions, you can slowly begin to understand the project architecture. Don't underestimate the time it takes to understand all aspects of the system. Take 3-4 days to understand the authentication mechanism and 2-3 days to understand things management. These are based on the experience of previous similar projects, but the key is to take time to fully understand. Make time in your daily work. Don't ask your manager for specific time to do this.

Find out if the project has some continuously maintained unit test cases. Effective unit test cases are a good way to understand the code of large projects. Unit testing can help understand code fragments, including the external interface of a unit (how the unit is called and the content returned) and its internal implementation (debugging unit testing is much simpler than debugging the whole actual use case).

If you can understand some content 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 new projects. Most of the time, your task in the project is to fix bugs and enhance functions.

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

3.1 be able to quickly find the required classes

In any maintenance activity, whether it is repairing bug or enhancing functions, the first action is to identify the classes that are called in the current repair or enhanced use case. When you locate the class / method that needs to be repaired or enhanced, you are half done.

3.2 be able to analyze the impact of changes

When you have completed the necessary modifications or enhancements, the most important thing is to make sure that your modifications do not destroy other parts of the code. You should use your Java technology and understanding of other frameworks to find out what changes may affect. The following two simple examples describe the last mentioned situation in detail:

A) when the equals () method of the class A changes, a contains () method that protects the List of the A instance will be affected. If you don't have enough knowledge of Java, it's hard 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 bug repair method, but he doesn't know that it will affect the use cases associated with "user ID".

When you improve the above two skills, although you don't know much about the project, most maintenance tasks will become much simpler. If you fix a bug, you will locate and fix the bug and ensure that the change does not destroy other parts of the project. If you enhance or add a feature, basically you just need to imitate the existing feature and use a similar design.

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

In terms of bug fixes and enhancements, you don't have to fully understand the work of all 2000 classes and how the code runs to drive the system. If you have the above skills, you can quickly locate the part of the code that needs to be modified, repair it with good java and framework skills, and ensure that the change will not destroy other parts of the project and deliver it, although you may only know the design of a small part of the project.

4. Use tools to find the required change content and the impact of the change

Continuing with our theme of delivering as soon as possible, you should look for tools that can help you implement delivery as soon as possible through as little understanding of the project as possible.

4.1 tools for quickly discovering the contents to be changed

Whether fixing bugs or system enhancements, you must first find the classes and methods you need to modify called by the use case. There are basically two ways to understand how a use case works, static code analysis and runtime 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, etc.

The disadvantage of all static code analysis tools is that they can not accurately show the runtime calls of classes or methods in use cases. Therefore, Java has added new features, such as callback patterns. For example, static analysis tools cannot infer which servlet is called when the page submission button is clicked.

The runtime analysis tool can show the state of classes and methods when the use case is running. Tools include: maintainj, diver, jsonde, Java call tracer, etc. These tools can capture the stack state at run time and generate sequence diagrams and class diagrams for a use case.

The sequence diagram shows all the methods invoked by the use case at run time. If you're fixing a bug, it's probably one of these called methods.

If you are enhancing existing functions, use the sequence diagram to understand the call flow, and then modify it. It may be adding a verification, modifying Dao, etc.

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

Be careful in choosing runtime analysis tools. Too much information is a major problem with such tools. Select some tools that provide simple filtering of invalid information and easy viewing of various views.

4.2 tools for quickly discovering the contents to be changed

If the unit test is effective, you can run the unit test to find out whether the change destroys other test cases. There are few unit tests that effectively maintain and cover large enterprise applications. Here are some tools for this situation.

There are still two techniques that static code analysis and runtime analysis can use. There are many static code analysis tools available in the market. Such as lattix, structure101, coverage, nwire and IntelliJ's DSM.

Given a changed class, the above tools can identify the collection of classes that depend on the class. Developers need to "guess" the use cases that may have an impact based on this information, because these tools cannot show the call relationship between runtime classes.

There are not many tools on the market that can be used for runtime impact analysis, except maintainj. MaintainJ first captures all classes and methods that are invoked in a use case. When the above information of all use cases is captured, it is easy to find the impact of class changes on use cases. The precondition for maintainj to work effectively is that all use cases of the project should be run once in order to obtain runtime dependencies.

In short, at present, you can still get limited help from tools in analyzing the impact of changes quickly and accurately. First, carry out some impact analysis as needed, and then judge the impact of the change according to the review of yourself or other senior members of the team. You may need the tools mentioned above to double check your judgment.

5. Two suggestions for the above contents

5.1 don't reduce code quality

For fast delivery, there is no overall understanding of the architecture, but it must not be conditional on reducing code quality. Here are some code quality problems you may have caused by considering only fast delivery.

Because modifying code involves many dependencies, the risk of adding new code is relatively small. For example, five use cases call a method. In order to improve a use case, you need to modify the implementation of this method. The simplest way is to copy this method, rename it, and then invoke the new method in the improved use case. Never do that. 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 use cases. Usually, it is better to stop and think about it, and then implement it by yourself.

Another example is to change the "private" method to "public", so that other classes can also call it. Try not to expose unnecessary 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 programs, make sure you don't deviate from this pattern. If you are not sure about the agreement, ask other senior developers to review your changes. If you have to do something against the Convention, try to place it in a smaller class (the private function in a 200 line class should not affect the overall design of the application)

5.2 don't stop understanding the project architecture

According to the way listed in the article, assuming that you can deliver and continue with less understanding of the project, you may stop understanding the project architecture. This will not help your career in the long run. As your experience increases, you should undertake larger module tasks. Such as building a complete new feature or modifying some basic design of the project. When you can make these improvements, you should have a good understanding of the overall architecture of the project. The methods listed in the article are to improve yourself in the shortest time, not to prevent you from fully understanding the whole project.

6. Conclusion

The whole article focuses on rapid delivery with the necessary understanding of the project. You can do this without reducing the quality of your code.

If you fix a bug, quickly locate and fix it. If necessary, you can use the runtime analysis tool. If you add a new close-up, you can find similar close-up, understand the process (use tools if necessary) and write it.

Maybe these sound simple, but are they practical? of course. But only if you have good java technology and enough understanding of the framework can you modify the code first and then analyze the impact of the change. Analyzing the impact of changes requires more skills than implementing changes. You may need senior developers to help you analyze the impact of changes.

About 50% of the IT operational budget is for simple bug fixes and enhancements. According to the suggestions in this paper, it should be very helpful to save money in maintenance activities.