Aqui minha contribuição.
I started a new job recently where I am working on a very large
application (15M lines of code).
Você provavelmente não está familiarizado com o projeto e seus "recursos". Antes de digitar uma única linha de código, é importante estar familiarizado com o projeto. Portanto, reverta suas alterações e comece analisando o código . (Pelo menos o afetado)
Entender a solução existente oferece uma perspectiva melhor de onde você está se metendo. Contextualize a solução e sua importância.
Como @Greg apontou, você deve ser capaz de testar o código existente para ter uma referência válida para comparar com (testes de regressão). Sua solução deve ser capaz de gerar os mesmos resultados do que o existente. Neste estágio, você não se importa se os resultados estão certos ou não . O primeiro objetivo é refatorar, não corrigir bugs. Se a solução existente disser "2 + 2 = 42", sua solução também deve. Se não lançar exceções, o seu também não deve. Se ele retorna nulos, o seu deve retornar nulos também. E assim por diante. Caso contrário, você estará comprometendo 25k linhas de código.
Isso é por causa da retro-compatibilidade.
Por quê? Porque agora, é a sua garantia única de um refatorador de sucesso.
And many of the unit tests either directly reference that interface,
or are coupled to base classes which reference that interface.
Uma maneira de garantir a retro compatibilidade é urgentemente necessária para você. Então, aqui está seu primeiro desafio. Isole o componente para testes unitários.
Tenha em mente que essas 25 mil linhas de código foram feitas assumindo os possíveis resultados do código existente. Se você não quebrar esta parte do contrato, então você está a meio caminho da solução final. Se você faz, bem: pode a força estar com você
Depois de ter projetado e implementado o novo "contrato", substitua o antigo. Deprecá-lo ou retirá-lo.
Eu sugeri que deixar os bugs sozinhos por causa da refatoração e correção de bugs são tarefas diferentes. Se você tentar levá-los adiante, você pode falhar em ambos. Você pode achar que encontrou bugs, no entanto, eles podem ser "recursos". Então, deixe-os sozinhos (por um minuto).
25 mil linhas de código parecem-me suficientes para me concentrar em apenas uma tarefa.
Quando sua primeira tarefa estiver concluída. Exponha esses erros / recursos ao seu chefe.
Finalmente, como o @Stephen disse:
There's not much you can do about it except slowly make things better.
When you create the new classes, make sure you properly test them and
create them using SOLID principles so they will be easier to change in
the future