Learn some tips to cut down time spent on finding reasons why your code fails.
It is usually every afternoon, at around 3 PM when things start to go wrong. It all started after receiving a notification that a customer encountered a bug in your software. After a phase of doubt, you get in touch with DevOps to find out what is wrong with the logs for your app since you previously got a notification that they are being moved.
To your surprise, they are situated in a location you do not have access but in the process of being moved to a web application which will be available after a few days.
Sadly, logs or log messages often end up missing at the wrong time. Before you start to track down the bug, you receive a public service announcement saying:
- Check the logs to ensure that they are at the right place and logging what they should on a regular basis.
You end up astonished on how these processes rapidly change when you are away, even for just a short while.
If you found the logs or attempted the call and if the customer detected a bug, you might know where the bug is.
Avoid touching the code
The initial step is to take that call that creates the bug and use it as a test. Generally, this is an integration test since you have not yet fully determined the root of the problem.
Make sure that this test fails. Remember that this is vital since oftentimes, the test you make will not mimic the broken call which is true if you are utilizing the web or another framework that can complicate the tests.
Several elements might be stored in variables and it is not always evident just by looking at the test.
Create a failing test
Once you have a failing test or one with an error, you must troubleshoot. Before moving on to this phase, you should review the stack to make the troubleshooting process easier.
The stack includes all the tasks that have been initiated but not yet finished.
If you want a different approach, you can use Python Tutor where you monitor the stack while executing lines of code.
In case something goes wrong with your Python program, the interpreter will print out the stack for you. Regardless of what the program was executing at the time, it is evident that something went wrong at the bottom.
Prioritize the bottom of the stack
The bottom of the stack is where you will see which error occurred, but often the last line of the stack is where you find the issue. It is recommended to use pylint or flake8 which points to an error that might have been ignored.
In case the error is somewhat ambiguous, the next step is to Google it. You will have better luck if you do not include information that is relevant only to your code such as files, variables, etc. For those who are using Python 3, it is beneficial to include it in the search.
Back then, developers had to fix issues without the availability of a search engine. Those were the “dark” times. Today, you should make the most out of all the tools available.
Sadly, the issue might start earlier and only became evident during the line executed on the base of the stack.
It is time to look up the stack. There is a good possibility that the issue is in your code, not the Python core or even third-party packages. You must scan the stack for lines in your code first. Furthermore, it is relatively easier to set a breakpoint in your own code. You must include the breakpoint in your code a little further up the stack and check around if things look as they should.
Since you have a failing test, the best place to start is with the Pdb or Python Debugger. Look for a site in your code where this call should hit. You must find at least one place to include a pdb break.
Make the necessary changes
If you still feel lost at this point, you can try creating a new test where you make slight changes. Once you have a test ready along with additional tests, it is safe to start with changes in the code to check if you can narrow down the issue.
Remember to start the troubleshooting task with a fresh commit to ensure that you can easily draw out changes that do not work.
Once the task becomes frustrating, the ideal course to take is to simply walk away from the issue. Just take a break, for now.
Note down everything
After a phase of rest, it is recommended to note down any information you have about the issue. The details to note down must include:
- The specific call responsible for the problem
- What happened including any error messages or associated log messages
- What you were expecting to occur
- Tasks performed to find the issue and any clues that you encountered during troubleshooting
Oftentimes, this includes a lot of information. You can try to be brief but make sure that it is complete with all the pertinent details.
Writing down all the information might provide you with an insight into something that you have not yet tried in solving the issue. Oftentimes, you can figure out the problem after hitting the ‘submit’ button.
At any given rate, if you have not thought of anything after listing down everything, you can try sending an email to someone such as your colleagues or other people involved in your project. Remember that there is nothing wrong with asking for help. Most are kind and eager to help especially in the Python community.