Most developers tend to see such tasks as architectural ones, while they are administrative in nature. To implement this properly, you should change workflow, not code! Consider, what would happen, if after all your fixes, old team would come back and continue their old ways? Most of your work would be wasted immediately!
Note that your command won't be able to achieve improvement without support from stakeholders. In most cases, this means that you are asking for impossible, as team leader is unable to communicate concept of technical debt to product owner. Your task as a developer is to collect objective proof, that current architecture decreases project's business value by slowing down progress and introducing bugs.
Do not change anything without a reason. Never start any change just because you don't like current implementation.
Introduce policies enforced by team leader and followed by everyone:
- Continuous integration and pre-validation are not an option - they are
life support.
- Code review - no change should be merged until it
passes whole test suite and a review by another developer.
- Every change should improve architectural properties of code base. This implies any refactoring necessary to achieve a given task, but nothing more. The exact ways to so could be obtained from other answers, but should not. It's your team responsibility to both improve current design and keep change scope minimal. In particular, most integration tests do not require major rewrite, and testing should not be a reason for touching thousands of files introducing unit testability.
- Every change should introduce more passing relevant tests (any kind of
automated tests, not necessarily unit).
- Every bug fix should include a regression test failing before change and passing after it.
- With every code review , discuss most important decisions taken and reuse
them in following reviews. Do not try to document them, it does not
work, just build up your team's synergy and propagate it using
reviews. Decisions may include some architectural changes proposed in
other answers, exact result is irrelevant, just try to make use of
your respected members experience.
These requirements enforce experience propagation and facilitate consistency in your code base. Unfortunately they rely highly on personal experience of your team members, so team success will be limited by your best senior. This is unavoidable, but can alleviated a bit by learning best practices form outside sources like this SE.
This does not mean, you are to leave the mess as is. For every request to change functional behaviour or fix a bug, investigate a scope of change. Scope should include necessary refactoring that would leave behind a cleaner state and good test coverage. Such scope would be big as long as code base is a mess. It will reduce in size if you properly follow boy-scout principle every time. The key to success is to reuse assets you already have, introducing new value incrementally.
