Existem vantagens em codificar valores de dados em um programa?

Sou um programador autodidata e novato, então peço desculpas se não souber o que é o programador.

Estou trabalhando em um projeto no qual estou fornecendo dados, que serão atualizados continuamente, para desenvolvedores que essencialmente criarão uma ferramenta para gerar relatórios a partir de consultas nos dados.

Parece que todos os envolvidos pensam que precisam codificar valores de dados (não o esquema, mas os próprios domínios / valores) no programa de geração de relatórios.

Por exemplo, suponha que estivéssemos reportando sobre pessoal; o relatório seria dividido em categorias, com um cabeçalho para cada departamento e, em cada cabeçalho, haverá subtítulos de cargos e, em cada subtítulo, haverá uma lista de funcionários. Os desenvolvedores desejam codificar os departamentos e os cargos. Por outro lado, eu pensaria que eles poderiam / consultariam essas coisas em tempo de execução, classificariam os registros por eles e gerariam cabeçalhos de relatório dinamicamente com base em quais valores existem.

Como a lista de valores possíveis será alterada ao longo do tempo (por exemplo, os departamentos serão criados / renomeados, novos cargos serão adicionados), o código precisará ser atualizado continuamente. Parece-me que podemos pular as etapas de manutenção de código e organizar dinamicamente os relatórios.

Como não sou desenvolvedor, estou me perguntando o que estou perdendo. Quais são as vantagens de codificar valores em uma ferramenta como essa? É assim que os programas são projetados?

Wikipedia:

Codificação embutida (também codificada ou embutida) refere-se à prática de desenvolvimento de software de incorporar o que pode, talvez apenas em retrospecto, ser considerado um dado de entrada ou configuração diretamente no código fonte de um programa ou outro objeto executável ou formatação fixa de os dados, em vez de obter esses dados de fontes externas ou gerar dados ou formatação no próprio programa com a entrada fornecida.

A codificação embutida é considerada um antipadrão.

Considerada um antipadrão, a codificação rígida exige que o código-fonte do programa seja alterado sempre que os dados de entrada ou o formato desejado forem alterados, quando for mais conveniente para o usuário final alterar os detalhes de alguma forma fora do programa.

Às vezes você não pode evitá-lo, mas deve ser temporário.

Geralmente, é necessária codificação embutida. Os programadores podem não ter uma solução de interface de usuário dinâmica para o usuário final elaborada, mas ainda precisam fornecer o recurso ou liberar o programa. Isso geralmente é temporário, mas resolve, em um sentido de curto prazo, a pressão para entregar o código. Posteriormente, a codificação eletrônica é feita para permitir que um usuário transmita parâmetros que fornecem ao usuário final uma maneira de modificar os resultados.

• A codificação codificada das mensagens dificulta a internacionalização de um programa.
• Caminhos codificados dificultam a adaptação a outro local.

A única vantagem do código rígido parece ser a entrega rápida de código.

Verdade? Não há casos de uso válidos possíveis?

Embora eu concorde que a codificação geralmente seja um anti-padrão ou pelo menos um cheiro muito ruim para o código , há muitos casos em que faz sentido:

• simplicidade ( YAGNI ),
• a entrada é realmente constante e nunca será alterada (ou seja, representa uma constante natural ou comercial ou uma aproximação de uma. por exemplo, 0, PI, ...),
• software incorporado (restrições de memória e alocação vêm à mente),
• software seguro (esses valores não devem estar disponíveis e / ou fáceis de decodificar ou fazer engenharia reversa, por exemplo, tokens e sais criptográficos),
• código gerado (seu pré-processador ou gerador é configurável, mas cospe código com valores codificados),
• e provavelmente mais alguns.

Ainda é um anti-padrão ? Então é excesso de engenharia ! É sobre a expectativa de vida do seu software !!

Não que eu esteja dizendo que existem muitas razões, e geralmente eu me recusaria a valores codificados. Mas alguns podem facilmente obter um passe por razões válidas.

E não supervisione o primeiro sobre simplicidade / YAGNI , pensando que é trivial: provavelmente não há razão para implementar um analisador maluco e um verificador de valor para um script simples que faz muito bem um caso de uso restrito.

É difícil encontrar o equilíbrio. Às vezes, você não prevê que um software cresça e dure mais do que o script simples como começou. Muitas vezes, porém, é o contrário: projetamos demais as coisas e um projeto é arquivado mais rápido do que você pode ler o Pragmatic Programmer. Você desperdiçou tempo e esforço em coisas que um protótipo inicial não precisava.

Essas são as coisas ruins com os Antipadrões: eles estão presentes nos dois extremos do espectro e sua aparência depende da sensibilidade da pessoa que está revisando seu código.

Às vezes, não há problema em codificar valores. Por exemplo, existem alguns números como 0 ou um ou vários valores n ^ 2-1 para máscaras de bits que precisam ter certos valores para fins algorítmicos. Permitir que esses valores sejam configuráveis ​​não tem valor e apenas abre a possibilidade de problemas. Em outras palavras, se a alteração de um valor quebraria apenas as coisas, provavelmente deveria ser codificado.

No exemplo que você deu, não vejo onde a codificação seria útil. Tudo o que você mencionou já deveria estar no banco de dados, incluindo os títulos. Até coisas que conduzem a apresentação (como ordem de classificação) podem ser adicionadas se não estiverem lá.

A implementação de uma solução robusta que permita valores que, de outra forma, poderiam ter sido codificados para serem configurados pelos usuários finais exige uma validação robusta desses valores. Eles colocaram uma corda vazia? Eles colocaram algo não numérico onde deveria ter sido um número? Eles estão fazendo injeção de SQL? Etc.

A codificação embutida evita muitos desses riscos.

O que não quer dizer que a codificação permanente seja sempre, ou mesmo frequentemente, uma boa ideia. Este é apenas um dos fatores a serem levados em consideração.