Legacy monster. How do you win?

Question

PHP

Hello.
There is a very large PHP project, which was written by different teams and at different times.
The project began to be written when PHP 5.1 was still there, many tails are drawn from there.
There are SQL injections throughout the project. Everything lies in different files, there is no autoloader as such, the composer project did not even smell it. For hundreds of files, not a single line of the test.
Even fully understanding the structure of the project, I walk through it like a minefield. This monster needs to implement the features that the business wants, but there is no time and resources (human) to rewrite this code, because rewriting is at least 6 months of work for 8 hours.
What you want: implement testing, get rid of SQL injections and clean up the code.
How do you do it?
What is my plan:

• get rid of SQL injections and move the project to PDO
  
• get rid of legacy PHP < 5.2
  
• get rid of echo in functions, make functions return a result of the same type
  
• start writing selective tests for these functions and run them after each feature.
  

If this is mastered, then you can switch to components (SF), but how to make the transition smooth?
And another problem : a lot of dead code, are there any tools that will help you find this code?
In general, I have some experience, but I'm sure that here I will find answers from more experienced developers.

Answer 1

A few platitudes:
1. Business will not give resources to rewrite the project from 0: time and big risks
2. As a rule, business does not care what shit is spinning there, as long as it brings money.
3. If there is more or less adequate guidance, you need to convey the idea of ​​gradual code refactoring as necessary in the process of fixing bugs and developing new features, and thereby argue that it takes more time to develop new features/fix bugs.
How I would do:
1. Tests for existing functions (if possible, I saw methods in controllers with a hodgepodge of model method calls, creating DTOs and saving them through a repository, direct http requests and requests to a 1000+ line database, cover this with tests - impossible)
2. Draw up a refactoring plan, where to note what needs to be done and where, in short, mainly for the development team.
3. Gradually refactor old code as you interact with it.
4. New code - write right away, to interact with the old code where there is no opportunity / time to remake it - make some kind of adapters so as not to distribute toxic code.
5. As an operational measure of protection against SQL injections, you can put something like this https://github.com/nbs-system/naxsi
6. Monitoring code that is not used - pinba.org , as soon as such code is found, delete it permanently (as a last resort there is VCS, I hope). Start with higher level code - controllers for example. Plus, IDEs can help with this and grep.
7. As an option - new features can be cut in a separate project (v2), twist both and gradually switch to a new one, eventually throw out the old one (v1) (and start making a new one - v3 :-) )

Answer 2

Today is a convenient way with web services.
You are looking for functionality that can be separated into a separate component, write a component, change the API in the old code and redirect to a new component.
Repeat until there is nothing left of the old code.
But I agree with RidgeA - the business will not allocate money for this just like that.
First you need to work on this, to convince the business that technical debt is not just empty words and you are getting closer to the blocker, when due to the complexity of the project more and more things are tied not to knowledge of technology, but to key people who simply know the nuances of the project . The dismissal of any such person leads to huge risks for the project as a whole. Suggest options for how it will be slowly removed and slowly move towards it.

Answer 3

It is not very clear from the question what exactly constitutes your interest in refactoring this project.
If you, purely out of the kindness of your heart, want to help the business, then you don’t need to do this, otherwise you will realize the phrase “initiative is punishable” from your personal experience)
Regarding the essence of the issue, I will support those who have already said their opinion: gradual rewriting of the old code in a modern way. The old code works together with the new one, and so on, until there is nothing left of legacy.

Answer 4

We have the following situation:
1) There is an old service written on crutches with a bunch of any slag. It processes the main part of the logic, it is finished, supplemented, and so on.
2) There is an api service on a modern stack, which gradually takes away the functionality from the old monster.
3) All new tasks are put on a new stack in priority.
So gradually the old leaves, the new comes. But again, while we are making api on a modern stack, this stack becomes obsolete, and after some time it will have to be rewritten.
You can do this if it is an it-company.
If this is just some company that does not want to invest in software, then it is better not to engage in altruism, supplement the old stack and that's it. And then the market will decide everything, when it will be easier to rewrite the project than to hire specialists to support it.

Answer 5

https://www.google.com/url?sa=t&source=web&rct=j&u...
Real story presentation

Answer 6

Your job, for which you get paid, is to implement the mechanisms necessary for the business.
On the one hand, to explain to the management that everything is bad in the code means to denigrate the people who wrote this code. In my experience, management is often negative about such antics. In my memory, there was not a single boss who would understand and accept the unfortunate fact that the code is shit.
On the other hand, trying to develop lousy code is also not a pleasant task. And sawing it after school hours means taking time and money from yourself. Spending hours on this, during which the bosses will think that you are working on new functionality, means taking time and money from the company.
In other words, you have two choices. Either the positive aspects (salary there, etc.) outweigh the negative - and you just live with the code base that you have. Or outweigh the negative points - and you quit and go to the company where there are no projects with such bad code. There is no need to build a Robin Hood and Superman in one bottle - at best, no one will simply appreciate this.

Answer 7

• Write integration tests emulating a browser in selenium or phantomjs
  And then it will turn out to trace the dead code. And when editing live code, you will know that most likely it has not become worse.

Answer 8

Well, business should allocate resources to eliminate sql injections, after all, the security of the project, and there you can slowly rewrite the modules that are responsible for these injections, then tell a true story about those. debt and rewrite the rest. And about the comments about the microservice architecture - this is, of course, stylish, fashionable and youthful, but no one makes microservices on modules from legacy code. In general, a fail-safe system for this should be

Answer 9

1. creating a prototype system with an architecture that solves current problems
2. moving to a new architecture using adapters, patterns that allow you to adapt the old functionality to the new one.
3. Writing new functionality in a new style, processing old functionality through refactoring (we throw out the internal without changing the external behavior)

Answer 10

As a rule, building a new project from scratch is easier than trying to fix what is already there.
The best option is to create a parallel project with a common base. And over time jump on it.
PS: SQL injection is directly a request from the outside. And in your case, this is a SQL vulnerability or insufficient filtering of variables

Answer 11

It is not dudat to rewrite from scratch, because the people who make the decisions have no idea what kind of dung is smoldering there in the coda in those Augean stables. For them, everything is simple - it works, so it's normal.
Personally, I used Koterov's wonderful DBSimple library in php projects, it solves the issue of injections in the bud, while using almost the same queries.
Not rewriting at all, most likely, will not work. It is necessary to insist that part of the code still needs to be refactored without fail, otherwise the implementation of features is simply impossible at all, or a lot of things will fall off somewhere and a lot of things in the process.

Answer 12

First, document the business logic. Qualitatively, in detail so, with feeling.
Then go back to ratings. Something tells me that "from scratch" with modern tools will fit in a month of work, including testing and a nice design.

Answer 13

Alexander Byndyu has a good article on this topic https://blog.byndyu.ru/2014/01/blog-post_8.html