Code Debugging Process

Muwonge Nicholus
3 min readApr 10, 2019

--

In a developer’ world, bugs seem to try their level best to trump over it in any way they can. These make life harder and a matter of fact make getting a spec of sleep at night more challenging than it actually should be.

I personally encounter bugs during the development of features. I usually keep this in mind before starting to code so I really don't freak out if I saw a status code 422 or any other error code for that matter. To make the debugging process easier I have always relied upon different tools and these are my personal favorites;

  • The default CMD and or Git Bash. Now, almost any programmer knows that the status of their request is displayed in the console and lucky enough it talks about the trails and or the particular lines or sections of the application affecting the smooth flow of the application. as demonstrated in tha picture below
an error thrown and directing one to the reason program isn't running in Git Bash.
  • Flake 8 and Pylint. This is a linting tool that helps one abide by the best practices in programming as per Pep 8 required standards. Luckily the authors of this remembered to throw in a check for valid code syntax, importations and so on. Well if I didn't get that picture painted so well, this program will alert you every step of the way without needing to first run the program.
Pylint alerting user by underlining a word.
Flake 8 in action
  • Postman: Now this is so popular to the extent of being a programmer’s must-have tool(“ I mean research shows”). So when running the program I usually test the operation of the app by running routes in postman which usually gives off a mock of how the back end should always function. It too, unfortunately, isn't any special with telling that hard truth of code being dysfunctional. It spreads it out for you and tells you to deal with it hence a long error message with pointers at where the problem may have originated.
Kind of looks like this for those who didn't know.

So after all this process, you realize that some of these bugs are repetitive, so what one should always do is look out for those and endeavor to learn how they come about and prevent it. For instance, following pep8 standards and on will never encounter those alerts.

I would also recommend writing tests for the code and then run them regularly to fish out all the bugs that come up in production.

At this point in time, I realize I haven't talked about code refactoring to make it work more flawlessly. In adding a new feature I also happened to change the code structure to a much simpler and cleaner look more like object-oriented structure layout that involves inheriting from one class to another. This looked like

A snap of file changes on Github

In this case, I moved the created_at and updated_at fields to a custom class since its similar to that of some other application and hence made these models inherit from the single model in core application. This is a good practice and in practicality makes debugging easy.

That was all for my code debugging session. Thanks for the read.

--

--

Muwonge Nicholus
Muwonge Nicholus

Written by Muwonge Nicholus

I am a Javascript and Ruby engineer. I love designing user interfaces and currently working in payment systems.

No responses yet