Até que ponto devemos renomear códigos e dados quando as nomenclaturas dos usuários finais mudam?

Há muito tempo, adicionamos um recurso em que nossos usuários podiam "Aceitar" uma imagem após ser adicionada a uma fila de fluxo de trabalho. Acontece que usamos o termo errado e os usuários realmente "aprovam" a imagem.

É fácil alterar Aceitar para aprovar em nossa interface, basta substituir uma palavra. Mas programamos todas as camadas com a palavra "accept", desde o nome da classe CSS até os valores do banco de dados.

• A classe CSS que ativa o botão verde: ".accepted";
• O método de modelo que verifica e vincula o atributo de classe no nó DOM: "isAccepted";
• Atributo de status JavaScript: matriz com "não revisado", "aceito" e "publicado";
• Coluna de status do Mysql: ENUM com "não revisado", "aceito" e "publicado";
• Nomes de teste;

É trivial (especialmente quando você tem testes) substituir a maioria das ocorrências de aceitação para aprovação. Um pouco mais difícil é migrar os dados, especialmente porque eles precisam ser sincronizados com a implantação.

Esse caso específico é simples, mas já enfrentei casos semelhantes, ainda mais complexos, durante minha carreira. Quando um arquivo também é renomeado e a implantação ocorre em dezenas de servidores, ou quando o cache do proxy, o memcached e o mysql estão envolvidos.

Deixar "aceito" em todas as outras camadas, exceto a interface, é uma péssima idéia, pois novos programadores que ingressam na equipe podem não aprender as razões históricas que levaram a essa decisão e, apesar de aceitar -> aprovar, são palavras próximas em termos de significado, se foi renomeado para "na fila para a próxima reunião de status gerencial", certamente não faria sentido. E parece que, se comprometermos aqui e ali, em algumas iterações, os conceitos de interface do usuário não terão influência nos internos do sistema, e eu certamente não quero trabalhar em um sistema em que metade da saída não tenha 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, ele voltou a morder você? O comentário do código ou a documentação do desenvolvedor é suficiente para evitar esse problema?

Para mim, é definitivamente melhor mudar tudo relacionado ao item em questão.

É uma forma de degradação do código e, embora um item que não esteja sendo alterado possa não ser muito importante, define o tom da base de código.

Isso também pode gerar confusão no futuro e dificultar o entendimento dos novos desenvolvedores da base / domínio de código.

A partir do conteúdo e das tags da pergunta, assumirei que você está usando 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 normalmente fiz (e já vi) é:

• Refatoração antecipada de 1 plano: refatorar todas as camadas do aplicativo para adotar o idioma atualizado; ou
• registrar dívida técnica: você pode alterar o código voltado para o usuário imediatamente e depois registrar tarefas de dívida técnica para alinhar o restante das camadas do aplicativo ao idioma atualizado. Isso normalmente resulta em um punhado de tarefas chatas (mas gerenciáveis). (Perfeito para 17:00!)

Acho que o principal aqui é que o que você está descrevendo é dívida técnica e deve ser reconhecido como tal.

Tive gerentes que argumentaram que não devemos perder tempo com tarefas triviais que não adicionam nenhuma funcionalidade visível. É aí que a analogia da dívida é realmente útil. Tudo se resume a isso:

A equipe escolheu fazer DDD com linguagem ubíqua. Desviar-se dessa abordagem, deixando o código em um estado inconsistente, gera confusão e remove muitos dos benefícios que o DDD e a UL oferecem. Em termos de gerente, ele adiciona custo ao projeto. O código se torna mais difícil (caro) de gerenciar e mais confuso para novos desenvolvedores (caro).

Você pode procurar nas 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 acontecer normalmente, o uso de l10n pode permitir que você altere rapidamente o que é exibido na interface do usuário, sem precisar alterar o termo usado no código.

Com isso, basta usar os termos em seu código que são os mais amplamente compreendidos. Escolha nomes do domínio conforme os desenvolvedores o conhecem e podem esperar.

Como você descreve adequadamente, acompanhar as alterações da nomenclatura do usuário final em todas as partes da fonte é um grande investimento. No entanto, definitivamente vale a pena, especialmente para um produto de longa duração desenvolvido por uma infraestrutura completa (com linha direta, testadores etc.)

O rastreamento da nomenclatura do usuário final na fonte é um investimento, porque existem muitos tipos de componentes onde ela aparece e não há varinha mágica trabalhando simultaneamente em todos esses componentes. Talvez o desenvolvimento de uma varinha mágica, componente após componente, seja um investimento interessante que você possa diluir ao longo da vida útil do projeto.

Eu trabalhei em uma base de código de 30 anos em que a diferença entre a nomenclatura do usuário final e a nomenclatura interna cresceu especialmente. Aqui estão algumas desvantagens dessa situação, que contribuem para a sobrecarga do trabalho de todos:

1. Na ausência de uma política adequada, o novo desenvolvimento tende a usar a atual nomenclatura do usuário final. Assim, o mesmo conceito pode ter dois ou mais nomes em componentes diferentes. Como os componentes interagem juntos, isso resulta na existência de vários nomes sinônimos de forma simultânea em algumas partes locais do código.

2. Quando a linha direta / suporte técnico é chamada, eles escrevem uma história de usuário usando a nomenclatura do usuário final. O desenvolvedor encarregado de corrigir o problema deve converter a nomenclatura do usuário final para corresponder à nomenclatura de origem. Claro que não está arquivado e, é claro, é uma bagunça. (Veja 1.)

3. Quando o programador depura o código, ela deseja definir pontos de interrupção em funções relevantes. É difícil encontrar as funções apropriadas se a nomenclatura do usuário final e a nomenclatura de origem não concordam. Pode até ser difícil ou impossível ter certeza de que uma lista das funções relevantes está completa. (Veja 1.)

4. Na ausência de uma política adequada, a manutenção da fonte usando uma nomenclatura obsoleta colocará periodicamente essa nomenclatura obsoleta na frente dos usuários. Isso produz má impressão e causa sobrecarga.

Eu já rastreei por dois dias o próprio local em que alguns dados são lidos no banco de dados e injetados em algum componente dessa base de código. Como nem eu, nem ninguém da empresa em que trabalhei foi capaz de descobrir um nome que levasse a esse lugar, eu finalmente demiti e decidi encontrar outra solução para esse problema.

Embora custar mais de [1] dois dias de manutenção sem render nada (sem conhecimento, sem correção, nada) seja provavelmente o pior possível, discrepâncias entre a nomenclatura do usuário e a nomemclatura da fonte aumentam a sobrecarga de muitas tarefas rotineiras na manutenção de um software.

É importante observar que o custo indireto aumenta com a empresa que produz o software. Em uma organização grande, um relatório de problema não chegará à sua mesa antes de ser considerado por vários colegas e a correção pode estar sujeita a teste.

[1] Por causa de mais de um desenvolvedor envolvido.

Nem sempre renomeio o código e os dados porque alguns pacotes são compartilhados entre os clientes. Eles estão basicamente usando a mesma coisa, mas chamam de maneira diferente. Exemplos, em um CMS, um cliente chama seu cliente "Cliente" e outro usa "Cliente". Por isso, substituímos o Cliente pelo Cliente na superfície por 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 x lista de controle de acesso, administrador x gerente, etc. Pode ser confuso para novos usuários, mas para componentes principais como esses, geralmente há desenvolvedores principais que garantem que esses componentes funcionem para todos os clientes e Também é fácil de implementar por outros desenvolvedores (por exemplo, criando etiquetas configuráveis).

Pode ser bom pensar que, se você fizer essa alteração, esperamos que não precise fazer isso novamente se a mesma peça for usada por outro cliente, basicamente transformando-a em um produto.