Mecanismo de realimentação e base federada
Marcelo Mrack
diferente de outros geradores, isso porque a idéia primordial possuir
uma base histórica de desenvolvimento que permita, ao longo do tempo,
reduzir (praticamente a zero) o custo de (re)configuração no sistema
- em outras palavras, quanto mais desenvolvimento é feito, menor será
a quantidade de ajustes necessárias para colocar o próximo sistema em
produção.
Evidente que as técnicas heurísticas e empíricas já em uso pelo
Merlin já dão conta de boa parte do trabalho, mas a questão aqui é
CONTEXTUALIZAÇÃO. Quero dizer que cada ferramenta no ambiente de
desenvolvimento deve ser orientada para a equipe em que ela está sendo
usada e não baseada em um conjunto de configurações fornecidas pelo
fabricante (que embora possam ser boas, sempre têm um custo de ajuste
para adequar ao ambiente onde ela está inserida).
Nesse sentido, busca-se o conceito de computação autonômica tanto
defendido por players como a IBM e a Microsoft. E como colocar isso em
prática?
Minha idéia para resolver isso é AUMENTAR O CONTEXTO para o sistema.
Assim, ao invés do software gerador se basear em um conjunto de
configurações (por exemplo, alguns arquivo XML ou .properties dentro
do seu classpath da aplicação), PORQUE NÃO COLOCAR "NESSE BOLO"
TAMBÉM AS CONFIGURAÇÕES JÁ UTILIZADAS (e arduamente ajustadas) EM
OUTROS DESENVOLVIMENTOS?
O que quero dizer é que devemos reutilizar aquilo que já fizemos.
Simples assim.
Suponha que foi feito o sistema A2, no qual foram perdidas horas e
horas para configurar o ambiente, criar regras de negócio, esquemas de
layout de interface, etc, etc, etc.
Quando partimos para o sistema S2 seria ótimo reutilizarmos tudo
aquilo de bom do sistema S1. Hoje, isso é possível, mas com grande
esforço (copiar, colar, ajustar, herdar, modificar, sincronizar, etc).
Porque o software simplesmente não "pega" aquilo de bom
transparentemente e descarta o ruim?
A idéia aqui é justamente essa. Vou explicar:
Fazemos o sistema S1. Nele perdemos certo tempo para configurar,
definir regras, etc. Ele ficou pronto e está em produção. O Merlin
guardou isso. Fim do sistema S1.
Fazemos o sistema S2. O Merlin detecta em S2 tudo que é igual ou
parecido com o que existe em S1 e com base nisso, já molda a forma
inicial de S2. Nas diferenças, o usuário atua e ajusta. O Merlin
guarda isso. Fim do sistema S2.
Fazemos o sistema S3. O Merlin detecta em S3 tudo aquilo que é igual
ou parecido com o que existe em S2 e S1 e molda a forma inicial de S3.
Nas diferenças, o usuário atua e ajusta. O Merlin guarda isso. Fim do
sistema S3.
...E a coisa continua ao longo do tempo. É provável que para cada
novo sistema Sn que for construído, o número de ajustes necessários
reduza. Em tempo, para sistemas simples (entrada/saída) o custo será
zero.
E como ele faz isso? Compartilhando o environment de desenvolvimento.
Explico:
O sistema de realimentação do Merlin é um diferencial para grandes
sistemas, não para os pequeninos. Em grandes sistemas, a tecnologia 3
camadas é praxe. Nelas, todo o classpath (conjunto de classes e
configurações do sistema) reside no servidor de aplicação. Isso
quer dizer que todas as informações que o Merlin precisa ele pode
obter no servidor de aplicação (ou no arquivo .EAR ou .WAR ou .JAR ou
.SAR, como você quiser interpretar). Assim, ele "funde", com base em
algoritmos de pesos, medidas e taxas de acerto todas as configurações
para chegar na "melhor sugestão" para o novo sistema em
desenvolvimento.
NOTA 1: Lembro, aos desavisados, que o Merlin armazena seus dados de
configuração dentro dos aquivos .class do sistema (via anotações) e
um único arquivo .properties simples. Isso significa, que todas as
informações que estou falando vão estar sempre dentro do arquivo
.EAR (ou outro) da aplicação que estará no servidor de aplicação -
e portanto está disponível.
BASE FEDERADA
Extrapolando esse conceito, outra coisa que eu tenho em mente para o
sistema de realiementação é a existência de uma base federada.
Imagine uma corporação grande (como o Google) que possui filiais ao
redor do mundo, com vários centros de desenvolvimento. É provável
que muitas coisas que um cara faz em um lugar serão exatamente as
mesmas que outro cara está fazendo (ou melhor, já fez) em outro
lugar.
Compartilhar as informações entre todos esses ambientes é uma idéia
interessante, o que promove o reuso ao (quase) extremo. Isso é o
fundamento básico de uma base federada de informações históricas de
desenvolvimento para uma empresa grande.
Mas vamos além (gosto de pensar grande). Imagine o know que existe
dentro da Apache Foundation. Agora imagine que temos nossa base
federada na empresa e a Apache decide abrir a base federada deles para
o público. O que fazemos? Vamos utilizar as informações da base da
Apache na nossa empresa: aquele método de hash maravilhoso pode ser
usado em substituição ao nosso. E melhor, de forma transparente.
CUIDADOS
Quanto mais aumentamos o contexto, maior é a preocupação a ser
tomada. Se na pequena equipe de 3 ou 5 desenvolvedores todo mundo
acessa o código de todo mundo, entre empresas diferentes a coisa pode
não ser bem assim.
Nesse sentido, torna-se óbvio a necessidade de ajuste de perfis de
acesso, tipo de informações publicadas na base, dependências, etc.
Outra questão diz respeito à re-entrância. Quer dizer, imagine no
caso (do exemplo anterior) que o sitema S1 foi modificado após S2,
S3...Sn já estiverem em uso. O que acontece? Várias coisas podem
acontecer.
Modificações no atributo x, da classe y, do pacote z no sistema S1
podem afetar o comportamento do atributo a, da classe b do pacote c no
sistema S2, o que pode afetar o comporamento....bem, dá pra ter uma
idéia do estrago :-)
Esses dois tipos de situações devem ser gerenciados (pois obviamente
não podem ser evitados). Assim, é preciso um mecanismo complexo para
controlar tudo isso (estou sendo redundante, desculpem).
Tão complexo que meu orientador sugeriu eu tirar isso fora da minha
dissertação e propor isso como tese de doutorado. Concordei com ele
que é complexto, mas isso é uma das três bases do Merlin (as outras
duas são a não-geração de código-fonte e a independência de
plataforma).
Bom, por enquanto sobre realimentação é isso. Estou cansado. Quando
eu estiver com menos sono eu volto ao assunto que tem muito pano pra
manga.
Att.