Os arquivos de configuração externa são considerados um antipadrão?

Muitas vezes, estive em uma situação em que um aplicativo aparentemente estava quebrado, apenas para descobrir que um arquivo de configuração externo estava com defeito. Normalmente, isso ocorre porque o arquivo errado está lá ou contém dados incorretos.

Existe uma maneira melhor de permitir que um usuário / processo externo modifique as características de tempo de execução de um aplicativo ou essa é a solução mais conhecida para o problema?

Eu gostaria de ver uma discussão sobre o caso geral, em vez de focar, digamos, em Unix /etc ou Java JNDI e assim por diante.

A maioria dos aplicativos requer alguma configuração externa; você pode ocultar isso tornando-o dependente de variáveis ​​mágicas ou salvando-o em algum local interno, mas isso não removerá a necessidade. O objetivo é reconhecer o que deve ser externo e o que pode ser interno. Somente as partes internas podem ser testadas.

Um aplicativo não deve confiar em um arquivo de configuração externo para estar correto. Ele deve verificar a correção e relatar erros. Se não for possível para o aplicativo verificar o arquivo de configuração, provavelmente você está fazendo muito com ele. Se o arquivo de configuração alterar o comportamento do aplicativo, ele não deve ser externo na minha opinião.

Por exemplo, um nome de usuário / senha do banco de dados pode ser facilmente verificado pelo aplicativo tentando se conectar ao banco de dados. Se isso falhar, pode ser relatado e, obviamente, não é um bug no código do aplicativo. Da mesma forma, para um caminho de arquivo, a existência e os direitos de acesso podem ser verificados.

Agora, se você colocar consultas SQL no arquivo de configuração, o aplicativo não poderá verificar facilmente a exatidão dessas consultas. O mesmo vale para um arquivo completo de especificação de injeção de dependência (a Java-Spring XML). Esses não devem estar em arquivos de configuração externos.

Mas se a configuração especificada descrever algo externo e você puder verificar rapidamente sua correção, não acho que haja algo errado com os arquivos de configuração externos.

Editar: verifique também se seus relatórios de erro mostram qual arquivo de configuração é usado. Nada é mais frustrante do que descobrir que você estava olhando para o arquivo errado depois de horas tentando descobrir o que havia de errado com ele.

Eu os classificaria mais como uma "área problemática conhecida" do que como antipadrão. A menos que você implante uma configuração fixa, precisará armazenar informações de configuração em algum lugar . Normalmente, gosto de armazenar a maioria das informações de configuração no banco de dados, mas você ainda precisa armazenar as informações de conexão com o banco de dados em algum lugar. Prefiro a abordagem Java / Spring de armazenar as informações de configuração na própria estrutura do aplicativo, em vez de (digamos) no diretório inicial do usuário ou no registro do Windows, mas isso é apenas uma preferência pessoal.

Arquivos de configuração externos NÃO são um antipadrão. Como tudo o mais, eles podem ser usados ​​bem ou mal, dependendo do sistema em questão.

Você parece ter encontrado alguns aplicativos em que a configuração externa pode interromper o aplicativo sem informar ao usuário o que está acontecendo. Isso é ruim, mas não é culpa dos arquivos de configuração, é quem decide quais partes estão nos arquivos de configuração e quais estão no aplicativo e como lidar com os erros entre eles.

Na minha opinião: NÃO , os arquivos de configuração externos não são um antipadrão.

É apenas uma técnica, um padrão arquitetural para gerenciar a complexidade do software.

Na era dos princípios de design do SOLID, você mudou a complexidade do software de Monolithic_application para módulos mais independentes que precisam ser conectados.

a alternativa para "arquivos de configuração externos" seria configurar os módulos diretamente por código.

É preferível mover a configuração da lógica para os dados. Ele permite que você flexibilize o aplicativo sem a necessidade de refazer seu código. A falta de arquivos de dados é mais um caso de pouca documentação ou trabalho desleixado na instalação do que uma prática inadequada em termos de codificação do IMHO.

Faça com que sua ferramenta SCM favorita faça duas tarefas como uma ferramenta CM: Coloque seus arquivos de configuração no repositório. Para alterar a configuração, confirme as alterações e permita que suas ferramentas de implantação automatizada as levem à produção (depois de executar vários testes automatizados, é claro!)

Et Voila! você tem um registro de todas as alterações na configuração, além da rede de segurança adicional de um sistema automatizado de CI / teste!

Como já foi mencionado, os padrões de arquitetura e design não se limitam ao sistema do produto, mas também à equipe / processo / sistemas que ajudam a produzi-lo.