Ask HN: Is this Symfony PHP project garbage?

1 points by morenatron ↗ HN
I am working on a new codebase as a frontend developer and the backend is in Symfony PHP. I haven't worked with Symfony before but this project seems to be poorly maintained. Help me get a grasp of whether or not this is normal or total garbage.

They are using really outdated dependencies. Symfony itself is in 5.4 and they have 368 deprecations and some critical vulnerabilities. The project is 10+ years old and there are no software tests at all. Everything is manually tested.

And I did a PHPStorm Error Inspection and it found 650+ Errors, 1,4k warnings and 140k+ weak warnings. 520 Errors are because of "Undefined symbols" though

The project seems to be poorly maintained to me and there are runtime errors and downtimes but the backend team always accuses the hosting service for the downtimes.

is this normal or not, that is the question

10 comments

[ 3.3 ms ] story [ 33.6 ms ] thread
It's sort of normal. Legacy software can be (re)defined as "what runs in production." It generates revenue but has accreted significant tech debt.

Not saying normal isn't dysfunctional--no tests at all is a little insane. At the same time, it enabled the business.

With better tooling now, of course some issues are more obvious. Maybe the codebase has its own patterns or way of doing things; some fixes might be more risky than others.

There are upgrade branches but somehow they are stale and not worked on anymore. Probably so hard to and test everything manually that they stoped trying at all. How would you go on a project like this if you were to be the new lead there?
After buy-in from higher-ups and the associated teams, look at the development cycle and build process, how a change goes from local to production.

Add automation around linting, running the test suite, and build & deployment. A lot of it can go in dark, in case there's concern about blocking urgent things. Lay down a skeletal pipeline.

Create a couple template projects, for front- and backend, so future projects can start at the highest quality bar and with latest dependencies.

Partner with QA to collect and document test scenarios. On the frontend, at least you'll be able to mock or stub the backend.

Eventually, you'll want this system to block merges and deployments based on agreed-upon criteria. Exceptions can be made, so long as it's documented.

Throughout, it would be nice to add tests. It's an opportunity to understand the domain with fresh eyes as well.

Add mutation testing too.

the errors are most likely coming from the custom code, you might need to update those yourself
What is the business case for your time focused on the quality of Symfony? Assuming it is total garbage is not unreasonable as dealing with total garbage is a reasonable reason to pay you for working with Symfony.

The engineering question is "Is Symfony good enough?" There are money and staffing and personalities that go into the answer. For example insuring against security problems might easily be cheaper than the costs and risks of pursuing alternatives.

The ability to work in such contexts is why senior staff are senior staff. Good luck.

thanks mate, yeah I won't go into the rabbit hole of questioning symfony. I don't want to halt development just want to move on with a stable release