Human factor or “agreements do not work”

Imagine the situation. You and your team, after the next iteration, discuss the weak code coverage with tests and decide that since Monday of the current moment everyone is writing tests for both new code and pop-up bugs. It seems reasonable (someone remembers the last unfortunate deployment), everyone assents and the content disagrees with the thought that now we’ll have everything will be fine. The time comes for the next meeting where during the question “how about testing with us”, the majority looks away. The result is clear, everything remains the same.

You can certainly try to calculate those who do not, find out why this is happening, conduct an educational conversation) and this will even help for a while. And then time will pass and everything will be as before. And those people who follow the agreements on this issue, in another question can do everything in their own way and vice versa.


')
Another situation. For the project, a system of access rights was needed and one of the team members implemented it. The library turned out to be powerful, flexible and generally convenient. It is being actively used and after some time they notice that many people ignore the rules for working with the library (agreements), as a result, the code becomes confused, there is a lot of duplication, there are always situations that the access to the functionality is not the one who should and no one can quickly figure out in the intricacies of access rules.

What unites these situations? Insufficient control over the process. You can control it completely differently and below I want to share my thoughts on how best to do it and why.

To begin with, control can be divided into two categories (in the context of this article): internal and external. Internal control is automated checks and restrictions using specific architectural solutions both at the project level as a whole and when designing specific libraries (interface design). External is a check by verifiers (including static analysis tools) upon availability.

Examples:
Foreign keys in the database - internal control.
By default, "all prohibited" using acl - internal control.
The manager watches the commit to the ticket - external control.
Static code analysis - external control.

Both types of control are important. At the same time, everything that can be controlled automatically, you need to automate and turn external control into internal. In essence, an article on how to “maximize the quality of a code with minimal control and eliminate the human factor.” This will save your nerves and help you to maximize the influence of a person on the quality of a software product.

Internal control

- The database must independently maintain its integrity (fk, check) and be as strict as possible with respect to the input data. Then the majority of development errors will be revealed at the earliest stages.
- The principle of “everything that is not allowed is prohibited” is always used.
- When designing internal components, you should strive to minimize the rules that will have to be adhered to in the process and use. Sometimes even at the cost of loss of flexibility (but so that it does not become a problem and an obstacle). And the python philosophy to help.
- Use mocks in tests only in case of urgent need (external service), otherwise every line in the real code will have to change several lines in the test, and in the end it will become an unbearable burden for the whole team.
- Internal libraries (as opposed to the code of the application itself) can be changed only upon agreement with the main developer. You can't do without control here, but you can partially solve the problem by creating hooks in the version control system, which will not commit the code to the conditions you need.
- When developing people constantly have to keep in mind things that “cannot be forgotten”, then most likely something is wrong. If it is impossible to do a refactoring which allows you not to think about it, then you need to do at least so that the code itself checks its requirements and reports them (for example, throwing exceptions).
- The code that is written or used for the first time (the first daemon, the first use of acl or any other component) must be written very well, because in the future everyone will be guided by it.
- Programming in pairs improves the quality of the code.

External control

- As far as possible, you need to change tasks and not fall into a situation when "only Vasya understands, but he is sick for the second week."
- Organize the development process so that all the code goes through the "main developer". Use not the agreements, but the rules of the VCS itself, which give access to writing to the trunk (master) only to it.
- Use continuous integration. And the red flag should not become the norm.
- Develop code requirements and conduct reviews.

Of course this is not all. Below are a few examples of the application of the described approach in real code.

We have a bunch of demons in the project, the framework offers to inherit the class and override the run method. Naturally, in this method you can write the entire code of a small daemon (which in practice is often done). To get to this code and test it is almost impossible. The logical solution is to ask everyone to write separate classes for each daemon, and in the run method only make the call. But this only works with maximum external control, so it is better to block direct access to this part of the framework and require the transfer of the daemon class to your proxy code. He will do all the work on the launch, and it is simply impossible or very difficult to write incorrectly. Perhaps this is the "syntactic vinegar ©".

In another project, all business logic was inside the database and access to it was carried out exclusively through procedure calls. The organization of access to the database was implemented in a limited way, which did not allow the usual sql commands to be done. Therefore, this aspect did not need to be monitored.

In general, you can say this: Create your system in such a way that the right things are done easily and naturally, while undesirable things are impossible or made with great difficulty.

upd This is not about controlling people! It is very important. No need to keep them on a leash and control their every step. Let them quietly commit their code, and now at a review, having identified the flaws, the code can be sent for revision.

I think that many will have something to add here. I will be glad to hear your experience.

ps vasfed thanks for the edits and improvements.