Primeiro um pouco de fundo. Estou codificando uma pesquisa de Idade -> Taxa. Existem 7 faixas etárias, portanto, a tabela de pesquisa é composta por 3 colunas (de | a | taxa) com 7 linhas. Os valores raramente mudam - são taxas legisladas (primeira e terceira colunas) que permaneceram as mesmas por três anos. Achei que a maneira mais fácil de armazenar esta tabela sem codificá-la é no banco de dados em uma tabela de configuração global, como um valor de texto único contendo um CSV (então "65,69,0.05,70,74,0.06" é como as camadas 65-69 e 70-74 seriam armazenadas). Relativamente fácil de analisar e usar.
Então percebi que, para implementar isso, eu teria que criar uma nova tabela, um repositório para envolvê-la, testes de camada de dados para o repositório, testes de unidade em torno do código que descompacta o CSV na tabela e testes em torno da própria pesquisa. O único benefício de todo esse trabalho é evitar a codificação da tabela de pesquisa.
Ao conversar com os usuários (que atualmente usam a tabela de pesquisa diretamente - olhando para uma cópia impressa), a opinião é praticamente de que "as taxas nunca mudam". Obviamente, isso não está correto - as taxas foram criadas apenas três anos atrás e, no passado, coisas que "nunca mudam" têm o hábito de mudar - então, para eu programar isso de forma defensiva, eu definitivamente não devo armazenar a tabela de consulta em a aplicação.
Exceto quando penso YAGNI . O recurso que estou implementando não especifica que as taxas serão alteradas. Se as taxas mudarem, elas ainda mudarão tão raramente que a manutenção nem sequer é considerada, e o recurso não é realmente crítico o suficiente para que qualquer coisa seja afetada se houver um atraso entre a alteração da taxa e o aplicativo atualizado.
Decidi praticamente que nada de valor será perdido se eu codificar a pesquisa e não estiver muito preocupado com minha abordagem desse recurso em particular. Minha pergunta é: como profissional, justifiquei adequadamente essa decisão? A codificação dos valores é um design ruim, mas o problema de remover os valores do aplicativo parece violar o princípio YAGNI.
EDIT Para esclarecer a questão, não estou preocupado com a implementação real. Preocupa-me que eu possa fazer algo rápido e ruim e justificá-lo dizendo YAGNI, ou posso adotar uma abordagem mais defensiva e de alto esforço, que, mesmo na melhor das hipóteses, traz benefícios baixos. Como programador profissional, minha decisão de implementar um projeto que eu sei que é falha simplesmente se resume a uma análise de custo / benefício?
EDIT Embora todas as respostas tenham sido muito interessantes, pois acho que isso se resume às escolhas de design de um indivíduo, acho que as melhores respostas foram @ Corbin e @EZ Hart, pois trazem à tona coisas que eu não havia considerado na pergunta:
- a falsa dicotomia de 'remover corretamente valores codificados' movendo-os para o banco de dados vs 'aplicando YAGNI' de forma eficiente 'usando codificação embutida. Havia uma terceira opção de colocar a tabela de pesquisa na configuração do aplicativo, o que não implica a sobrecarga da maneira correta e sem a eficiência do YAGNI. Geralmente, não estamos limitados a decisões ou decisões e, em seguida, tudo se resume a uma decisão de custo / benefício.
- a geração de código pode reduzir a sobrecarga de mover os valores codificados para o banco de dados e de uma maneira que também elimina minha decisão de engenharia de processar um CSV na tabela. Potencialmente, isso também adiciona um problema de manutenção a longo prazo ao código gerado, se os requisitos básicos mudarem para o método de pesquisa. Tudo isso afeta apenas a análise de custo / benefício, e é provável que, se eu tivesse essa automação disponível, nem sequer consideraria a codificação embutida algo assim.
Estou marcando a resposta de @ Corbin como correta, pois altera minhas suposições de custo de desenvolvimento e provavelmente adicionarei algumas ferramentas de geração de código ao meu arsenal no futuro próximo.