Há muito tempo, adicionamos um recurso em que nossos usuários podiam "Aceitar" uma imagem depois que ela foi adicionada a uma fila de fluxo de trabalho. Acontece que usamos o termo errado e os usuários realmente "aprovam" a imagem.
Alterar Aceitar para Aprovar na nossa interface é fácil, basta substituir uma palavra. Mas nós programamos todas as camadas com a palavra "accept", do nome da classe CSS aos valores do banco de dados.
É trivial (especialmente quando você tem testes) para substituir a maioria das ocorrências de aceitar para aprovar. Um pouco mais difícil é migrar os dados, especialmente porque precisa ser sincronizado com a implantação.
Este caso específico é simples, mas eu enfrentei casos semelhantes, porém mais complexos, durante minha carreira. Quando um arquivo também é renomeado e a implementação acontece em dezenas de servidores, ou quando o cache de proxy, o memcached e o mysql estão envolvidos.
Deixar "aceito" em todas as outras camadas, exceto a interface, é uma má ideia, já que os novos programadores que ingressam na equipe podem não aprender as razões históricas que levaram a essa decisão e aceitar - > aprovar são palavras íntimas em termos de significado, se foi renomeado para "enfileirado para próxima reunião de status gerencial", certamente não faria qualquer sentido. E parece que, se nos comprometermos aqui e ali, em algumas iterações os conceitos de interface do usuário não terão nenhum suporte para os internos do sistema, e certamente não quero trabalhar em um sistema onde metade da saída não tenha nenhuma conexão com suas entranhas.
Então, você sempre renomeia tudo quando necessário? Se isso aconteceu com você, e você decidiu que o trade-off não valia a pena, ele voltou para te morder? O comentário do código ou a documentação do desenvolvedor são suficientes para evitar esse problema?
Para mim, é definitivamente melhor mudar tudo relacionado ao item em questão.
É uma forma de degradação de código e, embora um item não seja alterado, pode não ser grande coisa, ele define o tom da base de código.
Isso também pode gerar confusão no futuro e dificultar o entendimento de novos desenvolvedores para o código base / domínio.
Do conteúdo e das tags da pergunta, presumimos que você esteja usando uma linguagem onipresente.
Na minha experiência, a UL é ótima, mas, como você mencionou, pode levar a tarefas de manutenção adicionais à medida que a linguagem evolui. Isso, por si só, não é uma coisa ruim. Claro, é inconveniente, mas também é esperado.
O que eu geralmente faço (e visto feito) é:
Acho que a principal coisa aqui é que o que você está descrevendo é dívida técnica e deve ser reconhecido como tal.
Já tive gerentes que argumentaram que não deveríamos perder tempo em tarefas triviais que não adicionam nenhuma funcionalidade visível. É quando a analogia da dívida é realmente útil. Tudo se resume a isto:
A equipe escolheu fazer o DDD com a linguagem ubíqua. Afastar-se dessa abordagem deixando o código em um estado inconsistente adiciona confusão e remove muitos dos benefícios que o DDD e o UL fornecem. Em termos de gerente, adiciona custo ao projeto. O código se torna mais difícil (caro) para gerenciar e mais confuso para novos desenvolvedores (caro).
Você pode querer olhar para as opções de Localização (l10n). Embora possa não parecer tão drástico quanto ir do inglês para o espanhol, você está lidando com um termo diferente para o mesmo conceito. Se isso parece acontecer normalmente, usar o l10n pode permitir que você altere rapidamente o que é exibido na interface do usuário sem ter que alterar o termo usado no código.
Com isso, basta usar os termos em seu código que são mais compreendidos. Escolha nomes do domínio, como os desenvolvedores sabem e podem esperar.
Como você descreve isso apropriadamente, rastreando a nomenclatura do usuário final mudanças em todas as partes da fonte são um grande investimento. Isto é no entanto definitivamente vale a pena, especialmente para um produto de longa duração desenvolvido por uma infra-estrutura completa (com hotline, testadores, etc.)
O rastreamento da nomenclatura do usuário final na origem é um investimento porque existem tantos tipos de componentes onde aparece e não há varinha mágica trabalhando simultaneamente em todos esses componentes. Talvez desenvolver uma varinha mágica, componente após componente, é uma investimento interessante que você pode diluir ao longo da vida do projeto.
Eu trabalhei em uma base de código de 30 anos, onde o desvio entre o usuário final nomenclatura e nomenclatura interna cresceu especialmente grande. Aqui são alguns inconvenientes desta situação, que se somam à sobrecarga do trabalho de todos:
Na ausência de uma política adequada, o novo desenvolvimento tende a usar o nomenclatura atual do usuário final. Assim, o mesmo conceito pode ter dois ou mais nomes em diferentes componentes. Desde os componentes interagem juntos, isso resulta em vários nomes sinônimos existente simulatenamente em algumas partes locais do código.
Quando a linha direta / help desk é chamada, eles escrevem uma história do usuário usando nomenclatura de usuário final. O desenvolvedor encarregado de consertar o problema deve traduzir a nomenclatura do usuário final para coincidir com o nomenclatura das fontes. Claro que não é arquivado, e é claro que é uma bagunça. (Veja 1.)
Quando o programador depura o código, ela quer definir pontos de interrupção em funções relevantes. É difícil encontrar o apropriado funções se a nomenclatura do utilizador final e a nomenclatura da fonte não concordo. Pode até ser difícil ou impossível confiar que uma listagem das funções relevantes é ainda completa. (Veja 1.)
Na ausência de uma política adequada, a manutenção da fonte usando um nomenclatura obsoleta irá de vez em quando colocar este obsoleto nomenclatura na frente dos usuários novamente. Isso produz pobres impressão e causa sobrecarga.
Eu já localizei dois dias no mesmo lugar em que alguns dados são ler o banco de dados e injetado em algum componente desta base de código. Porque se eu ou ninguém na empresa em que trabalhei foi capaz de descobrir um nome que leva a este lugar eu finalmente demitido e decidiu encontrar outra solução para esse problema.
Embora custando mais de [1] dois dias de manutenção sem gerar qualquer coisa (sem conhecimento, sem correção, nada) é provavelmente tão ruim quanto possível discrepâncias entre a nomenclatura do usuário e a nomenclatura da fonte adicionar sobrecarga a muitas tarefas de rotina na manutenção de um software.
É importante observar que o custo indireto aumenta com a empresa produzindo o software, em uma grande organização, um relatório de problema não chegar em sua mesa antes de ter sido considerado por vários colegas e a correção podem estar sujeitos a testes.
[1] Devido a mais de um desenvolvedor estar envolvido.
Nem sempre renomeio código e dados porque alguns pacotes são compartilhados entre clientes. Eles estão basicamente usando a mesma coisa, mas chamam de forma diferente. Exemplos, em um CMS, um cliente chama seu cliente "Cliente" e outro usa "Cliente". Por isso, substituímos Cliente por Cliente na superfície de um cliente, mas o CMS sempre será um Sistema de Gerenciamento de Clientes.
Outro exemplo é o gerenciamento de usuários com termos como permissões vs lista de controle de acesso, admin vs manager, etc. Pode ser confuso para os recém-chegados, mas para componentes principais como esses, geralmente há desenvolvedores que garantem que esses componentes funcionem todos os clientes e também fáceis de implementar por outros desenvolvedores (por exemplo, criando rótulos configuráveis).
Pode ser útil pensar que, se você fizer essa alteração, esperamos que não seja necessário fazer isso novamente se a mesma peça for usada por outro cliente, basicamente transformando-o em um produto.