Refactoring is not a task in Backlog
Some time ago there was a lot of noise on the Internet and questions at conferences about whether code refactoring tasks are the same kind of tasks as everyone else, with the need to describe them, put them in the Backlog, and then move them to a new sprint. I think this is a bad idea, even in the case of an excessively overgrown “technical debt” of the project. And that's why:
When a new project starts, its code is clean and beautiful. It's time to design beautiful abstractions, write good interfaces and professional implementations. Life is Beautiful! Our project too.
We continue to add functionality, everything goes smoothly. Then at some point we have to cut the corner a little, slightly roll off the intended track, add a very, very small processing of one particular case ... No, no, no "crutches"! Just a little necessary code that brings a beautiful theory to a working practical implementation. Nothing foreshadows trouble, and the development goes quite vigorously.
Nevertheless, on the canvas of our ideal picture of the code, small blots appear. Some people call them technical debt. This does not mean that you really owe someone something: this is simply not a very good code. But he somehow works, solves his problems.
As we continue to develop, we will stumble on such places in the code more and more, and each time we will have a choice: throw your breasts on the embrasure and rewrite everything completely or go around the problem area to solve another problem (the one you are working on at the moment). Sometimes we rush into battle, but more often we choose the option with a detour.
In each case it slows us down only a little. But, since as the deadline approaches, the requirements for development speed only grow, we have to gradually lower the bar for our code quality requirements - and this leads to an increase in the number of “blots”.
These new problem areas (in addition to the old ones) inhibit us more and more. We are aware of the problems, but the rush in terms of solving current problems does not allow us to focus on anything else. We have to work harder, just to keep the same speed.
At some point, it suddenly turns out that half of the code that we write is intended for backups, bypasses, hacks, and overcoming other types of obstacles we created earlier. There is a good code, there is a bad one, but here we wrapped the fish.
Each walk through this minefield instead of a straight line from point A to point B suddenly becomes an intricate maze route, without any guarantee of reaching the final goal. Even super-efforts do not allow you to move to the goal at the same speed as before.
The importance of problems is now visible to the naked eye. And they can not be fixed by simply throwing everything away and starting a project from scratch. We need to perform many tasks on refactoring code, and for these tasks we need time, which we have to ask the customer. Often this time will not be allotted to us: we in fact ask for time in order to correct our own code, for the development of which time has already been allocated and which we have previously stated ourselves.
Even if time is allotted, do not expect a quick result. We will be able to fix only those problems that we see right now and only to the extent for which the allotted time is enough (and there will not be a lot of it). We have written this bad code for many weeks (or months), and we definitely won’t have the same amount of time to rewrite this code.
This is not the way we need to go. Long periods of refactoring do not bring a large and immediately visible benefit to the project. They are very difficult to sell to the customer, because he will not see for what functionality he is asked for money. That is a bad idea. What to do?
Simplify! Upon receipt of each next task, we outline a plan for its implementation. If, in the course of this plan, we run into the “gum” of technical debt, then the task of refactoring it becomes part of the implementation of the current feature. Of course, we cannot immediately take up all the bad places in the code. But this need not be done! If during the implementation of any new functionality you correct more old “blots” than create new props and crutches, the overall quality of the project code will increase. Next time, when working on a new task, you suddenly have to turn to an already corrected place - you will be pleased to note that it no longer requires polishing with a file, but it works well at once and looks nice. This is how software development happens.
Perhaps the development of each individual feature in this way will take a little longer than you originally expected. But the development of the entire set of functionality with this approach will take less time, because at the last stages before deadline you will have the opportunity to work with a relatively clean code base, adding new functionality will not take time to search for workarounds. In addition, this personal approach to your development will have a good effect on the performance of the whole team.
Repetition is the mother of learning. With each new feature, we make the code a little cleaner. Just a little bit, but every time. Many times "slightly" at some point will allow you to write with a calm soul a new, well-functioning feature, for which you are not ashamed, instead of tearing your hair out and struggling with the desire to remove all this garbage at all.
The moment of awareness of the usefulness of continuous refactoring is not as far as you might think. Some people began to notice him by the end of the same sprint in which they began to use this approach. The forces of continuity and incrementality of the process make themselves felt very quickly. From a certain moment, the execution of a new task with refactoring starts to take less time than to perform the same task without refactoring (due to the time spent earlier on improving the accompanying code).
')
The work goes better, the code becomes cleaner and we give the customer more functionality than we could before. All win.
So refactoring is not a task in Backlog, it is part of every task in it.
When a new project starts, its code is clean and beautiful. It's time to design beautiful abstractions, write good interfaces and professional implementations. Life is Beautiful! Our project too.
We continue to add functionality, everything goes smoothly. Then at some point we have to cut the corner a little, slightly roll off the intended track, add a very, very small processing of one particular case ... No, no, no "crutches"! Just a little necessary code that brings a beautiful theory to a working practical implementation. Nothing foreshadows trouble, and the development goes quite vigorously.
Nevertheless, on the canvas of our ideal picture of the code, small blots appear. Some people call them technical debt. This does not mean that you really owe someone something: this is simply not a very good code. But he somehow works, solves his problems.
As we continue to develop, we will stumble on such places in the code more and more, and each time we will have a choice: throw your breasts on the embrasure and rewrite everything completely or go around the problem area to solve another problem (the one you are working on at the moment). Sometimes we rush into battle, but more often we choose the option with a detour.
In each case it slows us down only a little. But, since as the deadline approaches, the requirements for development speed only grow, we have to gradually lower the bar for our code quality requirements - and this leads to an increase in the number of “blots”.
These new problem areas (in addition to the old ones) inhibit us more and more. We are aware of the problems, but the rush in terms of solving current problems does not allow us to focus on anything else. We have to work harder, just to keep the same speed.
At some point, it suddenly turns out that half of the code that we write is intended for backups, bypasses, hacks, and overcoming other types of obstacles we created earlier. There is a good code, there is a bad one, but here we wrapped the fish.
Each walk through this minefield instead of a straight line from point A to point B suddenly becomes an intricate maze route, without any guarantee of reaching the final goal. Even super-efforts do not allow you to move to the goal at the same speed as before.
The importance of problems is now visible to the naked eye. And they can not be fixed by simply throwing everything away and starting a project from scratch. We need to perform many tasks on refactoring code, and for these tasks we need time, which we have to ask the customer. Often this time will not be allotted to us: we in fact ask for time in order to correct our own code, for the development of which time has already been allocated and which we have previously stated ourselves.
Even if time is allotted, do not expect a quick result. We will be able to fix only those problems that we see right now and only to the extent for which the allotted time is enough (and there will not be a lot of it). We have written this bad code for many weeks (or months), and we definitely won’t have the same amount of time to rewrite this code.
This is not the way we need to go. Long periods of refactoring do not bring a large and immediately visible benefit to the project. They are very difficult to sell to the customer, because he will not see for what functionality he is asked for money. That is a bad idea. What to do?
Simplify! Upon receipt of each next task, we outline a plan for its implementation. If, in the course of this plan, we run into the “gum” of technical debt, then the task of refactoring it becomes part of the implementation of the current feature. Of course, we cannot immediately take up all the bad places in the code. But this need not be done! If during the implementation of any new functionality you correct more old “blots” than create new props and crutches, the overall quality of the project code will increase. Next time, when working on a new task, you suddenly have to turn to an already corrected place - you will be pleased to note that it no longer requires polishing with a file, but it works well at once and looks nice. This is how software development happens.
Perhaps the development of each individual feature in this way will take a little longer than you originally expected. But the development of the entire set of functionality with this approach will take less time, because at the last stages before deadline you will have the opportunity to work with a relatively clean code base, adding new functionality will not take time to search for workarounds. In addition, this personal approach to your development will have a good effect on the performance of the whole team.
Repetition is the mother of learning. With each new feature, we make the code a little cleaner. Just a little bit, but every time. Many times "slightly" at some point will allow you to write with a calm soul a new, well-functioning feature, for which you are not ashamed, instead of tearing your hair out and struggling with the desire to remove all this garbage at all.
The moment of awareness of the usefulness of continuous refactoring is not as far as you might think. Some people began to notice him by the end of the same sprint in which they began to use this approach. The forces of continuity and incrementality of the process make themselves felt very quickly. From a certain moment, the execution of a new task with refactoring starts to take less time than to perform the same task without refactoring (due to the time spent earlier on improving the accompanying code).
')
The work goes better, the code becomes cleaner and we give the customer more functionality than we could before. All win.
So refactoring is not a task in Backlog, it is part of every task in it.
Source: https://habr.com/ru/post/316236/
All Articles