All people do not know how to write code
On the eve of Moscow Python Conf ++, we talked with Nikita Sobolev, CTO of the company "We make services", about the global problem of managing the complexity of code in the context of the development of programming languages. And also about why the situation becomes worse with time. Plus they asked why he had to create his own linter.
repository , where I collect such code examples.
The worst example I saw showed me that within a cycle of a hundred iterations, you can define a function. To be honest, when I looked at it, the interpreter broke down inside me. I guessed, but did not know that it was possible.
There was a case where we saw a lot of funny comments in the code. Someone complained about life, at work, there were those who wrote: "I understand that I'm writing nonsense, but the customer forces me." However, customers do not usually force you to write bad code. They ask to solve their problem, and what kind of code you will write there, they are generally up to a light bulb.
- Linters, code review - do not save?
I have two answers. Yes, they save. No, they do not save. It saves if you strictly follow the rules and regulations given to you by the prospective linters (those who do a lot of rough work for you: check functions for complexity, code semantics, etc.). This element must be blocking. You can not just run a linter sometimes to look at the result. If you failed these rules, then you generally should not release the code in production.
But in fact - do not save. Because those projects that use it are rare.
By the way, I am often asked: how can this be implemented? And I answer: it's very simple, in CI you put a line - check my code - and if it falls, everything you've implemented. It remains only to refactor everything. Fortunately, now there are autoformers and the ability to refactor the file after the file. The next question is traditionally: how to explain to business what is important?
- Is there any general answer to this question?
For each case, the answers are different, so in the general case it is difficult to formulate (you need to think about that, about this ). But usually the companies that deal with this problem are on the technical side. Those. techies ask us how people who know how to talk about business, and about technology understand, explain it to business in their particular case. With this formulation of the problem, this works very simply. When you come, everything is bad, and everyone understands this. The conversation with business starts like this: "Do you think that your programmers are sitting and doing nothing?". And the business nods. And you say that this is not the case. Programmers are wonderful guys who are trying to solve your problems. But without an integrated approach to project management, everything falls into chaos, and this is normal.
And we suggest together to come up with rules to avoid certain problems. We consider the cost of introducing different pieces, and then we estimate the real (accomplished) losses from the fact that such pieces are not yet available. For example, programmers for a whole month ruled a bug that does not exist or which can be found in 30 seconds if you use a certain approach and tool. The figures are convincing.
- In the end, is this an administrative problem?
Of course. I am convinced thato programmers want to write good code. But there are different obstacles. Someone can not because of inexperience. Someone lost motivation, because everyone does not care. Someone does not know what exactly is a good code for, say, creative throwing. They press on someone - he wants and can write, but they tell him that it must be tomorrow. And instead of building a partnership with the business and explaining why it will not be tomorrow (or if it is, then it will be necessary to reign three more days), he does anyhow as. And such partnerships are interesting for the business itself. He also needs to make it work for a long time and it's cheap to maintain.
That is, here all the issues are solved: there are no insoluble contradictions.
- There is the same code style - PEP 8. It does not help to quickly understand, what is good?
In terms of commas, it helps. But what's the point, if you put the commas correctly, and everything else will be bad?
- Is there not enough of a well-known higher-level thing?
In theory, there are some best engineering practices. But they are either unknown or ignored. When you ask why the developer did not follow this practice, he says that he kind of heard that this is a good topic, but the code works. When the code stops working, do you ask if he understood, where did the best practice come from and why should it be observed? No, I do not. He thinks that he was just mistaken.
It's hard to explain to a person that it's normal to make mistakes. Everyone is mistaken, we are all people. But the best engineering practice was just invented to save you from a mistake or protect you from the consequences. Those. it is a tool of safety engineering, as in enterprises. Only it was written not with blood, but with time and money.
In general, our unattainable global task is to automate the code review, so that Python itself (if we are talking about our case) knew how to write it. It should be a tool that delivers not only opportunities, but also limitations for developers.
- Why do you even develop a linter? Is it possible to use (or develop) existing ones?
In fact, we do so. Our linter in fact is a plugin for Flake8. Just position it exactly as a full-fledged tool, not just a plug-in.
Why Flake? not Pylint? Pylint does a lot of what exactly linter does not have to do. For example, it implements a very large number of checks on the type, although types should deal with type checker. Plus, he gives out a very large number of errors, which in fact there. And I do not like his documentation, and I'm frightened by his own implementation of ast. It is difficult to configure. By enabling the configuration, you allow people to make the wrong choice. Therefore, we have a task - to make a tool that can not be configured. So you put it - that's all.
- What guides formed the basis of this linter? Or is it just your own experience?
Now it is based on the rules that we have formulated for many years on our code review. Some rules were ported from other linterers: ESLint, Pylint, SonarQube, Credo. Much took from the wonderful work «CognitiveComplexity» . Always looked back at Miller's Wallet. Separate rules - this is my vision, which appeared after evaluating a large number of other people's code. That is, at this stage it is a "team solyanka".
- What will you tell about Moscow Python Conf ++?
First of all - about complexity management . This topic is close and understandable to all developers. We will look at different metrics, on ways to transfer complexities from the simplest component code - lines - to the most complex - the module. And then we'll talk about the holivar part, where I'll lay out my vision of how it is necessary or not necessary to write in Python, and ask users to vote what they like and what does not. For many developers, the restrictions (doing A, but not doing B) are an attempt on their creative space, so they react very vigorously to it. And this is where you can unleash an interesting discussion.
- Who is the report focused on?
I think that these are all the same developed developers, because the beginning programmers have not yet formed their clear opinion. Although they will be interested to listen and speak. They are exactly our users.
Friends, we hasten to remind that before our Moscow Python Conf ++ less than a month. This year it will have more than three dozen performances and a whole series of Mitapov. The final program will be announced the other day, but for now you can get acquainted with the general list reports.
It may be interesting
visit this site
visit this site
visit this site
Pleasant data, significant and magnificent plan, as offer great stuff with smart thoughts and ideas, bunches of incredible data and motivation, the two of which I need, on account of offer such an accommodating data here.