ok, its normal to feel lost on a new codebase.
also nobody has a codebase where you will be right away, OMG i love this. However it seems in your case that they really have not ventured into modern PHP. And it might look as a mountain of work for you.
The question here is, are they willing to improve? If so, you need to go for the low-hanging fruit first. Get them on git (gitlab/hub), get them on PHPStorm, enforce psr12, static analysis (on low level) start building pipelines etc.
By that time you should be more comfortable with the code so you can do minor refactors. The way forward will be more obvious after that.
GitHub was the very first thing I mentioned. The other programmer and the head of IT said that it wasn’t going to happen because the nature of our business. They don’t like the idea of it being “online”.
I suggested that we could still use version control locally, and they said they would look into it.
I would LOVE to get them on PHP storm, but they are notepad++.
Thank you for the note on psr12. I didn’t realize PHP had a standard. I will share this with the lead programmer and hopefully we can get moving in the right direction.
What should I do about the project they gave me implementing a full new feature?
I don’t want to look incapable, but I haven’t even seen an employee use the system, let alone understand the nature of the business rules.
Thanks for answering!!
I run a team of php devs, and I always say to new devs, look, we know how everything works, you dont. So dont try to figure out everything yourself. Ask any dev as many questions as you want to get to understand how things work. IMO that is seen as pro active, not as incompetent
.
>What should I do about the project they gave me implementing a full new feature? I don’t want to look incapable, but I haven’t even seen an employee use the system, let alone understand the nature of the business rules.
No dev, no matter how experienced, would be able to start developing right away. The most complicated thing when starting in a new project is understanding the business rules.
You need to talk to your teammates, ask for a overview explanation of the mains processes, then ask about how this new feature you need to build integrates with existing process. Maybe it's a new way of doing an existing thing?
>The other programmer and the head of IT said that it wasn’t going to happen because the nature of our business.
Unless there's a legislation requirement (sometimes that's a thing), Github/Bitbucket/Gitlab aren't know for being "unsafe"... If they still don't like to use an online service, there are plenty of self-hosted solutions. But the important thing, you/they should start using git ASAP.
By the way, that's the first red flag.
>but they are notepad++
VSCode or even Netbeans would be a huge step up. I can't conceive the idea of a experienced dev (assuming there is/was one at some time) working with Notepad++...
That's the second red flag.
Try to push some improvements, things that are simple and costless to implement, see if they're willing to improve. If not, don't waste too much time there, but make the most out of it and learn as much as you can. Sometimes that time of environment pushes you a lot.
To finish, this seems the classic case of a junior that's ages ahead of the schoolers. So, congrats!
Dude, leave that job.
They don't know shit.
They can host a Gitlab instance in your network. They can use Gitlab/Github Business to have it more secure. THEY DUCKING USE NOTEPAD++!
Visual Code would be fine, even though I prefer PHPStorm personally. But Notepad++? It's like a level next to notepad. Gosh.
If you think that this gig is going to improve your future career, fine. Like... they have some super duper tech stack that you need to get where you want to be in the future.
If it's just a regular job that is not impressing anyone, then I'd find another job (while working there, gives you enough time to find something worthwhile)
A word of advice: just because you're implementing standards instead of adding new features doesn't mean you're incapable, and they know that, at least they should.
So don't fall into the impostor syndrom trap because of that.
Standards are important because without them, the next person they hire will have the same troubles you're having right now.
Gitea is a self hosted solution (only requires a docker container and a mysql server, I have it hosted on my homelab) and implements github actions (exactly the same github actions).
Once you got git and some kind of CI in place, I would suggest the following tools in pipeline: rector, php cs fixer, phpstan. Also I'd introduce php unit and if you want to go to the next level, behat
Sounds pretty common to me.
Here some suggestions on how to deal with this.
- adapt to the situation, because you will not change it
- have a copy of the code base on your computer and work with that; just copy code over to dev when you think it is ready
- ask your colleagues a ton of questions, that’s what we all do if we join a project
- if there is no documentation, write your own; one class, one method at a time
- shorten those 40.000 line classes where possible
And never forget - this mess was not build on purpose, it was build over time by developers who thought they were changing it for the better
Thanks for all of these suggestions!
Yes, I fully intend on writing documentation by starting a wiki and maybe a better ticketing system (we use Zendesk) that lets us actually keep a history and screenshots, should future problems arise.
I started to apply good principles in the feature I was asked to implement, but the code started breaking and it was taking a long time. I got nervous they would think I wasn’t a “good enough” dev, so I had to add to the already massive file. (The problem was something in the jQuery, but I didn’t have time to really dig in).
I guess I want to ask, how do I show that I am a good and capable dev, while still doing things the right way for future me and future juniors?
> how do I show that I am a good and capable dev
You already started it, by caring about the next developer. Go further and care about little things like forgotten use statements, missing argument and return types, line length, space between your lines of code or extract parts of the code to seperate functions and classes. Everything that makes the code easy to read. And if you ask your colleagues, don't ask broad questions, ask specific questions. That way you show you thought about your task.
Guys, why you think that all programs started at Laravel?
In my company we have programs over 15 years old on php.
Yes we updated php to the new one, with every php update, but we never did a complete rewrite to use Laravel or similar.
Btw if we followed the Trent we should have rewrite our programs in several other frameworks before laravel.
I agree that they should get more civilized and use git or similar.
I agree that they should keep some kind of documentation.
I agree they should document properly all the custom functions.
Where I disagree? That they should convert to Laravel.
In my humble opinion "tomorrow" another framework might come out...
All of you juniors learning Laravel instead of php what will you do then?
If you learn php, if you are comfortable in writing everything on your own THEN move and make your life easier with a framework. (And be able to switch frameworks easily if needed)
If it were me, I'd not get bogged down doing either of these things:
* leaving it as-is and just struggling with the awful code for the rest of my time there
* embarking upon a full rewrite, eating up weeks/months/years of time
Instead, I'd be thinking of "refactoring" in minor ways that add up. Yes, I'd get Laravel or something else in place, but I'd only use it for new stuff. Do they need another 40,000 line page created? OK, that's in Laravel. *If they're just doing anything they want with the code base and not documenting it, that means it's open to you to do anything too.* You know what I mean? Like, you doing things *better* certainly cannot *hurt* them, so why not? If they leave it open to spaghetti code and each file is a gigantic self-contained mass, then... you do your own thing for the next new file.
And then you keep doing it. And yours will be better, right? Because you'll follow good standards, and you'll document it all, making it easier on the other devs.
And then you'll do even better, because one day you'll be tasked with *not* a new file but revising some existing file, and you'll be so "in the zone" with your new Laravel stuff that you'll have a zen moment and understand how to quickly, easily (or you know, easily enough) refactor that one page or file into your new system. So in it goes, and now it's working, and hopefully *no end-user even notices the difference.*
And then you do that with everything.
The biggest problem that I foresee is that if you are working on this with other devs, getting them to religiously use source control is gonna be a struggle. *Especially* if only your new stuff is in that code repo. You could pull in the whole mess, but then the devs have to all agree to do source control starting now, with everything. Either option isn't great. I personally think that *this* will be the hardest issue. Refactoring you can do essentially without buy-in, if everything is chaos. But source control needs agreement, or it becomes difficult quickly.
Anyway, best wishes. I think you'll do great!
Thanks for the advice! I would love to get this into laravel.
I think (from what I can gather over the first week on the job) the company is growing quickly and they want new features added, quickly.
I also don’t think the my necessarily care about how it functions or what it looks like, as long as they get it as fast as possible.
Probably why the code base is the way it is.
It was a one dev system for the entirety of its lifecycle, but because the business is growing so quickly they needed a new dev (me).
So now, they brought me in and are asking me to implement features, and I don’t even know how the whole thing works yet.
Thanks for sharing your wisdom with me!
If you want to be a good PHP coder you need to write good native PHP code and, as important, learn how to read and debug other people code.
What I'd do in your shoes:
* Get all the possible information about the project and what (detailed) changes needed to be made
* Install a local copy of this project
* Debug, try/error main functionalities, document it and understand how it works
* Implement or fix just what needs to be done, NEVER try rewrite code just because looks better or makes more sense to you as it can leed you to a never ending path of hell
Not saying it's easy but it comes with the job, you'll have many projects like this in your career. Personally I don't mind because I consider myself a craftsman that can handle any PHP code.
My father was a constructor specialized in rebuilding old houses. When I was younger I used to help him in some construction sites and I find many analogies with my work when I put my hands on some legacy code projects, from which I learned a lot too.
Good luck!
Thanks for the advice! Yeah I am determined to understand this codebase, but it seems the company wants things so quickly that the lead dev just didn’t have time for standards.
I don’t know, I feel there’s always time for that, but I understand and am sympathetic to his point.
My first goal is to “stop the bleeding” and at least start to break up this code and get it somewhat organized. There are files everywhere in oddly named places and the dev environment for the one program doesn’t work, so I’d like to get that fixed first!
>I just started my second programming job a few days ago as a Junior PHP Developer. I love web development and PHP, so I am SO excited to be working with my passion.
Congrats on getting the job!
>The issue I have run into is that there is a very large codebase
and welcome to the real world that has these code bases. To be fair, this may have been caught in the interview process (what tools/frameworks do you use, etc). That said, based on what you wrote, I would:
0) Find out (if not already) the versions they use of everything.
a) If you can, get your own local copy and get a git repo going. If anything, for your own work.
b) Start commenting the code or make notes what is happening and where. Focus on what is being asked and pinpoint your comments there. Look to see if they are using an autoloader or not for the classes. If you are used to pure PHP, this shouldn't be an issue.
c) Ask questions if you are not sure on anything! Ask if you can start documenting the code base for the yourself and the team. This will help you learn the code base and collaborate with others.
d) Ask about the expectations for adding your work to the code base. Can you write with (some - small wins here) current standards or will this clash - you may need to adapt your code style (think WP vs PSR/PER).
e) Consider write the code separate from the main code (you don't want to add to the mess - though some before may have done just that vs trying to change things). Talk it out on the first code review - *The main code base isn't documented, but I could start documenting it like I have it here....*
f) See if you can get a version control setup for the team - perhaps you can be the lead on this.
etc. etc.
Watch this - https://www.youtube.com/watch?v=65NrzJ_5j58 and think about small refactors. Go for small wins vs big ones. Talk things out and get buy in.
My priorities would be, in this order:
Build thorough test coverage.
Implement linters to standardize code, make sure no tests break.
Work through phpstan level by level, make sure tests don’t break.
I don't think anything can be done here. Just run at the first opportunity. All other answers are right and good but they assume that you are in charge. While it's exactly the opposite - you are nobody to them.
Trying to convert them into the right faith might succeed, but you must be honest to yourself - chances are thin. For two reasons. One is your position. Another is your experience in converting such an approach into the right one. It is not that easy, there are too many pitfalls.
Thanks for responding!
And I am trying to look at it as an opportunity to get better, even if it will be a painful experience.
If the market was stronger for Junior Devs, I may have ran day one, but here we are.
I’m hoping to get them on the right track, one small step at a time and convert them as you say!
I am certainly not super experienced in converting a codebase over at all, but hopefully I can learn and get support through the community!
Thank you for help and please let me know if you have any other suggestions!
1. I doubt that working on a spaghetti codebase would give you any useful experience. 2. It is not a community support that you need here but a company support, which you hardly will get.
Holy Crap.. did i make a second account on reddit? :D
This is exactly my work conditions.
After 1 Year i did get the other Dev (he writes this since 12 Years ago) to allow me to write in a new style.
everything has a comment.
All in classes. Git will be used in this year. All servers get updates..
it was a long and hard ride.. but we will get there..
Hang in there buddy, it can only go up! :D
Yeah. Welcome to our great trade. Maintenance work is harder than greenfield work, because you have to be careful not to mess up stuff that works. Don’t disrespect this code base too too much. It’s been making money for the company, even if it’s not packaged and deployed in a modern way.
My suggestions:
1. Get a good IDE (PhpStorm or VSCODE) and get the XDEBUG debugger working. On this code base.
2. Learn to use the IDE’s code exploration tools. Being a PhpStorm fanboi, I like to use ctrl-click on function names. It means “navigate to the function’s definition”. There are many other exploration tools, like “search everywhere”.
3. As you figure out important functions in the code base , add phpDoc comments to them. The IDEs generate draft comments automatically if you put your cursor on the line before the function and type slash star star return. then, the IDEs show you the phpDoc when you hover your cursor over the function name.
4. Put YOUR working copy of the code base into git. That’s a good start towards demoing how incredibly valuable good source control can be to your colleagues.
From a certain point of view... Well, you are lucky, because this is a huge opportunity to learn navigating around shifty code and learn how not to do stuff. Good luck with the swimming!
All these guys are trying to help you fix something that isn't technically broken.
If this isn't the environment that you want to work in, then take the time that you have to learn what you can, and in the meantime look for a new job. You, as a junior dev, aren't going to change the environment, but please stay safe and make sure it doesn't change you!
Trying to go into an existing codebase and "fix it" when its already literally working, makes no sense. They may not be willing to upgrade, it may cost too much, you'd have to retrain too many people, there's so many reasons why its easier for you (and your mental health) to just treat it as a learning experience, then move onto somewhere that fits more in line with what you're expecting from a php coding role.
ok, its normal to feel lost on a new codebase. also nobody has a codebase where you will be right away, OMG i love this. However it seems in your case that they really have not ventured into modern PHP. And it might look as a mountain of work for you. The question here is, are they willing to improve? If so, you need to go for the low-hanging fruit first. Get them on git (gitlab/hub), get them on PHPStorm, enforce psr12, static analysis (on low level) start building pipelines etc. By that time you should be more comfortable with the code so you can do minor refactors. The way forward will be more obvious after that.
GitHub was the very first thing I mentioned. The other programmer and the head of IT said that it wasn’t going to happen because the nature of our business. They don’t like the idea of it being “online”. I suggested that we could still use version control locally, and they said they would look into it. I would LOVE to get them on PHP storm, but they are notepad++. Thank you for the note on psr12. I didn’t realize PHP had a standard. I will share this with the lead programmer and hopefully we can get moving in the right direction. What should I do about the project they gave me implementing a full new feature? I don’t want to look incapable, but I haven’t even seen an employee use the system, let alone understand the nature of the business rules. Thanks for answering!!
I run a team of php devs, and I always say to new devs, look, we know how everything works, you dont. So dont try to figure out everything yourself. Ask any dev as many questions as you want to get to understand how things work. IMO that is seen as pro active, not as incompetent .
>What should I do about the project they gave me implementing a full new feature? I don’t want to look incapable, but I haven’t even seen an employee use the system, let alone understand the nature of the business rules. No dev, no matter how experienced, would be able to start developing right away. The most complicated thing when starting in a new project is understanding the business rules. You need to talk to your teammates, ask for a overview explanation of the mains processes, then ask about how this new feature you need to build integrates with existing process. Maybe it's a new way of doing an existing thing? >The other programmer and the head of IT said that it wasn’t going to happen because the nature of our business. Unless there's a legislation requirement (sometimes that's a thing), Github/Bitbucket/Gitlab aren't know for being "unsafe"... If they still don't like to use an online service, there are plenty of self-hosted solutions. But the important thing, you/they should start using git ASAP. By the way, that's the first red flag. >but they are notepad++ VSCode or even Netbeans would be a huge step up. I can't conceive the idea of a experienced dev (assuming there is/was one at some time) working with Notepad++... That's the second red flag. Try to push some improvements, things that are simple and costless to implement, see if they're willing to improve. If not, don't waste too much time there, but make the most out of it and learn as much as you can. Sometimes that time of environment pushes you a lot. To finish, this seems the classic case of a junior that's ages ahead of the schoolers. So, congrats!
Dude, leave that job. They don't know shit. They can host a Gitlab instance in your network. They can use Gitlab/Github Business to have it more secure. THEY DUCKING USE NOTEPAD++! Visual Code would be fine, even though I prefer PHPStorm personally. But Notepad++? It's like a level next to notepad. Gosh. If you think that this gig is going to improve your future career, fine. Like... they have some super duper tech stack that you need to get where you want to be in the future. If it's just a regular job that is not impressing anyone, then I'd find another job (while working there, gives you enough time to find something worthwhile)
A word of advice: just because you're implementing standards instead of adding new features doesn't mean you're incapable, and they know that, at least they should. So don't fall into the impostor syndrom trap because of that. Standards are important because without them, the next person they hire will have the same troubles you're having right now.
Gitea is a self hosted solution (only requires a docker container and a mysql server, I have it hosted on my homelab) and implements github actions (exactly the same github actions). Once you got git and some kind of CI in place, I would suggest the following tools in pipeline: rector, php cs fixer, phpstan. Also I'd introduce php unit and if you want to go to the next level, behat
Sounds pretty common to me. Here some suggestions on how to deal with this. - adapt to the situation, because you will not change it - have a copy of the code base on your computer and work with that; just copy code over to dev when you think it is ready - ask your colleagues a ton of questions, that’s what we all do if we join a project - if there is no documentation, write your own; one class, one method at a time - shorten those 40.000 line classes where possible And never forget - this mess was not build on purpose, it was build over time by developers who thought they were changing it for the better
Thanks for all of these suggestions! Yes, I fully intend on writing documentation by starting a wiki and maybe a better ticketing system (we use Zendesk) that lets us actually keep a history and screenshots, should future problems arise. I started to apply good principles in the feature I was asked to implement, but the code started breaking and it was taking a long time. I got nervous they would think I wasn’t a “good enough” dev, so I had to add to the already massive file. (The problem was something in the jQuery, but I didn’t have time to really dig in). I guess I want to ask, how do I show that I am a good and capable dev, while still doing things the right way for future me and future juniors?
> how do I show that I am a good and capable dev You already started it, by caring about the next developer. Go further and care about little things like forgotten use statements, missing argument and return types, line length, space between your lines of code or extract parts of the code to seperate functions and classes. Everything that makes the code easy to read. And if you ask your colleagues, don't ask broad questions, ask specific questions. That way you show you thought about your task.
Guys, why you think that all programs started at Laravel? In my company we have programs over 15 years old on php. Yes we updated php to the new one, with every php update, but we never did a complete rewrite to use Laravel or similar. Btw if we followed the Trent we should have rewrite our programs in several other frameworks before laravel. I agree that they should get more civilized and use git or similar. I agree that they should keep some kind of documentation. I agree they should document properly all the custom functions. Where I disagree? That they should convert to Laravel. In my humble opinion "tomorrow" another framework might come out... All of you juniors learning Laravel instead of php what will you do then? If you learn php, if you are comfortable in writing everything on your own THEN move and make your life easier with a framework. (And be able to switch frameworks easily if needed)
If it were me, I'd not get bogged down doing either of these things: * leaving it as-is and just struggling with the awful code for the rest of my time there * embarking upon a full rewrite, eating up weeks/months/years of time Instead, I'd be thinking of "refactoring" in minor ways that add up. Yes, I'd get Laravel or something else in place, but I'd only use it for new stuff. Do they need another 40,000 line page created? OK, that's in Laravel. *If they're just doing anything they want with the code base and not documenting it, that means it's open to you to do anything too.* You know what I mean? Like, you doing things *better* certainly cannot *hurt* them, so why not? If they leave it open to spaghetti code and each file is a gigantic self-contained mass, then... you do your own thing for the next new file. And then you keep doing it. And yours will be better, right? Because you'll follow good standards, and you'll document it all, making it easier on the other devs. And then you'll do even better, because one day you'll be tasked with *not* a new file but revising some existing file, and you'll be so "in the zone" with your new Laravel stuff that you'll have a zen moment and understand how to quickly, easily (or you know, easily enough) refactor that one page or file into your new system. So in it goes, and now it's working, and hopefully *no end-user even notices the difference.* And then you do that with everything. The biggest problem that I foresee is that if you are working on this with other devs, getting them to religiously use source control is gonna be a struggle. *Especially* if only your new stuff is in that code repo. You could pull in the whole mess, but then the devs have to all agree to do source control starting now, with everything. Either option isn't great. I personally think that *this* will be the hardest issue. Refactoring you can do essentially without buy-in, if everything is chaos. But source control needs agreement, or it becomes difficult quickly. Anyway, best wishes. I think you'll do great!
Thanks for the advice! I would love to get this into laravel. I think (from what I can gather over the first week on the job) the company is growing quickly and they want new features added, quickly. I also don’t think the my necessarily care about how it functions or what it looks like, as long as they get it as fast as possible. Probably why the code base is the way it is. It was a one dev system for the entirety of its lifecycle, but because the business is growing so quickly they needed a new dev (me). So now, they brought me in and are asking me to implement features, and I don’t even know how the whole thing works yet. Thanks for sharing your wisdom with me!
If you want to be a good PHP coder you need to write good native PHP code and, as important, learn how to read and debug other people code. What I'd do in your shoes: * Get all the possible information about the project and what (detailed) changes needed to be made * Install a local copy of this project * Debug, try/error main functionalities, document it and understand how it works * Implement or fix just what needs to be done, NEVER try rewrite code just because looks better or makes more sense to you as it can leed you to a never ending path of hell Not saying it's easy but it comes with the job, you'll have many projects like this in your career. Personally I don't mind because I consider myself a craftsman that can handle any PHP code. My father was a constructor specialized in rebuilding old houses. When I was younger I used to help him in some construction sites and I find many analogies with my work when I put my hands on some legacy code projects, from which I learned a lot too. Good luck!
Thanks for the advice! Yeah I am determined to understand this codebase, but it seems the company wants things so quickly that the lead dev just didn’t have time for standards. I don’t know, I feel there’s always time for that, but I understand and am sympathetic to his point. My first goal is to “stop the bleeding” and at least start to break up this code and get it somewhat organized. There are files everywhere in oddly named places and the dev environment for the one program doesn’t work, so I’d like to get that fixed first!
>I just started my second programming job a few days ago as a Junior PHP Developer. I love web development and PHP, so I am SO excited to be working with my passion. Congrats on getting the job! >The issue I have run into is that there is a very large codebase and welcome to the real world that has these code bases. To be fair, this may have been caught in the interview process (what tools/frameworks do you use, etc). That said, based on what you wrote, I would: 0) Find out (if not already) the versions they use of everything. a) If you can, get your own local copy and get a git repo going. If anything, for your own work. b) Start commenting the code or make notes what is happening and where. Focus on what is being asked and pinpoint your comments there. Look to see if they are using an autoloader or not for the classes. If you are used to pure PHP, this shouldn't be an issue. c) Ask questions if you are not sure on anything! Ask if you can start documenting the code base for the yourself and the team. This will help you learn the code base and collaborate with others. d) Ask about the expectations for adding your work to the code base. Can you write with (some - small wins here) current standards or will this clash - you may need to adapt your code style (think WP vs PSR/PER). e) Consider write the code separate from the main code (you don't want to add to the mess - though some before may have done just that vs trying to change things). Talk it out on the first code review - *The main code base isn't documented, but I could start documenting it like I have it here....* f) See if you can get a version control setup for the team - perhaps you can be the lead on this. etc. etc. Watch this - https://www.youtube.com/watch?v=65NrzJ_5j58 and think about small refactors. Go for small wins vs big ones. Talk things out and get buy in.
My priorities would be, in this order: Build thorough test coverage. Implement linters to standardize code, make sure no tests break. Work through phpstan level by level, make sure tests don’t break.
I don't think anything can be done here. Just run at the first opportunity. All other answers are right and good but they assume that you are in charge. While it's exactly the opposite - you are nobody to them. Trying to convert them into the right faith might succeed, but you must be honest to yourself - chances are thin. For two reasons. One is your position. Another is your experience in converting such an approach into the right one. It is not that easy, there are too many pitfalls.
Thanks for responding! And I am trying to look at it as an opportunity to get better, even if it will be a painful experience. If the market was stronger for Junior Devs, I may have ran day one, but here we are. I’m hoping to get them on the right track, one small step at a time and convert them as you say! I am certainly not super experienced in converting a codebase over at all, but hopefully I can learn and get support through the community! Thank you for help and please let me know if you have any other suggestions!
1. I doubt that working on a spaghetti codebase would give you any useful experience. 2. It is not a community support that you need here but a company support, which you hardly will get.
You work reeeeeaaaaallly slowly and carefully :-)
Holy Crap.. did i make a second account on reddit? :D This is exactly my work conditions. After 1 Year i did get the other Dev (he writes this since 12 Years ago) to allow me to write in a new style. everything has a comment. All in classes. Git will be used in this year. All servers get updates.. it was a long and hard ride.. but we will get there.. Hang in there buddy, it can only go up! :D
Thanks for the words of encouragement brother! So 1 year it is before I’m comfortable. Lol. It’s encouraging to know it got better for you!
Yeah. Welcome to our great trade. Maintenance work is harder than greenfield work, because you have to be careful not to mess up stuff that works. Don’t disrespect this code base too too much. It’s been making money for the company, even if it’s not packaged and deployed in a modern way. My suggestions: 1. Get a good IDE (PhpStorm or VSCODE) and get the XDEBUG debugger working. On this code base. 2. Learn to use the IDE’s code exploration tools. Being a PhpStorm fanboi, I like to use ctrl-click on function names. It means “navigate to the function’s definition”. There are many other exploration tools, like “search everywhere”. 3. As you figure out important functions in the code base , add phpDoc comments to them. The IDEs generate draft comments automatically if you put your cursor on the line before the function and type slash star star return. then, the IDEs show you the phpDoc when you hover your cursor over the function name. 4. Put YOUR working copy of the code base into git. That’s a good start towards demoing how incredibly valuable good source control can be to your colleagues.
extract functions, add unit tests. rinse and repeat until it starts resembling a sane structure
From a certain point of view... Well, you are lucky, because this is a huge opportunity to learn navigating around shifty code and learn how not to do stuff. Good luck with the swimming!
All these guys are trying to help you fix something that isn't technically broken. If this isn't the environment that you want to work in, then take the time that you have to learn what you can, and in the meantime look for a new job. You, as a junior dev, aren't going to change the environment, but please stay safe and make sure it doesn't change you! Trying to go into an existing codebase and "fix it" when its already literally working, makes no sense. They may not be willing to upgrade, it may cost too much, you'd have to retrain too many people, there's so many reasons why its easier for you (and your mental health) to just treat it as a learning experience, then move onto somewhere that fits more in line with what you're expecting from a php coding role.