Sou um programador autodidata e novato, então peço desculpas se não entender o jargão do programador.
Estou trabalhando em um projeto no qual estou fornecendo dados, que serão continuamente atualizados, para desenvolvedores que irão essencialmente criar uma ferramenta para gerar relatórios de consultas aos dados.
Parece que todos os envolvidos pensam que eles 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 fazendo relatórios sobre o pessoal; o relatório seria dividido em categorias, com um título para cada departamento e, em seguida, sob cada título de departamento haverá subtítulos de cargos e, em seguida, sob cada subtítulo haverá uma lista de funcionários. Os desenvolvedores desejam codificar os departamentos e cargos. Por outro lado, eu acho que eles podem / iriam consultar essas coisas em tempo de execução, classificar os registros por eles e gerar cabeçalhos de relatório dinamicamente com base em qual valor estão lá.
Visto que a lista de valores potenciais mudará com o tempo (por exemplo, departamentos serão criados / renomeados, novos cargos serão adicionados), o código precisará ser atualizado continuamente. Parece-me que poderíamos pular as etapas de manutenção do código e organizar dinamicamente os relatórios.
Como não sou um desenvolvedor, estou me perguntando o que estou perdendo. Que vantagens pode haver em codificar valores em uma ferramenta como esta? Normalmente é assim que os programas são projetados?
Comentários
- possível duplicata de Removendo hard-coded valores e design defensivo versus YAGNI
- Os relatórios são tabulações cruzadas, o que significa que os valores nas linhas devem aparecer como colunas?
- @Brendan – Se você codificar valores no relatório , você ‘ precisará alterar a lista em DOIS locais (fonte de dados e o relatório) enquanto se o relatório for dinâmico, você só precisará alterá-lo em um local (o relatório) .
- @Brendan por que você terminaria com três locais? Talvez meu entendimento esteja incorreto, mas eu ‘ m prevendo uma consulta sql para buscar dados de um banco de dados, o aplicativo agregará / agrupará os valores retornados, por exemplo, o departamento. Se você ‘ deseja ter a sobrecarga de várias consultas de banco de dados, pode selecionar departamentos / cargos distintos, se realmente quiser. Em nenhum momento os dados existem em mais de um local – o relatório está sendo conduzido pelos dados.
- @Brendan Eu também discordo da sua definição de estar em um lugar – a maneira como você o descreve ‘ s em vários locais, espalhados por todo o código-fonte.
Resposta
Wikipedia:
Difícil codificação (também hard-coding ou hardcoding) refere-se à prática de desenvolvimento de software de incorporar o que pode, talvez apenas em retrospecto, ser considerado uma entrada ou dados de configuração diretamente no código-fonte de um programa ou outro objeto executável, ou formatação fixa do dados, em vez de obter esses dados de fontes externas ou gerar dados ou formatar no próprio programa com a entrada fornecida.
A codificação permanente é considerada um antipadrão .
Considerado um No antipadrão, a codificação rígida exige que o código-fonte do programa seja alterado a qualquer momento que os dados de entrada ou o formato desejado mudem, quando pode ser mais conveniente para o usuário final alterar os detalhes por algum meio fora do programa.
Às vezes você não pode evitá-lo, mas deve ser temporário.
O código rígido é frequentemente necessário. Os programadores podem não ter uma solução de interface de usuário dinâmica para o usuário final, mas ainda assim devem fornecer o recurso ou lançar o programa. Isso geralmente é temporário, mas resolve, em curto prazo, a pressão para entregar o código. Posteriormente, a codificação é feita para permitir que um usuário passe parâmetros que fornecem ao usuário final uma maneira de modificar os resultados ou resultados.
- Hardcoding de mensagens torna difícil internacionalizar um programa.
- Os caminhos de codificação dificultam a adaptação a outro local.
A única vantagem da codificação parece ser a entrega rápida do código.
Comentários
- OK , mas a ” única vantagem ” costuma ser extremamente importante. As decisões de design na programação geralmente são sobre a compensação entre a prova futura e a entrega rápida agora e, como tal, a codificação permanente pode ser uma escolha perfeitamente aceitável. Às vezes, não codificação permanente é uma má escolha de design.
- -1 Eu não ‘ não acho que esta seja uma resposta útil. Basicamente, ele diz que ‘ incorporar valores ao código-fonte de maneira inadequada ‘ é inadequado. Eu acho que o OP quer orientação sobre quando as coisas podem pertencer ao código-fonte e, portanto, estão fora da definição da Wikipedia.
- O código rígido deve ser uma parte vital do seu processo e, considerando-o, um antipadrão está desatualizado no era dos microsserviços, com o tutorial do Angular Tour of Heroes sendo um exemplo de alto nível de uma grande software house que encoraja diretamente ou mesmo exige como uma etapa intermediária. Além do mais, quando você muda para dados dinâmicos, você ainda deve reter alguns dados codificados como um fallback, talvez controlado por uma variável de ambiente ou até mesmo uma alternância booleana no próprio código para que bugs e problemas de segurança possam ser devidamente isolados no linha.
Resposta
Sério? Nenhum caso de uso válido possível?
Embora eu concorde que a codificação permanente é geralmente uma anti-padrão ou pelo menos um cheiro de código muito ruim, há muitos casos em que faz sentido. Aqui estão alguns.
-
Simplicidade / YAGNI .
-
Constantes reais que na verdade nunca mudam.
ou seja, a constante representa um natural ou negócio constante ou uma aproximação de um. (por exemplo, 0, PI, …)
-
Restrições ambientais de hardware ou software
No software incorporado, as restrições de memória e alocação vêm à mente.
-
Software seguro
Esses valores não estão disponíveis e / ou são fáceis de decodificar ou fazer engenharia reversa, por exemplo tokens criptográficos e sais. (Observe que mantê-los codificados tem desvantagens óbvias também …)
-
Código gerado
Seu pré-processador ou gerador é configurável, mas emite código com valores embutidos em código. Não é incomum para código que depende de mecanismos de regras ou se você tiver uma arquitetura orientada por modelo.
-
Código de alto desempenho
De certa forma, este é um código ” gerado ” , embora ainda mais especializado. por exemplo. uma tabela de pesquisa / cálculo pré-determinada com mudanças improváveis. Isso não é incomum em programação gráfica, por exemplo.
-
Configuração e substitutos
Tanto em seu código real quanto em seus arquivos de configuração, você provavelmente terá valores de configuração e fallbacks para vários casos (quando a configuração não está disponível, quando um componente não responde como esperado, etc …). Ainda assim, geralmente é melhor mantê-lo fora do seu código e pesquisá-lo, mas pode haver casos em que você absolutamente deseja ter um valor / reação específica a uma ação / problema / situação específica.
-
E provavelmente mais alguns …
Ainda um Antipadrão ? Então é Engenharia excessiva ! É sobre a expectativa de vida do seu software !!
Não que eu esteja dizendo existem todos ótimos motivos e, geralmente, recuso-me a valores embutidos em código. Mas alguns podem facilmente ser reprovados por motivos válidos.
E não supervisione o primeiro em relação à simplicidade / YAGNI ou por pensar que é trivial: provavelmente não há razão para implementar um analisador louco e verificador de valor para um script simples que faz um trabalho para um caso de uso restrito muito bem.
É difícil encontrar a bola ance. Às vezes, você não prevê que um software vai crescer e durar mais do que o script simples com que começou. Muitas vezes, é o contrário: fazemos engenharia excessiva e um projeto é arquivado mais rápido do que você pode leia o Pragmatic Programmer. Você perdeu tempo e esforço em coisas do que um protótipo inicial não precisava.
Essas são as coisas ruins com os anti-padrões: eles estão presentes em ambos os extremos do espectro, e sua aparência depende do sensibilidade da pessoa que está revisando seu código.
Pessoalmente, eu tenderia a sempre seguir o caminho genérico, assim que vejo que algo pode mudar ou se eu “tive que fazer isso mais de uma vez. Mas uma abordagem mais precisa seria avaliar cuidadosamente o custo da codificação permanente em vez de gerar ou generalizar seu código para aquela situação específica.É o mesmo que determinar se vale a pena automatizar uma tarefa em vez de fazê-la manualmente. Basta levar em consideração o tempo e o custo.
Comentários
- Isso ‘ é engraçado, porque eu mesmo fiz o piloto e foi muito mais fácil, rápido e limpo para mim lidar com os valores dinamicamente. Eu fiz isso em Python, embora eu acredite que o produto final será codificado em Java – se isso fizer diferença. Parecia sobrecarregado de engenharia quando codifiquei os valores, porque cada coluna de entrada teve que ser rastreada em vários lugares. / li>
- @Tom: Você ‘ está dizendo que era mais fácil e rápido implementar (ou mesmo reutilizar) uma biblioteca de pesquisa de configuração do que usar um valor embutido no código? para você. Além disso, não ‘ não vejo como sua última frase se encaixa na definição de excesso de engenharia. enguia obviamente confusa e, obviamente, se ‘ for codificada e duplicada ‘ é ainda pior (o que não era o ponto de sua pergunta, provavelmente não entendi, mas me pareceu que você quis dizer que o valor não estava codificado no lugar todas as vezes, mas em um único ponto do programa).
- De qualquer forma, eu ‘ estou apenas apontando os casos em que ‘ d seria válido. Eu ‘ m também apontando que ‘ seria controverso em minha última frase. Você pode ‘ agradar a todos e equipes com pessoas com níveis de habilidade variados.
- @Tom, don ‘ t venda-se muito curto. Você ‘ está definitivamente no caminho certo. Parece mais fácil e menos demorado escrever um algoritmo rápido para organizar os dados observando os campos Departamento e Cargo, em vez de codificação permanente
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Também seria muito mais difícil manter a matriz codificada no caso de um novo Departamento ou Título ser introduzido. - Você pode ter coisas mais complexas que ainda são sensíveis à codificação permanente. Um que me vem à mente, que escrevi alguns anos atrás, era todas as permutações possíveis de um conjunto de valores. Eu precisava encontrar uma direção válida aleatória, escolher uma permutação aleatória e, em seguida, obter o primeiro resultado válido era de longe a solução mais eficiente e, uma vez que estava em um loop O (N ^ 3), a eficiência era importante.
Resposta
Às vezes, não há problema em codificar valores. Por exemplo, existem alguns números como 0, um ou vários valores n ^ 2-1 para bitmasks que precisam ser determinados valores para fins algorítmicos. Permitir esses valores para o configurável não tem valor e apenas abre a possibilidade de problemas. Em outras palavras, se alterar um valor apenas quebraria as coisas, provavelmente deve ser codificado.
No exemplo que você deu, não vejo onde a codificação permanente seria útil. Tudo o que você mencionou já estaria / deveria estar no banco de dados, incluindo cabeçalhos. Mesmo as coisas que orientam a apresentação (como a ordem de classificação) podem ser adicionadas se não estiverem lá.
Comentários
- Obrigado. A ordem de classificação foi a única preocupação que eu tinha. No entanto, em nosso caso, isso não ‘ t importa, e eu não ‘ nem mesmo considerei que poderia ser adicionado como outra tabela no banco de dados.
- Devo observar que gerenciar tudo isso no banco de dados é uma opção. Você também pode usar arquivos de configuração ou outras soluções, mas o hardcoding parece ser uma escolha ruim. O banco de dados opção é frequentemente usada porque é ‘ fácil criar uma interface para permitir que as opções sejam gerenciadas pelos usuários. Também existem ferramentas como isto que são especificamente projetados para este propósito.
Resposta
Implementando uma solução robusta que permite valores que poderiam ter sido codificados para serem configurados pelas demandas dos usuários finais validação robusta desses valores. Eles colocaram um barbante vazio? Eles colocaram algo não numérico onde deveria ser um número? Eles estão fazendo injeção de SQL? Etc.
A codificação permanente evita muitos desses riscos.
O que não quer dizer que a codificação permanente seja sempre, ou mesmo frequentemente, uma boa ideia. Isso é apenas um dos fatores a levar em consideração.