Em que ponto é que um arquivo de configuração se tornar uma linguagem de programação?

StackOverflow https://stackoverflow.com/questions/648246

Pergunta

Eu tenho sido ponderando sobre arquivos de configuração e sua relação com o código por um tempo agora e, dependendo do dia e direção do vento minhas opiniões parecem mudar. Mais e mais, embora eu continuo voltando para a realização pela primeira vez tive ao mesmo tempo aprender Lisp: há pouca diferença entre os dados e código. Este parece duplamente verdadeiro para arquivos de configuração. Quando olhou na luz direita um script Perl é pouco mais do que um arquivo de configuração para perl. Isso tende a ter consequências bastante pesados ??para tarefas como QA e divisões do trabalho como quem deve ser responsável por mudar os arquivos de configuração.

A fluência de config para a linguagem de pleno direito é geralmente lento e parece ser impulsionado pelo desejo de ter um sistema genérico. A maioria dos projetos parecem começar pequeno com alguns itens de configuração como onde gravar logs, onde olhar para os dados, nomes de usuário e senhas, etc. Mas, em seguida, eles começam a crescer: características começam a ser capaz de ser ligado ou desligado, as temporizações e ordem das operações começam a ser controlado, e, inevitavelmente, alguém quiser iniciar a adição de lógica a ele (por exemplo, utilizar a máquina 10 se é X e 15, se a máquina for Y). Em um certo ponto, o arquivo de configuração se torna uma linguagem específica de domínio, e um mal escrito para isso.

Agora que eu divagava para definir o palco, aqui estão as minhas perguntas:

  1. O que é o verdadeiro propósito de uma configuração arquivo?
  2. Deve ser feita uma tentativa para manter Arquivos de Configuração simples?
  3. Quem deve ser responsável pela tomada alterações aos mesmos (desenvolvedores, usuários, admins, etc.)?
  4. deveriam ser fonte controlada (Ver pergunta 3)?

Como eu disse anteriormente minhas respostas a estas perguntas mudar constantemente, mas agora eu estou pensando:

  1. Para permitir que um não-programadores para a mudança grandes pedaços de comportamento de forma rápida
  2. sim, qualquer coisa que não é grosseiramente grained deve estar em código
  3. usuários deve ser responsável por arquivos de configuração e os programadores devem ser responsável por uma configuração camada entre arquivos de configuração e código que dá mais grão fino controle da aplicação
  4. não, mas a camada do meio mais refinado deve ser
Foi útil?

Solução

perguntas muito interessantes!

I tendem a limitar meus arquivos de configuração para um formato muito simples "chave = valor", porque eu concordo totalmente com você que arquivos de configuração pode rapidamente tornar-se programas full-blown. Por exemplo, qualquer um que já tentou "configure" OpenSER sabe o sentimento que você está falando:. Não é a configuração, é (dolorosa) de programação

Quando você precisa de seu aplicativo para ser muito "configurável" de maneiras que você não pode imaginar hoje, então o que você realmente precisa é um plugins sistema . Você precisa desenvolver sua aplicação de uma forma que alguém pode codificar um novo plugin e ligá-lo em sua aplicação no futuro.

Assim, para responder às suas perguntas:

  1. O que é o verdadeiro propósito de um arquivo de configuração?

    Eu diria que, para permitir que as pessoas que irão instalar seu aplicativo para ser capaz de tweek alguns parâmetros relacionados à implantação, como nome do host, número de threads, nomes dos plugins que você precisa, e os de implantação de parâmetros para aqueles plugins (confira a configuração do FreeRadius para um exemplo deste princípio), etc .. Definitivamente não é o lugar para expressar a lógica de negócios.

  2. deve ser feita uma tentativa para manter os arquivos de configuração simples?

    Com certeza. Como você sugeriu, "programação" em um arquivo de configuração é horrível. Eu acredito que deve ser evitado.

  3. Quem deve ser responsável por fazer mudanças para eles (desenvolvedores, usuários, administradores, etc.)?

    Em geral, eu diria que os administradores, que implantar o aplicativo.

  4. deveriam ser fonte controlada (ver pergunta 3)?

    Eu normalmente não fonte de controle de arquivos de configuração em si, mas eu do source-controlar um arquivo de configuração do modelo, com todos os parâmetros e seus valores padrão, e comentários que descrevem o que eles fazem. Por exemplo, se um arquivo de configuração é nomeado database.conf, eu costumo fonte-controlar um arquivo chamado database.conf.template. Agora é claro que eu estou falando sobre o que eu faço como um desenvolvedor . Como administrador , eu pode querer fonte-controle as configurações reais que eu escolhi para cada instalação. Por exemplo, conseguimos algumas centenas de servidores remotamente, e precisamos manter o controle de suas configurações: escolhemos fazer isso com fonte de controle

    5. .

Editar : Embora eu acredito que o acima para ser verdade para a maioria das aplicações, sempre há exceções, é claro. Seu aplicativo pode permitir que seus usuários a normativa configurar dinamicamente complexos, por exemplo. A maioria dos clientes de e-mail permitem que os usuários definam regras para a gestão dos seus e-mails (por exemplo, "todos os e-mails provenientes de 'doe john' e não ter me no campo Para: deve ser descartada"). Outro exemplo é um aplicativo que permite ao usuário definir uma nova oferta comercial complexa. Você também pode pensar em aplicações como Cognos que permitem que seus usuários para criar relatórios de banco de dados complexos. O cliente de e-mail provavelmente irá oferecer ao usuário uma interface simples para definir as regras, e isso vai gerar um arquivo complexo de configuração (ou talvez até um pouco de código). Por outro lado, a configuração definida pelo usuário para as ofertas comerciais pode ser salvo em um banco de dados, de uma forma estruturada (nem uma chave = estrutura de valores simples nem uma parte do código). E algumas outras aplicações pode até permitir que o usuário para o código em python ou VB, ou alguma outra linguagem de automação capaz. Em outras palavras ... sua milhagem pode variar.

Outras dicas

Ok. Você terá alguns usuários que querem uma configuração muito simples, você deve dar a eles. Ao mesmo tempo, você terá solicitações constantes de "você pode adicionar este? Como eu faço no arquivo de configuração?", Eu não vejo por que você não pode suportar ambos os grupos.

O projeto que estou trabalhando atualmente em utiliza Lua para seu arquivo de configuração. Lua é uma linguagem de script, e ele funciona muito bem nesse cenário. Não está disponível um exemplo da nossa configuração padrão .

Você vai notar que é principalmente key = declarações de valores, onde o valor pode ser qualquer uma Lua de tipos built-in. A coisa mais complicada existem listas, e eles não são realmente complicado (é apenas uma questão de sintaxe).

Agora estou apenas esperando por alguém para perguntar como configurar a porta do seu servidor para um valor aleatório cada vez que iniciá-lo ...

Recentemente eu estava trabalhando em cima de um projeto e eu percebi que eu queria ter condicionais dentro da minha arquivo de configuração - que já tinha sido apenas uma muito simples um do formulário: 


key = val
key2 = val
name = `hostname`

Eu não queria escrever uma mini-linguagem, porque a menos que eu fiz isso com muito cuidado eu não podia permitir a flexibilidade que seria útil.

Em vez disso, decidi que eu teria duas formas:

  1. Se o arquivo começou com "#!" e foi executável eu analisar o resultado de executá-lo.

  2. Caso contrário, eu tinha lido como está

Isso significa que eu posso agora permitem que as pessoas a escrever "arquivos de configuração" que se parecem com isto: 

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

Desta forma, fico com a potência de um arquivo de configuração dinâmica, se o usuário quiser usá-lo, ea simplicidade de não ter que escrever o meu próprio mini-linguagem.

Cada (suficientemente longa duração) esquema de arquivo de configuração eventualmente torna-se uma linguagem de programação. Devido a todas as implicações que você descreve, é sábio para o designer-arquivo de configuração para perceber que ela é o autor de um linguagem de programação e plano nesse sentido, para que ela futuros usuários fardo com mau legado.

Eu tenho uma filosofia diferente sobre arquivos de configuração. Dados sobre como um aplicativo deve ser executado ainda é de dados , e, portanto, pertence a um armazenamento de dados, não em código (um arquivo de configuração IMO é o código). Se os usuários finais precisam ser capazes de alterar os dados, o aplicativo deve fornecer uma interface para fazê-lo.

Eu só uso arquivos de configuração para apontar para armazenamentos de dados.

Você poderia transformar a teoria da computação para definir o que conta como uma linguagem de programação. Se o formato de arquivo de configuração é Turing completa então razoavelmente conta como uma linguagem de programação. Por esta definição, um formato de arquivo para descrever níveis de Sokoban conta como uma linguagem de programação (veja < a href = "http://web.cs.ualberta.ca/~joe/Preprints/Sokoban/index.html" rel = "nofollow noreferrer"> aqui ). Há outros níveis de complexidade abaixo Turing completo que também pode contar, como gramática regular e < a href = "http://en.wikipedia.org/wiki/Pushdown_automaton" rel = "nofollow noreferrer"> Pushdown Automata .

Outra maneira de olhar para ele é que muitos arquivos de configuração só são capazes de marcação de dados, enquanto que uma linguagem de programação adequada deve ser capaz de implementar algoritmos . Por exemplo, JSON é um formato de arquivo de configuração, enquanto ECMA Script é uma linguagem de programação.

Aqui está o meu pensamento:

  1. Para permitir que o comportamento de tempo de execução de um aplicativo a ser modificado facilmente. Isso pode ser por programadores ou não programadores, dependendo das necessidades. Isso pode ser durante o desenvolvimento, mas muitas vezes eu visualizar arquivos de configuração como uma forma de ajudar a fazer um programa mais flexível em qualquer ponto.

  2. Sim. Eu acho que os arquivos de configuração deve ser tão simples quanto possível, dada a restrição de que você pode precisar de várias opções para controlar comportamentos diferentes do seu tempo de execução. Eu prefiro agrupar as definições de configuração, e simplificando-os, tanto quanto possível.

  3. depende do que e por que a mudança está sendo feita. Se os usuários vão ser mudá-lo, um front-end deve ser feito para escondê-los dos detalhes. O mesmo acontece muitas vezes, de não-desenvolvedores em geral.

  4. Muitas vezes o controle de origem da configuração "default", mas tem uma maneira de substituir esse por sistema, para o tempo de execução real.

Como para adicionar lógica para o arquivo de configuração - Eu gostaria de evitar isso. Eu acho que é melhor apenas têm a opção de arquivo de configuração na lógica na sua aplicação. Comportamento em config arquivos leva a uma falta de manutenção e de entendimento, na minha experiência. I fortemente preferem manter arquivos de configuração mais simples possível.

Eu tendo a concordar com a premissa desta questão. Eu evito me metendo problemas com a previsão inicial de que isso vai acontecer, e, portanto, não rolo meu próprio sistema de configuração.

  • Ou eu usar facuility configuração dos sistemas operacionais (como um plist, ou gconf ou o que for apropriado),
  • Ou um arquivo plano simples, como pode ser tratado por algo como um fora do analisador INI prateleira.
  • morder a bala e ligar um analisador de linguagem leve, geralmente lua, às vezes tcl para o aplicativo,
  • ou armazenar dados em um banco de dados relacional SQLite ou similar.

E me resignar a viver com qualquer decisão que eu fiz, ou se eu não posso, refatorar para usar uma das opções acima que melhor se adequa à aplicação.

O ponto é, não há realmente nenhuma razão para usar uma solução de configuração home-grown. Por um lado, é mais difícil para os usuários tenham que aprender um novo formato de configuração específico da aplicação. Por outro lado, Você se beneficia de todas as muitas correções de bugs e atualizações que vêm livre quando se utiliza uma solução off-the-shelf. Finalmente, fluência característica é colocado para descansar, porque, bem, você realmente não pode simplesmente adicionar mais uma característica sem realmente fazer uma grande reformulação causa o sistema de configuração não é realmente em suas mãos, em primeiro lugar.

Eu acredito que sua pergunta é muito relevante, dada a mudança para "interfaces fluentes". Muitos desenvolvedores têm "visto a luz" com respeito a aplicações XML configurado. Usando XML pode ser muito detalhado e difícil de editar corretamente (especialmente se nenhum esquema é fornecido). Ter uma interface fluente permite ao desenvolvedor configurar o aplicativo em uma linguagem específica de domínio com a ajuda de alguns pares chave-valor a partir de um arquivo de configuração de texto simples (ou talvez parâmetros de linha de comando). Ele também faz com que seja muito fácil de instalar e configurar novas instâncias do aplicativo para testar ou o que quer.

Aqui estão as minhas respostas à sua pergunta:

  • O que é o verdadeiro propósito de uma configuração arquivo?

Um arquivo de configuração é uma forma de permitir que o usuário para personalizar o comportamento do seu programa em tempo de execução.

  • Deve ser feita uma tentativa para manter Arquivos de Configuração simples?

Idealmente, eu acho que os arquivos de configuração deve pelo menos ser complementada por uma interface fluente para configurar o programa (isto é útil em muitos aspectos). Se você precisar de um arquivo de configuração, em seguida, ele deve ser mantido muito simples, nada mais do que pares chave-valor.

  • Quem deve ser responsável pela tomada alterações aos mesmos (desenvolvedores, usuários, admins, etc.)?

Eu acho que a resposta a esta depende da sua organização. Deve ser da responsabilidade da pessoa a implantação do software para garantir que ele está configurado corretamente.

  • deveriam ser fonte controlada (ver pergunta 3)?

Vou roubar esta resposta de alguém :) Eu gosto da idéia de armazenar uma configuração modelo no controle de origem e modificá-lo para as necessidades de cada usuário local. As chances são de arquivo de configuração de um desenvolvedor é o pesadelo de outro desenvolvedor, por isso é melhor deixar as coisas que variam por usuário fora do controle de origem. Ter um modelo é também uma boa maneira de deixar a pessoa a implementação do aplicativo (ou outros desenvolvedores) ver exatamente o que os valores são válidos para o arquivo de configuração.

Já vi programas python onde o arquivo de configuração é código. Se você não precisa fazer nada especial (condicionais, etc.) ele não parece muito diferente de outros estilos de configuração. por exemplo. Eu poderia fazer uma config.py arquivo com coisas como: 

num_threads = 13
hostname = 'myhost'

ea única carga sobre o usuário, em comparação com (digamos) arquivos INI, é que eles precisam para colocar '' em torno de cordas. Sem dúvida, você poderia fazer a mesma coisa em outras linguagens interpretadas. Dá-lhe capacidade ilimitada para complicar seu arquivo de configuração, se necessário, com o risco de, possivelmente, assustando seus usuários.

Sim, arquivos de configuração deve ser simples. Eles não deve conter 'lógica' em si - pensar neles como uma lista de expressões em se declarações, não as declarações condicionais na sua totalidade

.

Eles estão lá para permitir que o usuário decidir qual das opções codificados dentro do aplicativo deve ser usado, por isso não tentar fazê-los complicado, ele vai acabar por ser auto-destrutivo - você pode acabar escrita arquivos de configuração simples para controlar a forma como o arquivo de configuração original deve ser configurado de outra forma!

Uma das finalidades do trabalho "Oslo" da Microsoft é permitir (embora não exigir) resolução desta questão.

  1. Uma aplicação seria lançado com modelos de quaisquer novos componentes que inclui. Seria também usar modelos existentes. Por exemplo, ele pode incluir um serviço web, para que ele pudesse voltar a utilizar o modelo de sistema de um serviço web.
  2. Os modelos incluem metadados descrevendo-os, incluindo informações suficientes para obter ferramentas para acessá-los, quer textualmente ou graficamente.
  3. Peças dos modelos corresponderá a "configuração"

Isto significa que o equivalente a arquivos de configuração de hoje pode ser o suficiente ricos para apoiar tanto textual e edição gráfica de sua configuração. A ferramenta gráfica será fornecido com "Oslo" (nome de código "Quadrante").

Eu serei o contrarian e apresentá-lo apenas uma linguagem quando se incorpora mais do que pode ser representado por XML; ou então quando XML é considerado um idioma.

Como alternativa, a maioria dos arquivos de configuração pode ser pensado como classes, mas com apenas propriedades e há métodos. E sem métodos, eu não acho que é uma linguagem.

Em última análise, "linguagem" é uma abstração mole, mas sim, as bordas são ambíguos.

O código das nossas aplicações torna-se menos importante ... Há scripting, existem todos os tipos de atributos que definem o comportamento de classes, métodos, argumentos de métodos e propriedades. Os usuários podem definir gatilhos de banco de dados e restrições de banco de dados. Não pode ser muito complicado arquivos de configuração. Às vezes, o usuário pode definir stylsheets XSLT para manipular a entrada e saída porque os nossos sistemas precisam estar abertos (SOA). E há coisas como BizzTalk que precisa de configuração complexa demais. Os usuários podem definir fluxos de trabalho complexos.

Nós temos que escrever um código melhor para lidar com esse ambiente complexo, então o código de nossos aplicativos se torna mais importante ...

Eu sou um grande fã do uso de programas de Python como arquivos de configuração, especialmente para daemons. Eu gosto de tomar o rumo de tornar o daemon esvaziar completamente de configuração, exceto para a "porta de configuração". O programa pitão em seguida liga-se que o daemon e prossegue para criar objectos do daemon e fio-los em conjunto para criar a configuração desejada. Depois que tudo estiver configurado, o daemon pode então ser deixado para funcionar com o seu próprio. Os benefícios, é claro, são que você começa uma linguagem de programação completa desenvolvida para escrever seus arquivos de configuração e uma vez que você já tem uma maneira de falar com o daemon de outro programa, você pode usá-lo para depuração e obter estatísticas. A principal desvantagem é ter que lidar com mensagens de outro programa, chegando a qualquer momento.

arquivo de configuração : "Qual é o meu propósito?"
Você : "Configurar a manteiga"
arquivo de configuração : "Ok ..."
arquivo de configuração : "Qual é o meu propósito?"
Você : "Você configurar manteiga."
arquivo de configuração : "Oh meu Deus."

  1. Não há "verdadeiro propósito" de um arquivo de configuração. Sua tudo o que faz sentido para a sua aplicação. Em geral, as coisas que diferem (ou podem ser diferentes) entre as máquinas e não mudam no meio do seu aplicativo executado provavelmente deve estar em um arquivo de configuração. Padrões, portas e endereços para outros serviços são todos grandes candidatos. Chaves e segredos também são grandes candidatos, mas deve ser tratado separadamente do seu configuração normal, por razões de segurança. Eu discordo que o propósito de um arquivo de configuração é permitir mudanças rápidas de ser feitas. O objetivo deve ser o de permitir a flexibilidade na configuração de sua aplicação. Se um arquivo de configuração é um rápido fácil de modo a permitir que a flexibilidade, tanto melhor -. Mas você deve não ser a intenção seus arquivos de configuração para ser mudam frequentemente

  2. Sim e não. Se você atempt para fazer simples código da sua aplicação? Sim. Você deve tentar fazer tudo o que você escrever simples e direto ao ponto. Não mais complicado do que precisa ser. Mesmo acontece com a sua configuração. No entanto, isso é muito específico do aplicativo. Codificar o que deve ser em config porque iria fazer a sua config "muito complicado" é mau design. Na verdade, tentando "manter as coisas simples" é por isso que os arquivos de configuração acabar por ser uma bagunça gigante. Às vezes, o movimento mais simples é modularizar. É por isso que seus arquivos de configuração deve ser escrito em um langauge bem conhecida programação de propósito geral - não alguma linguagem de configuração terrível (leia-se: todas as "línguas de configuração" chupar ).

  3. Mais uma vez, quem deve ser modificando arquivos de configuração é completamente dependente da aplicação. Mas eu concordo com miniquark, quem está implantando o aplicativo deve estar no comando da configuração.

  4. tudo o controlo da fonte pode. controle de origem é grande. Você pode rolar coisas de volta super-fácil e você tem um histórico completo das alterações feitas e um registro de quem fez essas mudanças. Então, por que não?

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top