Just another way of fixing bugs

Every developer has to manage with bugs. We have to deal with this because no one is able to write code without errors. Requirements are always changing, systems becoming more complex with time and in such situations, it's hard to not make mistakes.

But how to avoid repetition of the same bugs when you edit a code? There's a good solution that will also save you some time while debugging the reasons of bugs.

Let's take a look at how usually developers start fixing bugs. At first, you will try to reproduce the bug. This depends on the system you are working with, but usually, it will be either making some network calls or clicking buttons on site in the correct order or whatever. Then if you are able to reproduce the bug you will try to debug the code to find what's causing a problem. And to do this you will again make network calls, click site or something like that.

Here comes the solution!

Instead of making any movements after you were able to reproduce the bug try to write a unit test for this. After this you are free of bug reproduction, you can just debug your unit test.

As a bonus, you will cover your code with a tricky case tests and won't let this bug be repeated in the future.

I know that it's not something new and it's great if you are already doing this but this thing should be told. Even the obvious things should be discussed because what is obvious to you can be not so obvious to your friends and vice versa.

It's hard to write good tests that will cover all cases from the first time. That's why it's important to continue writing them in future when you are using your code.

Thank you for attention! Good code to you all!

Comments

How to Build TypeScript App and Deploy it on GitHub Pages

Quick Summary In this post, I will show you how to easily build and deploy a simple TicksToDate time web app like this: https://zubialevich.github.io/ticks-to-datetime .

Pros and cons of different ways of storing Enum values in the database

Lately, I was experimenting with Dapper for the first time. During these experiments, I've found one interesting and unexpected behavior of Dapper for me. I've created a regular model with string and int fields, nothing special. But then I needed to add an enum field in the model. Nothing special here, right? Long story short, after editing my model and saving it to the database what did I found out? By default Dapper stores enums as integer values in the database (MySql in my case, can be different for other databases)! What? It was a surprise for me! (I was using ServiceStack OrmLite for years and this ORM by default set's enums to strings in database) Before I've always stored enum values as a string in my databases! After this story, I decided to analyze all pros and cons I can imagine of these two different ways of storing enums. Let's see if I will be able to find the best option here.

Caching strategies

One of the easiest and most popular ways to increase system performance is to use caching. When we introduce caching, we automatically duplicate our data. It's very important to keep your cache and data source in sync (more or less, depends on the requirements of your system) whenever changes occur in the system. In this article, we will go through the most common cache synchronization strategies, their advantages, and disadvantages, and also popular use cases.

How to maintain Rest API backward compatibility?

All minor changes in Rest API should be backward compatible. A service that is exposing its interface to internal or/and external clients should always be backward compatible between major releases. A release of a new API version is a very rare thing. Usually, a release of a new API version means some global breaking changes with a solid refactoring or change of business logic, models, classes and requests. In most of the cases, changes are not so drastic and should still work for existing clients that haven't yet implemented a new contract. So how to ensure that a Rest API doesn't break backward compatibility?

Blog about software development

Search This Blog