How to maintain easy-to-read code

Hi everyone, this is KOTELOV!

Read this article about how our lead developers have covered the topic.

A large IT project requires a lot of money, time and energy. This is an investment for many years. In the long term, the project is influenced by factors such as staff turnover, employees who do not monitor code quality, team size, etc. As a result, “knowledge of the project” (the nuances of specific implementations of its functionality) is lost, further support of the project becomes difficult or impossible (the amount of money required for this purpose is disproportionately higher than the expectations and common sense). Hail to rewriting the code from scratch.

KOTELOV Team

One of the fundamental goals of project managers is: “the project should live longer than the current team has been developing it.” Code review is the primary tool for this purpose.

Code review allows to:

● Detect bugs and promptly make changes the moment each new feature is created.

● Transfer knowledge about the project to other team members. This is a great opportunity for developers to understand how the modules are made and how the modules interacting with the newly developed module work.

During code review, pay attention to:

1. Functionality performance. Non-working functionality will not bring profit.
2. Code purity. Developers often write code the way they like it, or the way they are used to. The result is a hard-to-read hodgepodge. To resolve confusion within the team, an agreement is made to use a single Coding Style that is to be followed and used for code review. One can use an open-source Coding Style Guide from large companies or write his own guide. It is important to understand that the effect is achieved only if all team members stick to it.

If the voluntary approach does not work, this process may be automated using the *lint automatic code checking.

Fragment of Coding Style Guide Google

3. “Reinventing the wheel”. The required functionality should be implemented in the project only once, and not to be duplicated in the modules in which it is used. For example, a developer who has been working on a project for a longer period, and knows the application better, should look at the modules written by other developers and point at existing functionalities. Some development environments include a tool to detect duplicate code sections right out of the box. For example, JetBrains.

4. Architecture. “An architect is like a sapper. He only gets to make one mistake.” A mistake found at the architecture level leads to reworking a significant part of the module, if not of the entire module. The sooner the bug is found, the less time and money the customer will lose.

Using tools for modeling various UML diagrams allows you to see a bug during development and pass introductory information to the development team.

Code review is performed by humans. When it comes to bugs, success depends not only on technical knowledge of the team but also on the ability to communicate, to convey comments in a friendly way to the author of the code — Victor Galaguza, Senior iOS Developer.

Even great professionals may have polar opinions. And this is OK, since one can learn many new ways to solve a problem.

Code review is a great platform for learning.