The simplest answer is code reviews (and by code reviews, I really mean "everything related to code changes including the code itself). Obviously this means you'll have to have documentation.
I know places where people are hacking away all over the place, last place my mate worked at every time he came to fix a bug he'd grab the latest code and .. it'd have changed. One team would put changes in this direction, and another team would put changes in a different direction. Sometimes the teams changed direction all by themselves and you ended up with pure chaos where nothing got done to the product, but there was constant and intense code changes.
This is where you need some form of non-developer type change control. If you implement a system where changes are made in a controlled way, and by that I mean anyone can change something, its just that they need some reason to do it and some form of authorisation that its a good thing to progress.
So you can mandate that no change gets applied unless its in response to a change ticket. (anyone can create a ticket describing a problem that needs changing, of course) but these tickets then get assigned to a person or team by someone in charge of product direction - a business analyst or technical design authority or even a team get-together. What's important is that the change gets done in a non-individual way.
Once that is taken care of, someone will go and make changes and then you get them reviewed. This means someone else sees the code but also the ticket changes and documentation. So if you want to change your DB access system, fine... but you need to describe what it is, why it was changed, and how it works now. Without such documentation the change fails its review. Afterwards you can implement internal 'training' such as brown bags or code dojos to ensure the rest of the team gets informed.
Some people will resist this, but they tend to be the ones who churn code constantly, "cutting code" rather than "working on the product". This is an important distinction to make, as developers we can all get caught up in the concept that the code is what's important - its not. The product you're building is what's important and that is much more than just code.
The documentation doesn't have to be extensive, just enough to tell someone else what you've done or how it works. It can be a wiki or even just notes on the tickets - as tickets get old, they'll fade from view and the documentation with them, but this is ok as it means only relevant, current docs gets kept. Alternatively you can have a wiki of components, architecture and usage and that gets kept up to date as part of each code change. Or (my preference) is to store all your technical documentation alongside the code as text documents in a markup format that is built into html by the build server and presented on a web server - so anyone can see the current documentation which is easily updated when code is updated.
A last resort is to get an architecture team who has the responsibility to document the system, but they will also have the power to prevent any changes being made unless the documentation is updated first - many looser teams may not like this more restrictive approach, but if they cannot make it work using my suggestions then this is the system that would then have to be implemented.