Skills for programmers to develop large applications

Original article: Tips to developers starting on large applications

Assume that you are a Java developer and are developing and maintaining applications that contain 2000 classes and use 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 and have very 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 to develop new projects.

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

After careful consideration, why do you want to understand the project code first? In most cases, someone asks you 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. When maintaining a project, doing so (understanding the entire project architecture) may put a lot of pressure on you.

Even Java developers with 10 years of programming experience cannot 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 the original developers ). For example, there is still a lack of accurate understanding of 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 want to dispel 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 content in a week or two, regardless of its size. 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 simplify things. 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, and the manager can trust you more 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 fixing bugs and enhancing features. Do not underestimate the time required to understand all aspects of the system. It takes 3 to 4 days to understand the authentication mechanism and 2 to 3 days to understand transaction 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 unit test cases that are effectively maintained. Effective unit test cases are a good way to understand the code of large projects. Unit testing helps you understand code snippets, including an external interface of a unit (how a unit is called and returned content) and its internal implementation (debugging unit testing is much easier than debugging the entire use case ).

If you can understand some content well, you can take some notes, or draw some class diagrams, sequence diagrams, data model diagrams, etc., so that you or other developers can maintain them 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 thing 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.

　　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:

• When the equals () method of Class A is changed, the contains () method that stores the list of instance a is called. If the Java knowledge is insufficient, it is difficult to consider this impact.
• In a web project, we assume that the "user ID" is stored in the session. New programmers may add some information in "User ID" to fix bugs, but they do not know that it will affect the use cases associated with "User ID.

Therefore, you must gain an in-depth understanding of the Java language and the framework you use in your application, so that you can analyze the impact of a change.

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 want to fix a bug, you will locate and fix it, and ensure that the change will not damage other parts of the project. If you want to enhance or add features, you basically only need to imitate existing features and 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 fixes and enhancements, you do not have to fully understand the working content of all 2000 classes and how code-driven systems run. As long as you have the above skills, you can quickly locate the code to be modified, use good Java and framework skills to fix it, ensure that the change will not damage other parts of the project, and then deliver, 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 of our delivery as soon as possible, you should look for tools to help you implement delivery as soon as possible, with little understanding of the project.

　　4. 1. tools for rapid discovery of required changes

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

Source code analysis statistics scan all code and show the relationships between classes. There are many tools on the market. For example, architexa, agilej, umodel, and Poseidon.

The disadvantage of all static code analysis tools is that they cannot accurately display the runtime calls of classes or methods in use cases. Therefore, Java has added some new features, such as the callback mechanism (callback patterns ). For example, the static analysis tool cannot infer which servlet will be called when the submit button of the current page is clicked.

The runtime analysis tool displays the status of classes and methods during use cases. Such 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 the use case.

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

If you are enhancing existing functions, such as adding verification and modifying Dao, you can use the sequence diagram to understand the call process and then modify it.

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

You must carefully select the runtime analysis tool. Too much information is a major problem with such tools. You can select some tools to provide simple information, filter out invalid information, and view various views conveniently.

　　4. 2 tools for rapid discovery of required 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.

Here, there are two technologies available: static code analysis and runtime analysis. Many static code analysis tools are available in the market. Such as Lattix, structure101, coverity, nwire, and intellij's DSM.

For changed classes, the above tools can identify the 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 for impact analysis during runtime on the market, and only maintainj may be available. Maintainj first captures all classes and methods called in the 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 first, so as to obtain the dependency of the runtime.

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 to use the above tools to repeat your judgment.

　　5. Two suggestions for the above content

　　Do not reduce code Quality

For fast delivery, you can not fully understand the architecture, but you must not reduce the quality of the Code. Below are some code quality problems that you may only consider fast delivery.

Because code modification involves many 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 wrap or rewrite the method, or even modify it directly, and then test all the cases again. It is usually 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 reconstruction is required for better design, we should proceed.

Most applications have fixed structures and patterns for implementation. When fixing or enhancing programs, make sure they do not deviate from this pattern. If you are not sure about the protocol, ask other senior developers to review your changes. If you have to do something against the conventions, try to place it in a small class (private functions in a 200-line code class should not affect the overall design of the application)

　　Do not stop understanding the project Architecture

According to the method listed in the article, if you can deliver a project with less understanding of the project and continue to do so, you may stop having a deep understanding of the project architecture. This will not help your career in the long run. When your experience increases, you will 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 architecture of the project. The methods listed in this article only allow you to improve yourself in the shortest time, rather than preventing you from fully understanding the entire project.

　　6. Conclusion

The focus of the entire article is to understand the project and then deliver it quickly. You can do this without degrading the code quality.

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

Maybe it sounds simple, but is it practical? Of course. The premise is that you have good Java technology and a good understanding of the Framework before you can modify the code and 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. The suggestions in this article should be helpful for saving money in maintenance activities.

　　The author choudary kothapalli is also the creator of the maintainj project.

　　About the author

Choudary kothapalli is the founder of maintainj Inc. The tool provided by the company is used to save costs when maintaining large Java projects. The author has 15 years of experience in developing and maintaining enterprise-level Java applications and is Sun-certified enterprise architect and Java developer. He currently lives in Toronto, Canada with his wife and two sons.

　　About translators

Chen has been engaged in Internet Information Collection and Analysis Architecture Research for a long time. Rich experience in processing massive data volumes and nosql, focusing on process methods and automation. His Sina Weibo blog: Nothing to worry about