> I started "repairing" the project but there're no tests to check whether my adjustments are correct.
First you need to discover all associated business requirements. You need to create all the missing tests, but you cannot do that without knowledge of the business requirements. Get these requirements and get them in writing. Find them. If you cannot do this stop. Stop now.
> I'm so frustrated and depressed by it.
This is ultimately the difference between a newb, a mid, a senior, and a super duper ninjitsu rockstar.
A newb will just accept bad code and work on top of it with their own flavor of bad code. A newb doesn't know any better and everything is frustrating all the time even if the code were awesome.
A mid has just enough experience to be dangerous. Sometimes a mid suffers from Dunning-Kruger Effect in that their personal perception of the existing code isn't how they would do it and their way is soooooo superior. The mid level developers who don't suck prioritize tests and security above everything else. They know they aren't fabulous architects, but they also have some idea of where code applies known bad practices and known best practices and can work from there. A good mid isn't going to rewrite the code base, because the risk is too high. Instead they will make the most minor of best practice corrections confined to the areas they have to touch anyways.
A good senior understands concepts like automation, graceful degradation, progressive enhancement, scope, recursion, and so forth. They know how to make the code work for them. It isn't about writing a few lines of code to solve a single business requirement. It is about writing a few extra lines of code to allow the current business requirement to scale to the next thing so less work must be performed in the future and less regression occurs when the business direction shifts.
The super awesome developer takes automation to a whole new level. Documentation is automated and therefore always up to date and accurate. Debugging tools are already embedded as part of the validation process so that when validation fails you spend less time on research or resolution. Dependencies are few and well managed, because nothing pisses people off more than corruption from outside the code you own. In the end top developers value the time of other developers more than anything else and will write their code accordingly. It isn't so much about the readability of the code as it is speed of maintenance cycles moving forward.
If your job is actually important to you then you will find an acceptable level of risk that you are willing to own and have the time to practice against. Getting this right shows that you care to do the right thing without making an ass of yourself at the company's expense.
First you need to discover all associated business requirements. You need to create all the missing tests, but you cannot do that without knowledge of the business requirements. Get these requirements and get them in writing. Find them. If you cannot do this stop. Stop now.
> I'm so frustrated and depressed by it.
This is ultimately the difference between a newb, a mid, a senior, and a super duper ninjitsu rockstar.
A newb will just accept bad code and work on top of it with their own flavor of bad code. A newb doesn't know any better and everything is frustrating all the time even if the code were awesome.
A mid has just enough experience to be dangerous. Sometimes a mid suffers from Dunning-Kruger Effect in that their personal perception of the existing code isn't how they would do it and their way is soooooo superior. The mid level developers who don't suck prioritize tests and security above everything else. They know they aren't fabulous architects, but they also have some idea of where code applies known bad practices and known best practices and can work from there. A good mid isn't going to rewrite the code base, because the risk is too high. Instead they will make the most minor of best practice corrections confined to the areas they have to touch anyways.
A good senior understands concepts like automation, graceful degradation, progressive enhancement, scope, recursion, and so forth. They know how to make the code work for them. It isn't about writing a few lines of code to solve a single business requirement. It is about writing a few extra lines of code to allow the current business requirement to scale to the next thing so less work must be performed in the future and less regression occurs when the business direction shifts.
The super awesome developer takes automation to a whole new level. Documentation is automated and therefore always up to date and accurate. Debugging tools are already embedded as part of the validation process so that when validation fails you spend less time on research or resolution. Dependencies are few and well managed, because nothing pisses people off more than corruption from outside the code you own. In the end top developers value the time of other developers more than anything else and will write their code accordingly. It isn't so much about the readability of the code as it is speed of maintenance cycles moving forward.
If your job is actually important to you then you will find an acceptable level of risk that you are willing to own and have the time to practice against. Getting this right shows that you care to do the right thing without making an ass of yourself at the company's expense.
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect