How a new person learns to add new features and debug in a large system

Background:

Formally started in March, the company's main ERP software. The group where the landlord is located is mainly responsible for secondary development. The language used is Java.

What is secondary development? All customers of ERP software are enterprises. However, the situation varies between these enterprises. A standard enterprise resource management system cannot meet all the requirements of each company. Therefore, after the customer asks, the programmer increases or decreases the system, which is a secondary development.

In addition, our group is responsible for fixing various vulnerabilities reported by customers.

Learn how to add new modules and new functions

　　Why is it not feasible to read the code from start to end?
Basically, the financial system spans over ten or even 20 years, with tens of millions of codes and dozens of version revisions. More importantly, there is not even a design instruction document or technical instruction document. Simply looking at the code, it is impossible to know exactly what each class is used for, how the methods in the class are called, and how the data is transferred and processed.

It is impossible to guess.

　　A good way to familiarize yourself with the code is to create a simple new module.

 

Take the simplest system logon interface as an example (see). Now let's do an exercise: Create a new page, change "logistics management system" to "Personnel Management System", change "Account" to "User Name", and remove the "password" label and column, you can log on directly with the correct user name.

The code is ready for use. Just create the corresponding file and copy and paste the file, and then make changes as needed. After completing several such exercises, you can understand the role of each tag and column, which is the quickest way. In addition, I suggest you write comments while reading the code to help you consolidate your memory and deepen your understanding.

 

Breakpoint is required for complex functions.

　　What if I change the requirement to a function that is not simple? Sometimes, we may not need all the content and functions of a ready-made module, but simply port one function to another, obviously, we can't simply copy all the code, but we don't know what code blocks are designed for this function. What should we do?

At this time, we need to use the breakpoint (break point) debugging.

I will not go into details about how to add breakpoints here. If necessary, I will find a few good combinations in a few days to post them to you.

In the debugging process, you can easily know which methods are involved and mark them one by one.

 

How to debug
　　First, make sure this is a bug.

One day, James was called by a guest on the internet, saying that his QQ account had been stolen, and he was required to be responsible for the virus. James pressed the Caps Lock on the keyboard with a blank expression, and asked the guest to enter the password again. Then, the login is successful.

The above example is a common sense problem, but many times the user's mistakes happen to be a stranger to the system or unfamiliar with the business knowledge. The following is an example. A bug was received a few days ago: the user had to make a payment document but could not read it on the Payment document page.

At this time, if I am not familiar with this service knowledge point, I may first check the database to see if the data is lost or the code is faulty. A filtering condition is set incorrectly. But at that time, my first response was: Will he have already made a payment order for the overdue bill? (PS: it can be understood that a payment order has been made for an overdue bill, which means that your company has already paid the other party and it is impossible to pay it again)

As a result, we can see it in their system.

　　After determining a vulnerability, You 'd better pay attention to it in your local system.

Because users' systems are in use, the data is also very important (hundreds of thousands or even tens of thousands in minutes, the problem code farmers cannot afford to move the bricks for ten years ), therefore, there is no way to test and verify your system at will. Therefore, you must pay attention to this fault in the local system.

In addition, you will have a more comprehensive understanding of the conditions for the failure in the process of local attention. Example: If a user tells you one day that the sun is green in such an instant, you can ask him about the specific situation to reproduce it. He told you that he looked up at five o'clock P.M. yesterday and watched the sun green at an angle of forty-five degrees. He also watched the love action education film for three hours. In this case, you can try using the same conditions. If the test succeeds, it means that the conditions are basically complete. If the test fails, you can continue to ask the customer if there are other cases.

 

　　Determine the possible direction and use breakpoint to gradually narrow down the scope

After determining the basic fault information reported by the customer, we can basically know the possible direction of the bug. For example, I received a bug a few days ago, saying that the user has been using a feature and is always okay. I know that Tuesday will suddenly fail.

After checking the related update records, no other colleagues updated the customer's code that day, so the problem may occur in the database. Later, it was found that the number of documents the user made exceeded the system limit and an error occurred while printing and distributing a stored procedure.

For code problems, we can use the breakpoint test mentioned earlier to gradually narrow down the suspicious scope and locate the problem. For example, if a data error occurs, we can view it from the method of interacting with the database until the method of displaying the data is finally displayed. When passing parameters, there may be dozens or even dozens of methods in the middle. You can quickly locate the problem by using the semi-division method to set the breakpoint.

　　Perform a complete test to prove that your repair solution is correct and feasible.
In general, if you have been entangled in a bug for several days, once you find the problem, you will be so happy that you can't wait to jump up from the chair. But at this time, programmers should be calm enough to be excited, because you do not necessarily find all the answers, or even none.

More than once, I think I can fix this vulnerability. But when I submit a repair solution in writing, I always feel that it is not convincing enough. Once I see it, the boss will certainly question it. So I slowed down and thought about it again. I found myself far away from the root cause of the problem, not to mention providing a reasonable solution.

Therefore, I suggest that you do a complete test after fixing the bug until it proves that your solution has completely solved the problem and has not introduced any new problems.

 

Last few digress

I haven't written any technical blog for a long time.

The official start of work is not very busy. Hong Kong enterprises (Shenzhen Branch) are not busy. In addition, they are not in the Internet industry. Overtime is almost the meaning. They can leave at around six o'clock. However, I was not so idle in school, so I was busy with the company's training a while ago, so I couldn't care about it. Recently, I finally began to adapt to all aspects of my work. I took the time to write this article and gave myself a work summary for the previous three months.

I have a public account named "Hua Gong Xiao y". I share my work every day and my hobbies, such as Lin. If you are interested, please pay attention to it. The following link is an article I wrote two days ago. You can take a look at it.

Http://mp.weixin.qq.com? _ Biz = mjm5otm5mtkxmw ==& mid = 200944770 & idx = 1 & Sn = 1e563849010fa5365f3c9b4dd982a149 # Rd

 

(If you think this article is helpful to you, you can click the "recommendation" button below and look forward to your comments to communicate with the landlord)

How a new person learns to add new features and debug in a large system