Archive for August, 2006

O Melhor Golden Hammer Para o Serviço

Tuesday, August 29th, 2006

O conceito de Fábrica de Software parece muito atrativo a princípio, mas peca em diversos pontos. Um caso ocorreu com um cliente meu há algum tempo.

Eu fui chamado para ajudar na definição de um projeto. O sistema era um pequeno website teoricamente componentizado (utilizando algumas das técnicas de Component-Based Design) que seria projeto-piloto de uma grande série, muito lucrativa para meu cliente.

O problema é que o usuário (que era uma outra empresa) já havia feito boa parte do trabalho de levantamento do sistema, o contato dos técnicos do cliente seria com os analistas de negócio do usuário final, não com os usuários. Acontece que boa parte não significa tudo e quem já trabalhou com processos em cascata (waterfall) sabe que isso costuma não dar muito certo.

O cliente trabalha em fábrica de software utilizado RUP. Alguns artefatos de análise já estavam prontos, mas não todos. Considerando que a análise já era considerada pelo usuário como feita ele, obviamente, não iria pagar por ela. Na instância de RUP utilizada pelo meu cliente (se não me engano homologada pela IBM até) deveria haver uma fase de projeto (design) após a análise, e esta fase recebia como insumo os artefatos produzidos na análise.

Legal, mas cadê os artefatos?

Como RUP não é minha especialidade, eu fui chamado para avaliar os artefatos existentes, a arquitetura a ser utilizada e dar um parecer sobre a viabilidade ou não do projeto no aspecto técnico. Olhando aquele monte de casos de uso e sequer um domain model pronto meu parecer foi claro: não há como entregar este sistema utilizando a metodologia atual sem completarmos a análise.

Bom, e agora? Minha sugestão foi mudar a metodologia de desenvolvimento. O cliente não exigia qualquer metodologia, apenas a produção de um documento de arquitetura extremamente minucioso e por isso mesmo ineficiente, mas que poderia ser gerado por uma metodologia ágil.

Metodologias ágeis pressupõem contato constante com o cliente e no caso nosso cliente seria o analista de negócios, que estava disponível para dirimir dúvidas. Trabalhando com iterações curtas e entregas frequentes o usuário estaria sempre vendo e corrigindo o curso, sem necessidade de uma grande fase de análise (seja num modelo iterativo como RUP ou não). Não é um case para XP, mas diversas técnicas ágeis podem ser facilmente empregadas neste cenário.

A sugestão foi bem aceita pelo corpo técnico, mas a gerência entrou em desespero. A fábrica já funcionava com a metodologia há alguns anos, mesmo não sendo nenhum exemplo canônico de eficiência, como mudar de uma hora para outra? O tempo a ser tomado para a mudança, argumentei, não seria tão longo com um líder de equipe e alguma dedicação. A equipe de técnicos era muito boa, acima da média na verdade, e não teria tantos problemas em assimilar as novas técnicas.

O problema não é a metodologia que a fábrica usa, nem o tempo, nem sequer a clássica resistência à metodologias ágeis. O problema era que aquilo era uma fábrica! Uma fábrica produz quase sempre a mesma coisa e sempre do mesmo modo. Se você muda o modo como as coisas são produzidas, como fica a teórica vantagem de ter uma fábrica?

Então, ou projetos para fábricas devem seguir o mesmo molde ou você tem muitas fábricas. Uma fábrica que permita dinamismo de processos não está seguindo os princípios do conceito, de padronizar para baratear. Muitas vezes as empresas de desenvolvimento fazem sim a mesma coisa repetida ad eternum, na minha experiência a maioria dos pequenos projetos é feita desta maneira.

Ocorre que nem todos são. Mesmo entre projetos pequenos de sites e aplicações web nós temos casos como este, que tirariam muito mais proveito de uma metodologia com características específicas (seja RUP, XP ou Scrum) do que a utilizada. Considerando que eu nunca vi uma fábrica que realmente cumprisse as vantagens teóricas sem desvantagens muito impactantes (como sacrificar qualidade pelo preço).

Mas este post nem visa criticar a vantagem teórica de fábricas de software, o foco é outro. A idéia da historinha é mostrar que alguém montando uma fábrica deve ter em mente é que este modelo de desenvolvimento não se aplica a todos os projetos que a empresa pode ter pela frente. Se sua empresa pode se dar ao luxo de negar um projeto porque não atende às exigências da fábrica ótimo, mas se não pode você deve ter um plano-B.

No caso específico deste projeto as pessoas competentes ainda estão discutindo o que fazer dele.

MVC e Camadas

Monday, August 28th, 2006

Acabo de escrever um artiguinho novo. Eu ia responder na Java-BR pela enésima vez sobre a diferença entre Camadas e MVC, resolvi criar algo que possa apenas linkar.

Bom, esperando feedback: MVC e Camadas.

Intervalo Comercial

Monday, August 28th, 2006

Alguns já devem ter percebido que coloquei alguns banners mencionando os serviços de consultoria que presto. Bem, ocasionalmente um artigo ou post neste blog fazem com que eu receba e-mails de pessoas com dúvidas e principalmente buscando aplicar as técnicas mostradas na sua empresa. O problema é que muitas vezes as empresas não têm pessoal especializado para isso, e continuam fazendo as mesmas coisas da mesma maneira.

Há algum tempo eu venho prestando serviços de consultoria para diversos clientes, inclusive comento bastante sobre as realidades que percebo aqui. Os banners e links para a página de serviços são um convite. Tantas vezes temos nos fóruns da vida perguntas como: “Me colocaram a tarefa de escolher um framework web para a empresa, qual eu escolho?”. São pessoas que podem até ser bons técnicos dentro do seu escopo mas não têm visão da indústria para tomar decisões cruciais para um sistema ou a empresa como um todo.

Nos meus serviços de consultoria eu vejo alguns arquétipos:

  • Adorável Bomba: A empresa acaba de fechar um projeto altamente estratégico e/ou lucrativo para um cliente importante, interno ou externo. O problema é que este sistema deve ser feito com cuidado excepcional, fugindo do feijão-com-arroz diário. Não há tempo para treinamentos longos.
  • Crescimento Desordenado: A empresa ou equipe começou pequena e até então funcionava muito bem, obrigado. O problema é que as coisas estão crescendo e é preciso definir processos e metodologias a serem utilizadas. Compramos algo pronto ou criamos a nossa? Se compramos, como adaptamos? Se criamos, criamos o quê?
  • Novos Mares: O mundo evoluiu e finalmente a empresa vai implantar aquela tecnologia nova. Temos treinamento, temos um projeto-piloto… e não temos ninguém para dar direção à equipe. Por mais treinamento acadêmico que exista, é preciso experiência para tocar um projeto.
  • Novas Velhas Coisas: Após algum tempo tentando entender uma tecnologia, sejam componentes distribuídos, SOA ou EJBs, a empresa finalmente resolve voltar ao básico. Nada de tutoriais rápidos sobre como fazer deploy de um EAR no WebLogic, vamos estudar o que diabos são componentes distribuídos e como eles podem ajudar a nossa empresa.
  • Houston, We Have a Problem: A empresa contratou uma consultoria externa ou possui uma equipe interna que está há meses desenvolvendo um sistema muito importante. Meses demais, na verdade. É preciso que alguém verifique o que foi feito e avalie se está no caminho certo ou não, antes que o orçamento do ano inteiro vá pelo ralo…

Estes serviços pedem um consultor. Colocar uma tarefa desta nas mãos de uma pessoa não-capacitada é um bom meio para assassinar um projeto e queimar dinheiro e muitas vezes não faz sentido contratar alguém só para atuar em serviços pontuais.

Se você se encontra em uma(algumas) desta(s) situação(ões) e gosta do que lê aqui entre em contato.

Java Magazine: Interface Gráfica com JGoodies

Friday, August 25th, 2006

Saiu na JavaMagazine deste mês uma excelente matéria do Hugo Vidal sobre interfaces gráficas. Leitura obrigatória para quem trabalha com interfaces ricas.

Trabalhei alguns meses com o Hugo e além de ser uma das pessoas que mais entendem de componentização que conheço ele vive o assunto da matéria todo santo dia. Parabéns, Hugo e DevMedia!

Update: Faltou o link pro site do Hugo: http://www.componenthouse.com/

Bases de Dados São Recursos?

Thursday, August 24th, 2006

Quase todo sistema acaba persistindo dados de alguma forma, geralmente em grandes repositórios conhecidos como bancos de dados. Recentemente, os Sistemas gerenciadores de Bancos de Dados vêm perdendo sua posição como centro do universo para aplicações coorporativas e vem a pergunta: qual o papel do banco de dados num sistema coorporativo moderno? O banco de dados faz parte do seu sistema ou é apenas um recurso acessado por ele, como um filesystem ou servidor de e-mails?

Bancos de dados coorporativos foram o grande xodó das empresas (ainda são em boa parte delas). O raciocínio é simples: o objetivo do sistema é manipular e armazenar dados. Se eu preciso que vários sistemas (processadores de dados) acessem o mesmo dado, é bom que eles estejam em um lugar comum, daí o SGBD.

Banco Corporativo

O SGBD é o repositório de dados supremo, formando o Banco de Dados Coorporativo. Este, que fisicamente pode estar espalhado em diversos SGBDs de fabricantes diversos, é acessado por todos os sistemas. Na verdade, ao especificar um sistema neste ambiente a coisa mais problemática costuma ser sentar-se com a equipe de DBAs responsável para que esta avalie suas necessidades, geralmente criando views que permitem ao seu sistema acessar os dados.

O problema neste caso é que na evolução da tecnologia, não são apenas os dados que são comuns a diversos sistemas, mas também a lógica, o processamento. Não é admissível num sistema moderno a existência de lógica duplicada, um sistema deve reutilizar os componentes (ou serviços) providos por outros.

Ok, mas e os dados? Bem, os componentes de software (sejam business components vindos de CBD ou serviços SOA ou qualquer outra coisa neste sentido) possuem como grande característica o seu encapsulamento. A lógica interna ao componente, suas estruturas de dados e demais aspectos não devem vazar para fora deste. Isto inclui os dados.

Os dados pertencentes a um componente não devem vagar para fora dele. De uma maneira geral, um componente recebe e retorna apenas objetos por valor, ou seja: cópias dos objetos que mantêm dentro dele, que podem ser modificados pelo cliente e não vão interferir os objetos reais. Com a tecnologia atual e dependendo da granularidade do componente isto nem sempre é viável ou desejável, mas é a teoria (para este tipo de decisão que você precisa de um arquiteto experiente).

Componentes

Então, se nossos componentes têm por princípio básico proteger a implementação de algum conceito, devemos permitir acesso direto á base de dados? Não, pelo menos não enquanto pudermos evitar. O acesso aos dados deve ser feito unicamente pela API do componente, nunca quebrando o encapsulamento deste para injetar dados diretamente no banco. Veja o diagrama acima, bases de dados sequer são mencionadas!

Independente de o seu sistema ser construído com componentes, serviços ou apenas uma grande massa monolítica de código (como são a maioria dos sistemas), é importante definir o que é banco de dados corporativo do que é o repositório que guarda os dados da sua aplicação/componente/serviço.

Se sua aplicação (/componente/serviço) não guarda dados encapsulados, ou seja: se sua empresa insiste que você use um banco de dados coorporativo, trate o SGBD como um outro sistema com o qual você se comunica. Se seu sistema não pode garantir que os dados neste depósito não serão alterados por outros sistemas então o que você tem é uma integração, não um lugar para guardar seus objetos. Neste caso, utilize as técnicas clássicas de Mappers e Anticorruption-Layers.

Se você precisa acessar dados em um SGBD corporativo, utilize também estas técnicas. Não é porque seu sistema se comunica com este outro componente (o banco corporativo) via JDBC que ele é sua persistência. Utilizar um framework de ORM como Hibernate ou EJB 3.0 (JPA) é algo que eu não recomendaria porque o framework vai considerar que o banco de dados é sua persistência, não um outro sistema a ser integrado. EJB 3.0 por exemplo traz o mapeamento entre classes e tabelas para dentro dos seus arquivos-fonte, isto só é desejável se esta informação representa metadados do seu aplicativo, não configuração. Uma abordagem mais sadia mantendo a produtividade de um framework (afinal, ninguém gosta de escrever JDBC…) pode ser obtida utilizando frameworks ORM com propostas diferentes, como o iBatis.

Nestes dois casos, o SGBD é um recurso, não uma parte da aplicação. É como o servidor de e-mail: pode ser crucial para seu sistema funcionar mas não faz parte dele. Mais que esconder a implementação da persistência, a Camada do seu sistema que tem contato com o SGBD deve se preocupar em checar entradas e saídas, pré e pós condições, exatamente como quando fazemos chamadas a outros sistemas ou componentes.

Integracao

Já no caso oposto, com seu sistema encapsulando completamente o banco de dados, temos o SGBD como o local onde nossos objetos são armazenados. Neste caso o banco de dados faz parte da aplicação e devemos utilizar a Camada de Persistência para acessá-lo. Esta Camada tem por dever esconder da Camada de Negócios detalhes sobre como a persistência é implementada, na verdade ela esconde simplesmente que existe algo chamado Persistência, visto que para a Camada de Negócios persistência é algo transparente.

Integrado

Apesar de o banco de dados ser fisicamente uma entidade separada do programa (seu binário, WAR, EAR ou o que for), conceitualmente ele faz parte da aplicação. Note que isto não quer dizer que existe um esquema de dados físico (table schema, database ou coisa parecida) para cada componente. O esquema de dados pode residir em qualquer SGBD, mesmo um compartilhado. O que importa é que quem lê e edita aqueles dados é apenas sua aplicação.

Enquanto componentes ou serviços não fazem parte da arquitetura corporativa das empresas vamos conviver com bancos de dados corporativos, é bom que nossos sistemas se preparem para conviver pacificamente com eles.

RioJUG: Reunião de Hoje (21/08/2006)

Monday, August 21st, 2006

Como já mencionado neste blog, hoje temos mais uma reunião no RioJUG, desta vez com o assunto EJB 3.0:

EJB 3
Dia: 21/agosto/2006 (segunda-feira)
Horário: 19:00 horas
Duração: 2 horas
Local: Auditório do SENAC CIT - Rua Santa Luzia, 735 - 7o. andar, Centro
Dica de Acesso: Estação Cinelândia do Metrô pela saída Santa Luzia, atrás do Consulado Americano

Entrada Gratuita e Sem Inscrições Prévias

Coffe-break oferecido pelo nosso patrocinador Quality Software.

Sorteio de assinaturas das Revistas “Mundo Java”, “Java Magazine” e “SQL Magazine”, para os presentes.

A Palestra:

A especificação EJB trouxe a programação baseadas em componentes distribuídos para as massas, e representou uma grande simplicação em relação à tecnologias anteriores como CORBA e MTS/COM. Da mesma maneira, EJB representou um avanço ao tratar transações e outros serviços horizontais de maneira declarativa.

Entretanto EJB, mesmo com seus progressos, apresentava problemas significativos em áreas como testabilidade, facilidade de implementação e possuia um modelo de componentes persistentes (Entity Beans) definitivamente falho em diversos aspectos.

A nova encarnação de EJB é um grande overhauling, destinado à contornar esses problemas. Com inovações como “POJO based programming”, uso extensivo de anotações, injeção de dependências e configuração baseada em “defaults”, EJB 3 mostra que aprendeu algumas lições com projetos como Spring e Hibernate.

O Palestrante:

Marcos Eliziário é um arquiteto de software baseado no Rio de Janeiro, atualmente trabalhando como Arquiteto em um projeto de e-commerce e B2C de uma grande rede de varejo sediada no Brasil, além de coordenador do RioJUG (Grupo de Usuários Java do RJ).

Quem assistiu à palestra do Eliziario no RJDD sabe que pode esperar uma apresentação divertida e com poucas, muito poucas papas na língua…

De volta a POA

Wednesday, August 16th, 2006

Mais uma vez estarei em porto Alegre, desta vez uma estadia mais curta. Saio do Rio hoje e volto sexta de manhã.. se alguém não ligar para a final e resolver tomar uma cerveja me avise ;)

Rafael Divaga: Componentes x SOA

Wednesday, August 16th, 2006

O tema que tem atraído meu interesse também motivou um post do Rafael, muito boa leitura.

Reunião de Agosto do RioJUG: EJB 3.0

Thursday, August 10th, 2006

Marcos Eliziário vai conduzir uma palestra sobre EJB 3.0 na próxima reunião mensal do RioJUG. Se você estiver no Rio não perca a chance!

EJB 3
Dia: 21/agosto/2006 (segunda-feira)
Horário: 19:00 horas
Duração: 2 horas
Local: Auditório do SENAC CIT - Rua Santa Luzia, 735 - 7o. andar, Centro
Dica de Acesso: Estação Cinelândia do Metrô pela saída Santa Luzia, atrás do Consulado Americano

Entrada Gratuita e Sem Inscrições Prévias

Coffe-break oferecido pelo nosso patrocinador Quality Software.

Sorteio de assinaturas das Revistas “Mundo Java”, “Java Magazine” e “SQL Magazine”, para os presentes.

A Palestra:

A especificação EJB trouxe a programação baseadas em componentes distribuídos para as massas, e representou uma grande simplicação em relação à tecnologias anteriores como CORBA e MTS/COM. Da mesma maneira, EJB representou um avanço ao tratar transações e outros serviços horizontais de maneira declarativa.

Entretanto EJB, mesmo com seus progressos, apresentava problemas significativos em áreas como testabilidade, facilidade de implementação e possuia um modelo de componentes persistentes (Entity Beans) definitivamente falho em diversos aspectos.

A nova encarnação de EJB é um grande overhauling, destinado à contornar esses problemas. Com inovações como “POJO based programming”, uso extensivo de anotações, injeção de dependências e configuração baseada em “defaults”, EJB 3 mostra que aprendeu algumas lições com projetos como Spring e Hibernate.

O Palestrante:

Marcos Eliziário é um arquiteto de software baseado no Rio de Janeiro, atualmente trabalhando como Arquiteto em um projeto de e-commerce e B2C de uma grande rede de varejo sediada no Brasil, além de coordenador do RioJUG (Grupo de Usuários Java do RJ).

Apple WWDC 2006

Tuesday, August 8th, 2006

Fantástico!