A resposta mais simples é a revisão de código (e por código revisões, eu realmente quero dizer "tudo relacionado a mudanças de código incluindo o próprio código). Obviamente isso significa que você terá que ter documentação.
Eu conheço lugares onde as pessoas estão hackeando todo o lugar, último lugar em que meu cônjuge trabalhava toda vez que ele aparecia para consertar um bug que ele pegava o código mais recente e ... isso mudaria. Uma equipe colocaria mudanças nessa direção e outra equipe colocaria as mudanças em uma direção diferente. Às vezes as equipes mudaram de direção sozinhas e você acabou com o caos puro, onde nada foi feito para o produto, mas houve mudanças de código constantes e intensas.
É aqui que você precisa de alguma forma de controle de alterações do tipo não desenvolvedor. Se você implementar um sistema onde as mudanças são feitas de forma controlada, e com isso quero dizer que qualquer um pode mudar alguma coisa, é só que eles precisam de alguma razão para fazê-lo e alguma forma de autorização de que é bom progredir.
Assim, você pode exigir que nenhuma alteração seja aplicada, a menos que seja em resposta a um ticket de mudança. (qualquer pessoa pode criar um ticket descrevendo um problema que precisa ser mudado, é claro), mas esses tickets são atribuídos a uma pessoa ou equipe por alguém encarregado da direção do produto - um analista de negócios ou autoridade técnica de design ou até mesmo uma reunião de equipe. O importante é que a mudança seja feita de maneira não individual.
Uma vez que isso seja resolvido, alguém irá fazer alterações e, em seguida, será revisado. Isso significa que outra pessoa vê o código, mas também as alterações e a documentação do ticket. Então, se você quiser mudar o seu sistema de acesso ao banco de dados, tudo bem ... mas você precisa descrever o que é, por que foi alterado e como funciona agora. Sem essa documentação, a alteração não é revisada. Depois, você pode implementar 'treinamentos' internos, como bolsas marrons ou dojos de código, para garantir que o restante da equipe seja informado.
Algumas pessoas resistirão a isso, mas tendem a ser as que constantemente mudam o código, "cortando código" em vez de "trabalhando no produto". Esta é uma distinção importante a ser feita, como desenvolvedores, todos nós podemos ser pegos no conceito de que o código é o que é importante - não é. O produto que você está construindo é o que é importante e isso é muito mais do que apenas código.
A documentação não precisa ser extensa, apenas o suficiente para dizer a outra pessoa o que você fez ou como ela funciona. Pode ser um wiki ou até mesmo apenas notas nos tickets - como os ingressos envelhecem, eles desaparecem de vista e a documentação com eles, mas isso é ok, pois isso significa que apenas os documentos atuais são mantidos. Alternativamente, você pode ter um wiki de componentes, arquitetura e uso, e isso é mantido atualizado como parte de cada mudança de código. Ou (minha preferência) é armazenar toda a sua documentação técnica junto com o código como documentos de texto em um formato de marcação que é embutido em html pelo servidor de compilação e apresentado em um servidor web - assim qualquer um pode ver a documentação atual que é facilmente atualizada quando código é atualizado.
Um último recurso é obter uma equipe de arquitetura que tem a responsabilidade de documentar o sistema, mas eles também terão o poder de impedir que qualquer alteração seja feita, a menos que a documentação seja atualizada primeiro - muitas equipes mais soltas podem não gostar disso abordagem, mas se eles não podem fazê-lo funcionar usando minhas sugestões, então este é o sistema que então teria que ser implementado.