quinta-feira, 26 de abril de 2007

Não gosto de configuração programática



Não queria escrever sobre nada fora do meu foco atual mas estou com um assunto engasgado que preciso colocar minha opinião pelo menos para marcar presença. Sei que muitos amigos detestam o monte de XML que precisam escrever para configurar os frameworks que usam e entendo porque não gostam de XML.

Fui um dos primeiros entusiastas na adoção de XML na integração de sistemas ainda quando trabalhava com EDI em 2000. O uso de XML tem um monte de vantagens e algumas poucas, porém quase fatais, desvantagens. Só vou falar de algumas desvantagens: violam TDD, são difíceis de localizar erros, acarretam lentidão quando usadas com parsers inadequados e principalmente ser fácil de abusar do seu uso.

Tendo em vista as desvantagens, alguns programadores resolveram expurgar o XML das suas configurações e passaram a fazer a chamada configuração programática.

Entendo por configuração aqueles parâmetros que servem apenas para permitir a instalação e ajuste fino das aplicações em diversos ambientes. Lá devem ficar as informações que podem ser alteradas pelos profissionais de suporte.

Porém nos últimos tempos há um claro abuso deste conceito. Houve uma febre para tornar os sistemas flexíveis e customizáveis.
Os arquivos de configuração cresceram muito. Alguns contêm informações que só dizem respeito ao desenvolvedor do sistema e nunca deveriam estar expostos como configuração. Os arquivos enormes ficaram tão difíceis de alterar que as empresas precisam dispor de programadores especialistas nos frameworks que nada mais fazem do que gerenciar as configurações (Inner-Platform Effect). Ficou mais complexo configurar um sistema do que usar os 237 botões do controle remoto do seu home theater.

1. Solução natural do problema:
  • Configurar por convenção onde se pode saber por experiência onde estão as coisas.
  • Permitir mudanças nas convenções por convenção de forma centralizada para fazer uma vez só na vida com alterações em um único lugar.
  • Limitar as configurações somente àquilo que um profissional de suporte pode fazer em poucos minutos para apagar um "incêndio".
  • Configurações que só dizem respeito aos programadores preferencialmente devem ser feitas com anotações. É claro que respeitando as limitações e imposições dos frameworks de IoC, AOP, etc..
2. Solução adotada pelos defensores de configuração programática
  • Configurar via programação Java
Talvez eu esteja ficando um velho ranzinza mas acho absurdo trocar um configuration manager por outro programador e obrigar que todas as modificações sejam feitas em ambientes de desenvolvimento com Java instalado mais toda a parafernália de IDE, dependências, etc. Para mim a solução de configuração programática apenas engessa os sistemas e não toca no real problema de excesso de customização para gente que não precisa disto.

6 comentários:

marcospereira disse...

Luca, muito bom poder voltar a ler algumas palavras suas. Espero que continue com tempo para blogar.

Sobre o assunto do post, acho que as pessoas decidiram fazer configuração programatica como uma maneira errada de corrigir o excesso de configurações causado pela falta de convenções. O ruim da historia é que as pessoas geralmente não mudam de idéia sobre o assunto.

valeuz...

Anônimo disse...

Concordo completamente com a opinião do Marcos Silva. Querem corrigir um erro com outro ...

Anônimo disse...

Oi Luca, parabéns pelo post.

Quero dizer que também gosto de xml como uma ferramenta para integração de sistemas. Também acho perfeito usar CoC e ter um único lugar onde pode-se configurar a aplicação como um todo sem ter que repetir a mesma configuração para cada item. Quanto às configurações, penso que são de dois tipos: a de publicação e a do framework. A de publicação mexe com alguns parâmetros tipo o endereço do SGBD, por exemplo. Esta poderia estar em um arquivo xml, properties, ini, json, whatever. Provavelmente é pequeno e fácil de ser mantido. De forma que o lay-out do arquivo importará pouco. Quanto a configurar o framework, muita coisa pode ser alterada. Concordo que CoC reduz drasticamente essa configuração. E o que sobrar desta configuração poderia estar em um arquivo xml, java, json... Usar anotações me prende ao framework espalha tudo e se mal usadas, viram uma espécie de embedded-xml. Só as defendo para configurar classes específicas e que não vivem sem o framework.

E desculpe-me pelo comentário maior que o post.

Até.

Andre Barbosa disse...

Issa vira um deadlock. Como disse o Bruno, isso pode virar uma salada de annotations que vai facilitar a vida de quem instala e configura, mas vai dar náuseas no pobre coitado que for manter o código.

Anônimo disse...

Luca, muito bom post.

Estou contigo. A configuração programática a meu ver apenas elimina de certa forma o uso de XML, quando o grande problema é o excesso da necessidade de configurações. Ja ouvi muita gene argumentando que utilizar conf programática bom em virtude da utilização de recursos das IDEs JAVA de code completion, etc. Como se não existisse DTD e Schema... Acredito particularmente em uma tendência de convenções.

Anônimo disse...

Não é difícil de perceber que os parametros burros e estáticos que vc deseja que o pessoal do suporte tenha acesso para alterar podem estar tranquilamente num arquivo properties ou até mesmo num banco de dados, de forma que a configuração programática chupe esses dados. Daí o pessoal do suporte pode até ter uma interface web para alterar isso, o que seria mais prudente e seguro.

Configuração Programática oferece o melhor de todos os mundos. Vários frameworks estão indo por esse caminho: Guice, Waffle, Rifle, Mentawai, etc.

É claro que não ter que configurar devido a convenções, é ainda melhor, mas quando houver configuração, tomara que eu possa faze-la facilmente via código Java ou alguma DSL.

Como eu faço um loop usando XML para configurar 100 actions de crud por exemplo?

Outras vantagens da configuração programática:

# Mais prazerosa e natural, afinal estamos falando de código Java e não de uma especificação em XML.

# Menos propensa a erros e typos, já que uma configuração em Java pode ser compilada antes de ser carregada pela aplicação web.

# Ótima integração com IDEs, permitindo usar recursos como auto-complete, auto-compile (build automático), refactoring, etc.

# Flexibilidade total que apenas uma linguagem de programação pode oferecer, o que te permite criar seus próprios métodos de configuração, loops, ifs, comentários, ou seja, você possui a liberdade para fazer a configuração se adaptar a você e não você se adaptar ao XML.

# Utilizar linguagens de script como JRuby, Groovy, BeanShell, etc. para configurar sua aplicação, possibilitando uma configuração dinâmica que pode ser recarregada automaticamente pelo container a cada modificação.

# O bom e velho JavaDoc, documentando todos os métodos que podem ser utilizados para configuração.

Quem sou eu

São Paulo/Paraty, SP/RJ, Brazil
Engenheiro estrutural COPPE/UFRJ por formação, desenvolvedor Java por experiência e poeta se sobrasse tempo