What do you do when a program encounters a bug?

They all say that attitude determines everything, and a good attitude can also make a good developer. However, in real life, when you encounter problems, functional implementation failures, or fail to run normally, you will start to complain or look for excuses, these excuses are useless or a obstacle to your progress. The true professional attitude should focus on the positive results of projects and teams, the growth of individuals and teams, and actively carry out various tasks around the current work.
Rajaraman Raghuraman, author of this article, is a software developer with 8 years of development experience. He summed up the excuses and reasons that programmers often find when encountering problems, I do not know if you have been shot. If not, you may wish to take a look at "30 common responses after a programmer encounters a Bug ".
1. Running well on my machine
Developers often encounter such problems. They feel that the tester or customer's computer has a magical magic that can inject bugs into the program. Because the program can run well on his own computer, why is there a problem with them.
To avoid such excuses, developers need to figure out the development, testing, and customer runtime environments. The configuration or environment in which the bug occurs. When you figure out this, I believe you will not make such complaints again. Another way to avoid this is to have a continuous integration environment, check every piece of code, and compile and deploy the code on some test machines.
2. Is this the latest build?
When a tester tells the developer that there is a bug or submits a bug, the programmer often asks, is the application you are testing the latest build status? In fact, this situation rarely happens. Generally, bugs submitted are found in the latest build.
To avoid this, it is best to have a process that verifies that the code used by the tester is the latest and most effective. Another method is to have a continuous integration environment where the code can be automatically built and deployed to the test server.
3. It must be a configuration problem.
If a developer says this to you, you can say, "Maybe, could you tell me which file has a problem with the configuration? I need to make it run ." As in the preceding dialog, the user needs an exact answer, not a general or ambiguous answer.
The best practice is to define relevant parameters in all configuration files in a separate configuration file and write all dynamic values in a log file to prevent confusion during reference.
4. First raise a defect, and then I confirm it.
Personally, an unconfirmed defect is annoying. Developers can either track defects during development or coordinate between programmers and testers. Generally, developers and testers should work together to confirm defects, to prevent ambiguity.
The best way to avoid this is to have good team morale and collaboration between testers and developers. In this way, they can easily communicate and discuss and identify and track defects.
5. Restart the machine.
This can be said to be a programmer's killer shield. Sometimes this will work, but it is usually false. To avoid this situation, you need to understand the architecture, code, and the corresponding development environment.
6. I'm not sure why it doesn't work. Let me check it.
I believe that users hate developers for making such excuses. As a developer, you are not sure why a specific module/function does not work, so have you correctly understood this function and code design?
To avoid this situation, developers should have a clear mind map for each module. Once a problem occurs, they should analyze it immediately and find out the possible causes. If you are confused about the problem or do not know the cause, it is probably because of poor code design or lack of understanding of the corresponding functional modules.
Try again in 7.5 minutes
Well, you have set the timing zhadan for the program so that it can work again in five minutes.
This excuse is really ridiculous. Developers should realize that the Code will not change with time unless you have set some specific timed code functions.
8. I don't think my code is wrong.
Some programmers often say, "My code is correct ." As a member of the development team, it is better not to say "my code". For example, a module may have some problems. Let's check it out, finally, find the corresponding developers, which is more conducive to boosting team morale.
To avoid this situation, the best way is to embrace the team culture. Every developer must be aware of the functions and functions of each module and grant corresponding permissions.
In addition to the above eight sentences, what excuses or shield do developers make when they hear that their programs are defective or their functions fail? Let's share it with you.
Translated from: Java Code Geeks