What to do if there is a lot of bad code in the project?

Question

Programming

Came to a new project. I was warned that everything is bad there, but to be honest, tears of pain have been covering my eyes for the second week. Controllers for 2k lines, written by a schoolboy js, Hindu copy-paste, storage with select and hellish joins in EF - in neighboring files.
Motivation drops a lot when you look at this. Especially when new tasks are set in the form of "make it work yesterday, don't touch the old code, it works anyway".
How to deal with legacy depression? Leaving the project is, of course, an option, but the last one, in this spirit of answers, is not necessary.

Answer 1

How to deal with legacy depression?

Stop perceiving your work as "working with legacy code" and feel like a developer. Every fool can write a project from scratch, most of them, after a year of development, will get something like what you are describing. There is no need for a lot of mind to make the project worse and worse every day.
You also have the opportunity to get a more interesting experience - daily improvement, every new day - a little less shit code, analysis and correction of other people's errors (this is a very useful experience in terms of self-development, because it is easier to look for flaws in someone else's code, and knowing them we will not do it in your code).
So that's wonderful! This means that you have come across a category of shit code from the category of "just stupid duplication". Such code is very easy to refactor, which means there is no need to cry anymore. Ideally, before refactoring, it would be nice to cover the changed code with application-level tests, just an e2e test that will automatically check for you if you broke something.
And then, we start with structural changes (we take out duplication in private methods, then in services), without changing the code, then we start adding tests neatly and making the code cleaner. Moreover, all this can be spread over time, laying 30% of the development time to eliminate technical debt. like 2 hours a day to make the code better. Of course, you still have to convey this idea to the project owners that by investing now n% of the time, we will get profit in the long run in the form of a reduction in the number of bugs and, as a result, improved processes, predictability, etc.
But this is no longer constructive. If there is just a bunch of jquery noodles, then this is also refactored. Again, we start with structural changes, and there it doesn’t hurt so much.
But refactoring the base will be a little more difficult. For starters, I would get rid of direct work with the database and hide all sql and calls to all storages in our application code (table gateway, row gateway, or even better data mapper, depending on the current situation). And then you can again gradually improve the structure of the database, get rid of the storage, etc.

Answer 2

Sabotage in the form of secret edits to the old code.
And sometimes you can openly. "In order for this new one to work, you need to rewrite this old block of code"))

Answer 3

If you have free time and energy, then definitely rewrite. But most likely you will not have time, so crutches, crutches, crutches ... Or on your own after hours, but no one will pay you for it.

Answer 4

"I came to a new project. I was warned that everything is bad there" - so would you look at these 2 kilostrings on the controller in advance? Were the sources hidden from you?
If you "successfully" support the project, then they will sit on you for a long time and will not give you anything interesting in the future until the project stalls or you pull it out to a good level. I would advise you to find out the details of the development of the project, the need for its application, where did it come from and decide for yourself - do you even need to participate in this project? Although it is sometimes useful to read someone else's code.

Answer 5

Is rewriting everything from scratch not an option?

Answer 6

Break the system into modules (packages, components), and refactor gradually module by module, preferably covering it with tests, then the work process will be visible and, accordingly, the desire does not disappear.