Grow as needed + YAGNI

No meu tempo de experiência com Java EE já pude aprender e constatar bastante coisa. Um fenômeno que se repete com freqüência é a escolha de servidores e componentes que contêm muito mais do que se necessita para a resolução de um problema específico.Um exemplo claro disso é em aplicações que não precisariam de absolutamente nada que o Tomcat não ofereça, mas a escolha padrão acaba sendo um servidor de aplicações “mais parrudo”, como JBoss, WebSphere ou Weblogic. O curioso é que estes últimos servidores de aplicação suportam uma quantidade bem mais ampla de especificações e oferecem bem mais recursos, mas o que eles realmente oferecem de diferencial não é o que está nas especificações, na maioria dos casos.

Muitas vezes o diferencial destes produtos está em funcionalidades nos quais eles excedem as especificações e oferecem facilidades que não são obrigatórias. O fato de oferecer estas funcionalidades extras é muito bom, pois isto traz mais qualidade aos clientes, e isto possivelmente melhora os processos internos do cliente. Apesar disso, é comum vermos escolhas de tecnologia serem feitas porque a opção A oferece muito mais recursos do que a opção B, sendo que na prática as opções oferecidas pela opção B serão plenamente suficientes para atender a todos os “problemas reais” que virão a surgir. Isto quer dizer que é comum a opção A ser escolhida em vez de B sem que se saiba quais recursos de A serão úteis de verdade, mas pela percepção que “A oferece mais do que B”.

Talvez a justificativa para este comportamento seja escolher uma opção que “possua todos os recursos que necessitaremos”. Consigo entender isso. Porém, isto traz o caso comum de usar uma bazuca para matar uma mosca. Sim, com a poluição e evolução das espécies, podemos no futuro encontrar super moscas mutantes do tamanho de um helicóptero, e neste caso espero que você esteja com sua poderosa bazuca para matar essa mosca monstruosa!

Entretanto, para as moscas que eu costumo encontrar, um mata-moscas de plástico resolve o problema. Além disso, eu sei usar bem um mata-moscas de plástico, e foi bem mais fácil de aprender a usá-lo do que aprender a usar uma bazuca. Por oferecer bem menos e ser bem mais simples, o modo de operação do mata-moscas de plástico é algo que uma criança consegue aprender. Já para utilizar a poderosa bazuca matadora de moscas mutantes, é bom ler direitinho os manuais de utilização e se possível fazer o curso prático para fixar bem os conceitos. Afinal de contas você não quer correr o risco de se deparar com uma mosca mutante e não saber usar a bazuca né?

Da mesma forma que as moscas, as aplicações corporativas possuem este tipo de fenômeno. Antes de conhecer as necessidades reais da aplicação, já se definiu o uso do Weblogic com Oracle e possivelmente a configuração de um cluster de alta disponibilidade. Talvez fosse uma aplicação pequena ou média que o Tomcat + Derby ou Postgres ou Mysql pudesse dar conta sem problemas.

Eu venho estudando muito sobre web services nos últimos meses. Também nesta área isto ocorre bastante. Sem conhecer bem as necessidades que se quer resolver, já foi escolhida a pilha de componentes que “oferece tudo de web services”.

Este fenômeno é global, ocorre no mundo todo. Opiniões interessantes sobre isso foram dadas por Bill de hÓra e Rod Johnson. Uma abordagem que pode ser tomada é tomar as decisões de tecnologia baseando-se nos requisitos já inicialmente definidos. Pegar os requisitos funcionais e não-funcionais iniciais da aplicação e então decidir as tecnologias a se utilizar parece uma boa escolha. Desta forma, você possivelmente fará boas escolhas sem trazer desde o começo uma complexidade e custo que possivelmente nunca seriam necessários.

Claro, existem casos em que realmente se utilizará extensamente os recursos avançados do Weblogic e do Oracle, e eles são de fato necessários. Da mesma forma, podem existir web services com altos requisitos de segurança e confiabilidade que te façam depender de recursos do stack WS-*. Se este for o caso, escolha mesmo as opções com mais recursos e utilize tudo que precisar para atender aos requisitos críticos que lhe forem apresentados. Porém, saiba que estes casos são a minoria dentre as aplicações corporativas existentes mundialmente.

Se o seu problema for algo mais comum, escolha produtos e componentes que resolvam bem os problemas apresentados, e se algum dia eles deixarem de atender às necessidades, pondere novamente as suas escolhas. Isto sugere o “Grow as needed” do título. Cresça a sua estrutura conforme necessário, não compre inicialmente uma bazuca se ainda não existem moscas mutantes. E se os seus problemas não mostram claramente a necessidade da bazuca, aí provavelmente surge a sigla do título: YAGNI (You aren’t gonna need it)!

Antes de escolher as opções “mais ricas e robustas” disponíveis, estude se opções mais simples são capazes de resolver os seus problemas, pois se isto for o caso, você provavelmente terá uma configuração mais simples e mais barata e cheia de pessoas capazes de manipulá-la. Isto é melhor do que depender vitalmente de algum fornecedor e precisar contratar o super especialista que é um dos poucos no mundo capazes de resolver seus pepinos.

E claro, se suas decisões puderem ser de componentes open source, você não pagará nada de licença de software e terá uma grande variedade de profissionais disponíveis para te oferecer serviços