How to come to terms with the fact that you can not clean up bad code on the project?

Question

Programming

Not so long ago I started working on a project (back + front). Faced with low-quality code, which is layered over and over again. If on the back I can somehow fix everything that I don’t like, I add documentation, then there are a lot of warnings on the front, nothing is documented, and repeating code is a common thing. Because of this, the files are bloated to several thousand lines. You can’t fix anything, because. works, what to do?

Answer 1

Well, if you are a senior, then take it and fix everything. Oh, you're not a señor? Well then, don't be smart.
Sorry for being rude. Works - do not touch.

Answer 2

Score and get babos

Answer 3

Humble yourself. Refactoring is rarely included in the roadmap of projects for organizations and there are several reasons for this:
- don’t touch it (if you break it, you still have to fix it)
- why pay for the same result (rarely anyone except developers understand why refactoring is needed)
If you can’t put up with it:
- evaluate the changes
- make a list of the pros and risks of this event
- expose it to the decision makers in the organization.
If everything is done correctly and the costs are commensurate for the business, and there are enough pluses, then the idea will be supported. If not, then see item 1

Answer 4

Make a presentation for business management, draw a big scary problem at the beginning and graphs of rising support and maintenance costs, falling conversions, etc. Further slides listing the benefits of refactoring. For example, the introduction of new features will be reduced in time and cost by X and Y, changes to existing features by 5X and 5Y. The cost of maintaining and developing the project will decrease by X times, the cost of testing will decrease by Y. The load and costs of the servers will decrease by X, the page loading speed will increase by Y, the Bounce Rate will decrease to Z, the conversion will increase by at least X, etc., etc. It's good if marketing will watch the presentation together with the business - such things are important for them too. Business understands specific numbers, shit code as a philosophical concept does not.
And most importantly - the presentation should contain a specific proposal. Something like "refactoring will require Min-Max hours, but in order not to stop work, we do it in parallel on the 3rd priority after bug / security fixes and critical new features, allocating X hours a week for this."
The decision maker must understand that this will be profitable for the business in the end, and this will not noticeably affect the current tasks.
PS: this is of course all slightly exaggerated for clarity, but I think the essence is clear.

Answer 5

Quit

Answer 6

Often and a lot to show disdain for front-end developers, on occasion make condescending statements like "Well, it's okay, someday you will become real programmers" and "Yes, I understand, not everyone is given it." To any objections, be sincerely surprised and ask "Why are you offended, you have motley logs and shitty code mixed with spaghetti code." Not the fact that it will help, but at least it's fun. The main thing is not to go too far with criticism, it should look sincerely benevolent.

Answer 7

The correct answer is a combination of the answers already given above (Score and get babos || Quit)

Answer 8

Read the book "working effectively with legacy code" and think about how you can be sure that you won't break anything when refactoring.
If you don't have any of the following try to implement it:
- automated tests
- continuous integration
- code review or pair programming
- automatic refactoring tools
- static checking (typescript, for example
) bad code.
When estimating time to rework, pay attention to the amount of time that occurs due to bad code and the amount of time it takes to responsibly test changes manually.
Try to convince management to implement automated testing based on the facts above. Implement it gradually, first for new code that is easy to test. Once everyone gets used to the tools and starts writing good tests, it's time to cover the old code before making changes.
Something like this

Answer 9

Write an optimizer.