Com relação à sua segunda pergunta, não conheço estudos publicados ou práticas recomendadas. Com relação à primeira pergunta, posso oferecer algumas observações da experiência pessoal com um produto de longa duração semelhante, onde os nomes 'interno' e 'externo' são às vezes diferentes.
Os nomes que eu realmente gostaria de corrigir são os "homofones", onde um nome é usado interna e externamente para coisas diferentes . Isso pode ser realmente confuso, principalmente se as duas coisas não forem completamente diferentes (de modo que o contexto ajude a desambiguar). Um exemplo (abstrato) disso na minha experiência pessoal é onde internamente você tem algo como um Foo
que é uma coleção de múltiplos FooEntity
; externamente, apenas o último é visível e é chamado de "Foo". Demorei um pouco para descobrir que, quando o manual do cliente estava falando de vários “Foo”, na verdade significava múltiplos FooEntity
(em um único Foo
), se isso ainda faz algum sentido para você.
Em segundo lugar, eu gostaria de corrigir quaisquer “sinônimos” em que algum nome externo tenha sido usado internamente. Como em nomes de variáveis, partes de nomes de métodos / funções e assim por diante. Isso geralmente acontece quando os desenvolvedores implementam algo diretamente da descrição dos requisitos do cliente e esquecem de "traduzir" os nomes. Quando isso acontece, o nome 'errado' também tende a se espalhar, porque outros desenvolvedores copiam / colam parte desse código para usar como modelo para o novo código, por exemplo. Esses sinônimos não são tão confusos, mas podem ser irritantes porque, se você estiver pesquisando no código por alguma referência a Bar
você, tenha em mente que algumas partes podem se referir a ele comoQux
, então você precisa pesquisar duas vezes. (Isso pode ser pior em idiomas de tipo dinâmico do que nos estáticos, já que você precisa procurar partes do nome de variáveis / funções / ... em vez do nome de seu tipo.) Quanto ao caso inverso de “sinônimos ”, Onde um nome interno foi usado externamente: isso tende a não acontecer com tanta frequência, pois os funcionários do suporte ao cliente etc. geralmente têm menos consciência dos nomes internos, embora eu assuma que é confuso para os clientes quando isso acontece.
Se você puder evitar ou consertar pelo menos as duas situações acima, não tenho certeza se você deve ir tão longe quanto tornar todos os nomes internos iguais aos externos. Provavelmente, há uma boa razão pela qual os nomes internos também não foram alterados quando o nome externo foi diferente do nome interno. Na minha experiência pessoal, esse bom motivo é a necessidade de oferecer suporte a versões mais antigas do produto; pode tornar-se difícil mesclar uma correção de bug de uma versão de limpeza antes dos nomes para a versão mais recente, se for necessário alterar muito código.