In October 2014, for the first time, a .Net guru, Dino Esposito, comes to Russia with a master class.
Dino Esposito is the author of many .Net programming books, a technical evangelist for Android and Kotlin at JetBrains, and a member of the team that maintains the WURFL, a mobile device information database used by Google and Facebook.

We suggest you to get acquainted with the translation of one of the articles of Dino “Problems with the code? Help the team write better code. ”


Sometimes it seems to me that in the late afternoon many developers are starting to think that poor-quality code, especially in a large project, is not such a big problem. And actually, if you decide to count how many projects failed due to problems with the code, then you will count them, and the truth is, not so much. One way or another, I think you will not want to wait for a real disaster, as a result of which you will lose a lot of money.
Being a lead developer (solution architect or what you call it on a business card), what can you do to help the team write the best code?
')

Seven virtues of software development

I dare say that successful projects depend on two factors: on leadership, who know a lot about leadership, and developers, who understand what quality code is. Here is a list of seven virtues that can truly lead a team to a developer's paradise:

1. Let the tools help in writing code.

Programming should not be broken into the time when the developers simply write the code, and temporarily (later) when they clean and fix this code. This "later" never comes. You need to write a good code immediately. And here tools come to the rescue. Typically embedded in the development environment, these tools simplify common tasks, allowing developers to work faster and write really better code. At worst, the code is written faster, due to which there is time to fix it.
Autocompletion, code idiom hints (i.e. code matching language or framework), code inspection, predefined code snippets inserted by pressing key combinations, and predefined and customizable templates — all this speeds up development, ensures consistency and in some least better and cleaner code.
Code entry assistants make development more efficient and significantly improve the quality of your code with just a few clicks. They reveal duplicate or unused code, facilitate refactoring, simplify navigation and inspections, and offer patterns. Moreover, the tools help to adopt an appropriate naming convention, making renaming or refactoring a method a trifling task.
ReSharper is the most popular of the existing code entry assistants. Additional information can be read here . Other similar tools are the CodeRush from DevExpress and JustCode from Telerik.

2. If someone writes bad code, tell him about it.

Suppose you notice that some people on your team write bad code. How to tell them about this?
Here you need to take into account some psychological aspects. No need to be harsh and offend someone. At the same time, you hardly want to be responsible for someone's bad work.
The best way to talk about code that you don’t like is to carefully ask the person why he wrote it that way. This will allow you to understand his motivation and whether there was any misinformation, bad attitude, inexperience or restrictions that you did not guess.
It is very important that you do not criticize the code, without having clear reasons for this. So just pretend that you are curious about why the code was written that way, and you are interested because you yourself would have written it differently.

3. Help the developer get better

The golden rule to follow in order for the command to issue the best code is as follows:
Criticize the code, not the encoder, but improve the code through the encoder.
Any piece of bad code can be fixed. If this needs to be done, do not blame the encoder, it is better to help him correct himself. By doing this, you get two benefits. You get a better developer and perhaps a happier and more motivated employee. You allow him to feel almost like a hero, because he managed to do his job in the best way possible.

4. Inspect code before confirming changes.

Your company may have the best coding standards in the world, but how to enforce them? Trusting developers, of course, is necessary, but we must not forget and check their work. Pair programming and systematic critical decision analysis are concrete ways of checking the state of the source code base. To analyze the solutions, you can take a sample of the code and discuss it with the whole team. This can be a real piece of code from a project, written by one of the team members, or - in order not to hurt anyone's feelings - a specially written piece of code that demonstrates what you want to say.
To ensure compliance with coding standards, you can enforce the confirmation policy in the source code control system, be it TFS, TeamCity, etc. Is there any way to automate this process?
Today, almost any source control tool offers control for file submitted for confirmation. For example, TFS has a gated check-in system -
confirmation of changes carried out by the rules.
In other words, confirmation files are accepted into the system only if they meet the established requirements. When creating a gated check-in, TFS suggests specifying an existing build script to be used. Only if the build completes successfully, the files are confirmed. In TFS, a build is just an MSBuild script that can be customized for many different tasks. TFS has a large number of predefined integrable tasks. For example, code analysis tasks (in the past FxCop) and the task of running a list of selected tests. Since MSBuild is nothing more than a registered component that implements a contract interface, you can create new tasks yourself to add your own validation rules.
It is worth noting that the above-mentioned JetBrains ReSharper code entry assistant in its latest version offers a set of free command line tools that can be used in the MSBuild personalized task to identify duplicate code and conduct type inspections, including personalized inspections using specific templates. In order to use the command line tools, you do not need a ReSharper license. More information on the command line tools from ReSharper can be found here .

5. Happy is the project that does not need heroes.

Developers tend to exaggerate their abilities. At least, many of us at least once secretly imagined how they work more than 80 hours a week, saving the project, give joy to customers and look like true heroes in the eyes of management and colleagues.
It happens that the terms are determined incorrectly from the very beginning. Sometimes this understanding comes only in the middle of a project. In such situations, it is always easier to resignedly agree with this state of affairs, but this does not bring much relief and, more importantly, requires manifestations of heroism. The essence of transparency is to talk openly about problems, but at the same time it is also an effective way to bring the situation under control and reduce pressure.
In software development, we are under pressure due to tight deadlines or lack of necessary skills. Both the one and the other problem are completely solvable, if you report them in time. No need to bring to the need for the intervention of heroes. I have been such a hero several times and the lesson I learned is that heroism is an exceptional situation, and in software development you should try to avoid any exceptional situations.

6. Encourage training

Why do professional athletes train for many hours every day? And is it possible to draw an analogy between developers and professional players? It depends.
On the one hand, developers and so train every day at work and do not compete with each other. So, there is no analogy, and therefore, it is not necessary to train.
On the other hand, athletes work out basic movements so often that they can repeat them on the machine. Constantly returning to the basics of object orientation, design patterns, coding strategies, and specific areas of the API helps to keep knowledge ready and use it as quickly as possible.

7. Continuous change is part of the deal.

A software development project begins with a vague business idea. Many projects resemble moving targets driven by requirements. Continuous changes are familiar daily news, not something fundamentally new. Obviously, a mindset is the only effective way to cope with this stream of change. To be effective, every developer must be ready to refactor.
Refactoring is one of those things that seem to add no value to the project. Unfortunately, without refactoring, there will be no value.
Bad code is more expensive than good

In the context of a long-term project that is of great importance for business, bad code costs several times more than good code. No matter how simple it may sound, the project dies due to a bad code, when the cost of working with it (its creation, testing and maintenance) exceeds the cost of expenses that the enterprise model can handle. It is also true that no projects fail because of problems with the code, if companies manage to keep the cost of expenses associated with the code at an extremely low level.

This is the main problem.

Management sometimes reduces it to a simple reduction in development costs, hiring low-paid developers, and requests / instructions to reduce the amount of tests and documentation. They reduce the cost of writing code, turning the project into homework. Unfortunately, creating a code that simply works is only one side of the problem. Today, demands are constantly changing, complexity is increasing - and, worst of all, truly being realized only on the go. In such a scenario, writing code is only one cost item. Code maintenance and its development are the most expensive articles.
A good architect knows perfectly well that code maintenance is directly dependent on its quality, understanding of software development principles and language features, patterns and practices used correctly, and testability. This makes coding a much more expensive process than creating a code that simply works, but is much cheaper than maintaining and developing a code that simply works.

Dino Esposito master class will be held on October 25 in Moscow. Read more about this here .