Many projects with which I worked, large projects, turned into legacy, unraveling beards, and as a result, development became extremely difficult. There were cases when projects just died due to the hellish complexity of making changes. Today I will tell you about my experience of working with projects, and why I am writing all this to you at all. Everything is very subjective, of course.
So, I worked, and I tried, like a sailor who wants to rake out water and prevent the ship from sinking, but the quality of the project steadily declined, and there were several reasons.
You will easily recognize them, they are regular patients, I will just remind you about them:
- The architecture is lame, it is difficult to implement a new solution
- Coding errors
- There is no automatic testing
As a result, according to the results of the development of the project during the first 1-2 years, a mixture of legacy, shitty code, tangled tunnels with secret passages, and rock paintings ala "works like this, why I don't know" is obtained.
I do not dwell on this much, this is the # 1 topic in refactoring, so straight to the conclusions that I made.
The developed product is a collective expertise
If the team has 1 mega-developer, really pumped, works well, then he will not clean it up alone, because the team constantly makes mistakes and will invariably drag the project down.
You can, of course, try to give the current team a refactoring task, and then those who welded it will redo their own work result, and will give the same thing, well, maybe a little better than the first time.
Therefore, you should not expect a radical quality upgrade without a team upgrade.
This is a vicious circle # 1 - the team's expertise is not enough, but refactoring begins, and, attention, the same posons who wrote it do it.
Alternatively, you can put a good lead who will conduct a review and clean up these errors (although he will try to do it), but in the end it will end up with a headache for those who work badly, and then either the replacement of the developers, or they themselves will leave, and, again will replace developers.
It will be a kind of natural selection on the project.
People are afraid to change the code
Welcome, this is a psychology session for programmers.
Programmers are really afraid to change the code, and they can be understood:
- Not enough tests or not
- How the code works is not clear
- The dates are on
- No resources
- Management will not understand (normal, but if management is on fire, everything will be fine)
As a result, the old confusing legacy code that drags the project down is perceived as "it's better not to touch", and as a result this "don't touch" lasts forever, and, even worse, forces you to write code in a certain way, causing other technical problems that then they also pull the project down.
We take a project, shitty code, team fears, multiply it by time, and we get a huge technical debt, which stands up edge and does not allow the team to move normally and develop the project quickly.
The project starts to fall apart, deadlines are disrupted, new features become wildly more expensive for the project, developers start to get nervous, some leave, new ones are harder to find, you get the idea ...
So, I think this is problem number 1, fear of the code and risks.
From experience it has been noticed that if you leave technical debt, then this is a potential bomb, or at least a rake. Leave them 100, 1000, and you will get a minefield, on which not only go (develop the project), you will not be able to crawl.
Therefore, the only way to save the average speed of project development and not drag the quality down is, thanks to the cap, pay attention to quality, refactor.
Council fire, everyone knows about it, but in fact the list above has not gone anywhere, so you can't just take it and refactor it, because you get a project that is falling apart, and why?
Because there are no tests, how the code works is not clear, and as a result, instead of changing the car drawings and assembly, it turns out that Vasya and Petya took a grinder, sawed Solaris, and put it back to Tavria, but it does not go. Why? - oh, but because we did not know about that influence / behavior / tasks
Yes, you can refactor without tests, and then stabilize, but many user scripts or necessary code execution scripts can be lost, or stabilization can take a very long time.
Therefore, one more vicious circle - you can't leave the code alone, but you can't refactor it either, as it were, because there are huge risks.
It turns out that we don't need Legacy, but getting rid of it is scary and dangerous, so teams often leave Legacy as the "least dangerous option" in order to get an even more dangerous solution for the project later.
Tests are the key
It turns out that in order to unlock the refactoring and make it safe, you first need to cover all the cases with tests, and then when we cut our Solaris and assemble it to Tavria, the welding will stop and say "Hello, we need a Solaris, you messed up here."
Tests allow you to avoid mistakes when refactoring, i.e. make it safe, and then you can cut the project as you want and need without the very fear that risks will work and there will be problems.
Therefore, we get a chain:
Tests -> Refactoring -> Goodbye beard and legacy
It sounds simple, beautiful, but in practice there are few tests. Or it doesn't happen at all, and there are several reasons for this, as usual:
- Developers consider tests to be a separate topic and do not invest in assessments; they write separately from development. It is even more difficult if the project management thinks so and wants to cut tests to meet the deadlines.
- Tests are time, but the project needs to be handed over now, there is no time to write tests for us (this is, in theory, the same as point number 1)
- The project / component is simple, why are there tests, everything is extremely simple and works there?
- First we'll write the code, then we'll cover it with tests. But no, we didn't get it, the project didn't stand still, there was no time. So this task lies in the black box forever and ever.
There are actually a million reasons, but the fact is that it blocks refactoring and, as a result, prevents quality from growing up.
Therefore, tests are a critical task, and without them, the long-term quality development of the project will be significantly difficult if not impossible.
What to do, Houston?
I am writing this article only because not everyone understands this, and there is at least someone who will read it and want to write tests, refactor, which means I did not write this article in vain.
Therefore, everyone's homework - take a poorly written module, component, something, find there that you would like to refactor, write tests for this module or component, and refactor.
As a result, you will understand that tests are:
- A way to learn code. It may even be much more efficient than just reading it.
- Stability
- Old code can really be refactored and the quality of the project can be improved
I wrote everything in one breath, very subjectively, and maybe I'm wrong, this is just my experience. Maybe I just come across such projects, I don't know, but the information is still useful, and if you are thinking after reading it, this is also good.
I wish everyone good code, tests, and quality movement up - that's why we are hired, let's work well.
PS If you wish, write your refactoring experience in the comments, everyone will be interested.