You will surely face bugs and they should be expected from all sides – code, compiler, the operating system. When it comes to data from Internet traffic, bugs are inevitable.

Bugfix algorithm

Before you fix something, you need to understand what happened and how it should have been. Without understanding, you risk wasting time or even make the situation worse.

Firstly, the bug must be repeated: you should find the sequence of actions, the state or environment where the bug is repeated. Without this step, you will not roll out a bug fix – it would be just a blind guess, and the bug will definitely break something one day.

When the problem is guaranteed to be repeated, you can start to isolate: look for the cause of the problem, generate and test hypotheses, cutting off everything that is not related to the problem.

Analysis

After compiling a list of the most time-consuming bugs, the next step is an attempt to find common ground in these errors, as well as to understand the reason for their appearance. Analyze and interpret!

When the reason is discovered, it remains to eliminate the bug and reflex: what went wrong, why, how to make sure that in the future there are no such bugs.

Understand the difference

What is the difference between bugs and vulnerabilities?

• If a security problem leads to a failure to fulfill the planned scenario, then this is a bug.

• If a security issue leads to the execution of an unplanned scenario, then this is a vulnerability.

Both bugs and vulnerabilities can violate critical program properties. On the one hand, the functionality of the project may be lost (for example, it is impossible to remove the token from pause). On the other hand, security issues can be exploited by cybercriminals to carry out various attacks.

Hypotheses

Hypothesis 1. Specific coding patterns are likely to lead to the appearance of bugs in a large software project.

Hypothesis 2. The time required to correct errors in a project can be reduced by avoiding the patterns of behavior defined in the first hypothesis.

Do not mix

Don’t try to mix algorithms and other technologically complex pieces of code with business logic. The expressiveness of modern programming languages ​​is quite enough so that, say, the graphic engine of a computer game does not know anything about ninjas and helicopters, the functions of working with the database in the CRM system do not know the words “count” and “client”, etc. etc. For business logic, constant change, fuzziness, and confusion are typical. As soon as entities from different levels of abstraction begin to be mentioned in adjacent lines of code, all this immediately begins to penetrate technologically complex code, and everything explodes.

Every extra line of code is a bad idea

Where this is generally possible, you should not use someone else’s code that you have not read and understood from and to. This also applies to well-known general-purpose libraries and frameworks. The less code (including the one you write yourself and the one you depend on), the better.

If it is possible, the code must be checked manually. The best way is to use code review, bug bounty, as well as several independent audits. Such measures help to cope with both bugs and vulnerabilities.