Is it easier to refactor or rewrite 10,000 lines?

Question

JavaScript

I got a back on express with not just terrible, but just terrible code. I have no idea what God's powers he basically works. To make it clearer, the methods there take up 100 or even 200 lines, which can be reduced to 30. But this is half the trouble, it also happens that 3 methods do the same thing, and differ in ~ 5-10 lines. The documentation is completely inconsistent with what routes return. When I first launched the project, the web storm threw me 200 warnings per file with 1k lines of code.
What to do with all this?

To get deeper into it with my head, I will give you a small piece of code.

if (user !== undefined) {
   user = undefined 
} else {
   user = undefined
}

Answer 1

Usually code of this quality is easier to rewrite. There are additional advantages:
- you will understand in detail how the project works and what it does;
- you will probably find and fix some bugs along the way.
But this is individual, in general. It’s easier for someone to incrementally refactor; personally, it’s easier for me to write from scratch in such a situation, focusing on the existing code, but critically evaluating it.
This also depends on the size of the project, on its overall complexity, on the load on developers (is it possible to stop active development for a while). 10k lines, in principle, is not a very large size.

Answer 2

I think in this case refactoring is the census of the project.

Answer 3

The difference in a few lines of code and the lack of separation into layers can mean two things.
First, quick Wishlist in the changes of the project and the speed with which it was written. Second, the developer level. Alas, from the practice of reviewing projects on a node, I can say that at least every second project is a bicycle.

Answer 4

And the unequivocal answer to the question is no, unless there is a direct task for refactoring.
Since it's a common thing to underestimate complexity + maybe this system works in production and people work with it.
That is, the question of temporarily shutting down the system is not worth it at all. Applying large unstable changes that can bring down the system is also not an option.
If you do everything in the normal way, you need to know the input and output parameters of the modules or cover the modules for subsequent refactoring with tests to make sure the changes are correct.
I would recommend incremental improvements and decomposition. Shit code in 1 place, new and refactored modules in another.
If the criteria for system availability are of no interest to anyone, then you can just screw up your code as you see fit while there is a budget.