Suggestions for developing and maintaining large Java Projects

Suggestions for developing and maintaining large Java Projects

Suppose you are a Java developer who is developing and maintaining a 2000 class and uses 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 abilities to the project team. How do you deal with this situation? This article provides some suggestions for Java developers who start a new project.

1. Do not try to understand the entire project at once

Consider why the project code is the first? In most cases, you are asked to fix a bug or enhance the existing functions of the system. The first thing you need to do is not to understand the architecture of the entire project. This understanding of the entire project architecture may put a lot of 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 been working in this project for more than a year, assuming they are not original developers ). For example, the authentication mechanism or transaction management mechanism.

How did they do it? They are very familiar with what they are responsible for and can deliver value to the group. The value of delivery every day is far more important than knowing something you are not sure about in the future.

2. Focus on delivering value as soon as possible

So I am denying your enthusiasm for understanding the project architecture? No. I just want you to deliver value as soon as possible. Once you start a project and build a development environment, you should not deliver anything in a week or two, regardless of the size of the project. If you are an experienced programmer but haven't delivered anything for two weeks, how can your manager know whether you are working or reading news.

Therefore, delivery can make everyone easy. Do not think that you must understand the entire project before doing valuable delivery. This is totally wrong. Adding a piece of javascript verification code is very valuable to the business. Managers can trust you through your delivery. This will prove your contribution and employee value to the superior.

Day after day, you can gradually understand the project architecture after constantly fixing bugs and enhancing features. Do not underestimate the time required to understand all aspects of the system. It takes 3-4 days to understand the authentication mechanism and 2-3 days to understand things management. These are based on the experiences of similar projects, but it takes time to fully understand them. To squeeze out time in daily work, do not ask the manager for specific time to do this.

Check whether 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 snippets, including how an external interface unit of a unit is called and the returned content) and its internal implementation of debugging unit testing is much easier than debugging the entire actual use case ).

If you can understand some content, write some notes, or draw some class diagrams, sequence diagrams, and data model diagrams for maintenance by you or other developers in the future.

3. skills required to maintain large-scale projects

If you can do your current job, you must already have good java technology. Let's talk about other skills that enable 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 large project code.

3.1 quickly discover required classes

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

3.2 be able to analyze the impact of changes

After you complete the necessary modifications or enhancements, make sure that your modifications do not break other parts of the Code. You need to use your java technology and understanding of other frameworks to find out the potential impact of changes. The following two simple examples describe the situation mentioned at the end:

A) when the equals () method of Class A is changed, calling the List ins () method that protects the List of instance A will be affected. If the Java knowledge is insufficient, it is difficult to consider this impact.

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

When you improve the above two skills, although you are not very familiar with the project, most maintenance tasks will become much simpler. If you fix a bug, you will locate and fix it, and ensure that the change will not damage other parts of the project. If you enhance or add a feature, you basically only need to imitate the existing features to use similar designs.

Why is the design of "view account summary" and "view transaction history" significantly different in an online banking project? If you understand the design of "view account summary", you can simulate the function of "view transaction history.

For bug fixing and enhancement, You Don't Have To fully understand how the work content and code of all 2000 classes run to drive the system. If you have the above skills, you can quickly locate the part of the Code that needs to be modified, use good java and framework skills to fix it, and ensure that the change will not damage 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

To continue with the theme we deliver as soon as possible, you should look for tools that can help you implement delivery as soon as possible by understanding as few projects as possible.

4.1 quickly discover tools for content changes

To fix bugs or enhance the system, you must first find the classes and methods you need to modify to call this case. There are basically two ways to understand how a use case works, static code analysis and runtime analysis.

Source code analysis scans all code and shows the relationship between classes. There are many devices and tools on the market. For example, export exa, AgileJ, UModel, and Poseidon.

The disadvantage of all static code analysis tools is that they cannot accurately display the call status of classes or methods in use cases. Therefore, Java has added new features, such as the callback mechanism callback patterns ). For example, the static analysis tool cannot determine which Servlet is called when the page commit button is clicked.

The runtime analysis tool can display the status of classes and methods during use cases. Tools include MaintainJ, Diver, jSonde, and Java Call Tracer. These tools can capture the stack status at run time and generate sequence and class diagrams for a use case.

The sequence diagram shows all the methods called during the use case. If you are fixing a bug, it is probably one of these called methods.

If you are enhancing existing functions, use the sequence diagram to understand the call process and then modify it. It is possible to add a new verification, modify DAO, and so on.

If you are adding features, find some similar features, use the sequence diagram to understand the call process, and then develop new features in imitation.

Be careful when selecting the runtime analysis tool. Too much information is a major problem with such tools. Select a tool that provides simple filtering of invalid information and allows you to conveniently view various views.

4.2 quickly discover tools for content changes

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

There are still two technologies available for static code analysis and runtime analysis. Many static code analysis tools are available in the market. For example, Lattix, Structure101, Coverity, nWire and IntelliJ's DSM.

Given a modified class, the above tools can identify a set of classes dependent on the class. Developers need to "Guess" the use cases that may have an impact based on the information, because these tools cannot demonstrate the call relationship between runtime classes.

There are not many tools available in the market for impact analysis during runtime, except MaintainJ. MaintainJ first captures all classes and methods called 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 that MaintainJ can work effectively is that all use cases of the project should be run first, so as to obtain the dependency relationship during running.

In short, you can still get limited help from tools to quickly and accurately analyze the impact of changes. First, conduct some impact analysis as needed, and then judge the impact of the change based on the review by yourself or other senior members of the group. You may need the tools mentioned above to repeat your judgment.

5. Two suggestions for the above content

5.1 do not reduce code Quality

For fast delivery, the architecture is not fully understood, but it cannot be achieved by reducing the code quality. Below are some code quality problems that you may only consider fast delivery.

Because code modification involves a lot of dependencies, it is relatively less risky to add code. For example, five use cases call a method. 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 call the new method in the improved use case. Never do this. Code redundancy is absolutely harmful. It is a good way to package or rewrite the method, or even repair and modify the method directly, and then test all the cases again. Generally, it is a good way to stop and think about it, and then implement it with your own hands.

Another example is to change the "private" method to "public" so that other classes can also be called. Do not expose unnecessary parts. If we need to reconstruct the design for a better design, we should proceed.

Most applications have fixed structures and patterns for implementation. When fixing or enhancing the program, confirm that you have not deviated 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 conventions, try to place the private functions in a class with 200 lines of code in a small class without affecting the overall design of the application)

5.2 do not stop in-depth understanding of the project Architecture

Based on the method listed in the document, if you can deliver a project with less understanding of the project and continue to do so, you may end up with an in-depth understanding of the project architecture. This will not help your career in the long run. When your experience increases, you should undertake relatively large module tasks. Such as building a complete new feature or modifying some basic designs of the project, and other major improvements. When you can make these improvements, you should have a good understanding of the overall project architecture. The method listed in this article is to improve yourself in the shortest time, rather than prevent you from fully understanding the entire project.

6. Conclusion

The entire article focuses on fast delivery on the premise of having a necessary understanding of the project. You can do this without degrading the code quality.

If a bug is fixed, locate and fix it quickly. It is necessary to use the runtime analysis tool. If you add a new close-up, you can look for similar close-up, understand the process is necessary to use tools) and write.

Maybe it sounds simple, but is it practical? Of course. But the premise is that you have good java technology and a good understanding of the Framework before you can modify the code, and then analyze the impact of the change. Analyzing the impact of changes requires more skills than implementing changes. You may need assistance from senior developers to analyze the impact of changes.

About 50% of IT budget is available for simple bug fixes and feature enhancements. According to the suggestions in the article, the cost savings for maintenance activities should be very helpful.