CAELUM

Tive a oportunidade de palestrar juntamente com o Alexandre Magno no Falando em Java 2008. Um tema recorrente durante as discussões depois de palestras e workshops sobre Scrum é Qualidade.

Quando falamos sobre qualidade em software, surgem diversas dúvidas quanto ao que significa ter qualidade em um software: ter um código bem escrito? Testes unitários? Código que não apresente falhas? Boa performance no que se propõe a fazer? Documentação?

De acordo com a NBR 13596 (ISO/IEC 9126), existem algumas características que um software deve apresentar para ser considerado como um software de qualidade. Estas características são listadas na tabela a seguir:

Característica	Descrição
Funcionalidade	Satisfaz as necessidades?
Confiabilidade	É imune a falhas?
Usabilidade	É fácil de usar?
Eficiência	É rápido e “enxuto”?
Manutenibilidade	É fácil de modificar?
Portabilidade	É fácil de usar em outro ambiente?

A maioria das características que determinam um software com qualidade referem-se mais a boas práticas de engenharia de software ou eficiência da plataforma tecnológica. Entretanto, Scrum, como framework para gerenciamento de projetos, também é capaz de oferecer qualidade no processo de desenvolvimento.

Em Scrum, conseguimos uma melhora na qualidade através de diversos pontos. Obter esta melhora na qualidade depende muito se Scrum está sendo bem implementado ou não.

Dentre estes pontos, podemos destacar:

• Iterações
• Remoção de impedimentos
• Inspeção e adaptação
• Autonomia
• Times multifuncionais

Iterações

Qualidade em software também significa entregar para o cliente algo que lhe seja realmente útil, de acordo com suas necessidades.

Por ser uma framework ágil, Scrum trabalha com iterações, onde a cada iteração entregamos software, ou incrementos de software, potencialmente usável e de acordo com a necessidade do cliente. E, a cada nova iteração, temos “feedback” do que foi entregue e que utilizamos para melhorar o produto (sempre de acordo com a prioridade do cliente).

O “feedback” do cliente existiria de qualquer forma, seja apresentando o produto ao final de uma iteração, seja ao final de todo o ciclo de desenvolvimento (o que normalmente acarreta em alterações no código). Entretanto, se estas alterações forem feitas no final do projeto, isto também pode causar efeitos colaterais indesejados, ao passo que, fazê-las de forma antecipada, impede este tipo de problemas.

Através das Sprints, times Scrum estão sempre desenvolvendo algo que realmente tenha valor para o cliente.

Remoção de impedimentos

Remover qualquer tipo de impedimento durante a execução de um projeto é essencial não importa qual metodologia seja utilizada. Em Scrum, é esperado que estes problemas apareçam. Mas, o que é feito após resolver este impedimento, determina se um time está utilizando Scrum corretamente ou não.

Durante a execução de uma Sprint, é recomendável que a execução das tarefas seja feita item a item ao invés de cada membro executar tarefas de itens diferentes. Isso tem duas razões: a primeira é relacionada ao valor para o cliente. Para um cliente, um item somente tem valor caso tenha sido entregue completamente — algo que esteja funcionando 80% não lhe trará vantagem alguma. Além disso, executar um item completamente ajuda a manter o foco da equipe na meta e no item em específico. Desenvolvedores em geral tendem a ser mais orientados a tarefas ao invés de orientados a valor. Manter o foco na meta ajuda a aumentar a qualidade do item sendo desenvolvido.

A outra razão é em relação à forma como os problemas são resolvidos e como suas correspondentes soluções são utilizadas. A execução completa de um item representa um fluxo completo de execução e faz parte do processo utilizado no desenvolvimento. Neste caso, problemas que poderiam se tornar recorrentes podem ser solucionados imediatamente, permitindo que isso não se repita na execução dos próximos itens. Desta forma, estamos aprimorando o processo, o que também reflete na qualidade do produto.

Inspeção e adaptação

Ao final da execução de uma Sprint, há a Sprint Retrospective, uma das cerimônias de Scrum. Nela, revisamos a Sprint (inspeção) e determinamos o que foi bom e o que precisa ser melhorado (adaptação). As adaptações podem ser individuais ou coletivas, mas, de qualquer forma, elas garantem a melhora do processo e consequente otimização, o que traz diversos benefícios.

Com um processo mais enxuto e mais eficiente, podemos ter um software com mais qualidade.

Autonomia

Times em Scrum são auto-gerenciados, o que significa uma menor pressão sobre eles. Desta forma, cada um dos membros pode selecionar o que fará e terá o tempo necessário para fazê-lo com qualidade. Estudos mostram que, sob pressão de prazos exíguos, a primeira coisa a ser deixada de lado pelos desenvolvedores é a qualidade.

Além disso, através desta autonomia, os membros do time passam a ter uma melhor qualidade de vida, o que reflete em uma melhoria na qualidade como um todo. Isso porque passam a ter mais tempo e disposição para pesquisar uma melhor forma de abordar e executar uma tarefa. Em um ambiente onde Scrum tenha sido bem implantado, este aprimoramento pessoal é compartilhado com os outros membros, o que traz mais incremento na qualidade.

Times multifuncionais

Quando montamos os times, procuramos sempre montá-los com membros que tenham diferentes características ou atribuições. Por exemplo, ao invés de um time formado só por desenvolvedores ou só de analistas de requisitos, procuramos misturá-los e formar diversos times Scrum.

Isto porque a experiência de cada um é extremamente útil no planejamento das tarefas a serem executadas na Sprint. Entretanto, existe um conceito maior escondido por trás disto: qualidade desde o início.

Pude presenciar em diversas ocasiões a seguinte situação: empresas utilizando o modelo em cascata, faziam o levantamento de requisitos no início do projeto. Em seguida, arquitetos de sistema e especialistas no negócio modelavam as classes para atender a todos os requisitos levantados na etapa anterior. Depois (bem depois, por sinal), estes modelos eram passados para a equipe de desenvolvimento e o resultado era testado pela equipe de Q&A e homologação. No final do processo, isto era entregue à equipe de implantação.

Invariavelmente, o contato com o cliente era feito no início do projeto, onde este apresentava todos os requisitos possíveis e imagináveis para o produto. Embora saibamos que o cliente sabe o que precisa mas tenha somente uma vaga idéia do que quer, ele era obrigado a informar o que desejava que fosse desenvolvido, e por isso a quantidade de requisitos, algumas vezes desnecessários, era imensa.

Durante a modelagem, os analistas modelavam o que era necessário para a aplicação, muitas vezes deixando de lado alguns detalhes que poderiam facilitar o desenvolvimento ou ignorando outros detalhes que pudessem melhorar o acesso aos dados.

Os desenvolvedores, por sua vez, simplesmente executavam o que foi determinado pelos arquitetos e no prazo determinado pelo gerente de projeto.

Depois de devidamente codificado, o resultado era passado para a equipe de Q&A, que testava o que tinha sido produzido e retornava o resultado dos testes à equipe de desenvolvimento. Infelizmente, isto era feito invariavelmente aos lotes — os testadores eram obrigados a testarem diversos recursos de uma vez, muitas vezes impossibilitando testes com aspectos mais amplos.

Como tudo isso feito às pressas, em algumas situações, a equipe de implantação era informada com poucos dias de antecedência (e em uma situação, a equipe foi informada que tinha até o final da tarde para implantar um sistema). Com tão pouco prazo, muitas vezes a implantação era feita sem qualquer teste, simplesmente esperando que a sorte sorrisse para eles.

Note que os cinco parágrafos anteriores descreveram cada um dos estágios no desenvolvimento. E isto reflete como o desenvolvimento era feito — sem qualquer comunicação adicional entre cada uma das etapas que não fosse a documentação do sistema. É fácil descobrir o resultado disso.

Através de times multifuncionais, a cada Sprint temos a opinião de especialistas em diferentes áreas definindo o que será feito naquela Sprint. Enquanto não sabemos o que o cliente realmente quer como produto, sabemos o que é mais importante para ele, com estes especialistas definindo a melhor abordagem possível, levando em consideração os aspectos nos quais cada um é melhor. Assim, arquitetos podem começar definindo as classes levando em consideração a opinião de um especialista em banco de dados, de domínio, etc.

Utilizando o princípio de qualidade desde o início, o código tende a ser mais enxuto, mais adaptável, a ter mais performance. Como a interação com o usuário é constante, o produto estará sempre de acordo com a necessidade do usuário. E com a presença de um especialista em testes, cada tarefa executada já pode ser testada e eventualmente corrigida rapidamente.

E finalmente, um especialista em implantação já sabe antecipadamente o que deve testar e providenciar como ambiente de produção.

Conclusões

Existe uma beleza singular na simplicidade apresentada por Scrum. Entretanto, por trás desta simplicidade, existem conceitos que não devem ser ignorados, sob pena de obter somente parte dos benefícios de Scrum.

Um ScrumMaster deve estar sempre atento aos diversos sinais que o time apresenta, bem como motiva-los e desafia-los, sempre em busca constante do aprimoramento individual como seres humanos e o time como um todo. Além disso, buscar a melhoria contínua do processo permite que a qualidade passe a ser uma constante em futuros projetos de software.

No Falando em Java 2008, apresentei uma palestra introdutória sobre Domain-Driven Design. Apesar do tempo curto, os comentários foram ótimos! Muito obrigado a todos os que comentaram: pessoas no evento, blogs e GUJ. Falar de DDD em 40 min foi meu maior desafio e acabou faltando um pouquinho de tempo no final, mas deu para passar a mensagem.

Domain e Ubiquitous Language

O ponto fundamental do DDD é o primeiro D, o Domain. Tudo gira em torno desse tal de Domínio. O domínio é, em poucas palavras, o problema que queremos resolver com o programa que estamos desenvolvendo. Alguém (um cliente) tem um problema na área de atuação dele (geralmente nada a ver com informática) e contrata uma equipe de programação para ajudá-lo (nós :).

Segundo o DDD, é impossível resolver esse problema satisfatoriamente sem entender direito o que acontece no domínio do cliente. Não basta os desenvolvedores saberem mais ou menos: é necessário entrar fundo no domínio do cliente.

Mas é claro que nosso objetivo não é se tornar um especialista completo na área do cliente, mas apenas compreendê-la. A palavra-chave para isso acontecer é Conversa. Conversa constante e profunda entre os especialistas de domínio e os desenvolvedores.

Aqueles que conhecem o domínio em detalhes devem conversar com aqueles que conhecem programação em detalhes. Juntos, tentarão chegar a uma língua comum em que todos consigam se entender e que será usada em todas as conversas. É o que o DDD chama de Ubiquitous Language: uma língua baseada nos termos do domínio, não totalmente aprofundada neste, mas suficiente para descrever o problema satisfatoriamente.

Construção do Domain Model

Durante a conversa constante, todos juntos chegarão a um consenso sobre o Domínio. Os especialistas de domínio eventualmente criarão simplificações para facilitar a conversa; e os desenvolvedores podem introduzir conceitos técnicos simples.

Com isso, todos criam um modelo do domínio. É uma abstração do problema real, desenvolvida em conjuntos pelos especialistas do domínio e desenvolvedores. No DDD, é chamado de Domain Model.

É esse modelo que os desenvolvedores vão implementar em código. Literalmente. Item por item, como foi acordado por todos. Será desenvolvido um código limpo, com palavras do domínio, que representa, na programação, o domínio em discussão.

Usando DDD, seu programa orientado a objetos deve expressar a riqueza do domain model. Qualquer mudança no modelo (e, acredite, isso é muito comum) deve ser refletida imediatamente no código. Se algo do modelo torna-se inviável de se implementar tecnicamente, não se faz um “ajustezinho” no código; o modelo deve ser mudado para ser mais fácil de se implementar.

Ou seja, sempre seu código será expressão do modelo, que por sua vez é baseado totalmente no domínio.

Implementando o Domain Model

O DDD define uma série de patterns para facilitar a implementação do modelo em código. Mas, com absoluta certeza, esse não é o ponto principal do DDD. São apenas ferramentas que facilitam essa implementação.

Na palestra, mostrei alguns patterns de forma bem simples e rápida, como Entity e Value Object. E mostrei o tão discutido, debatido e mal-compreendido Repository.

O cliente descreve ao desenvolvedor o seguinte problema: “preciso saber todos os peixes que são da cor azul”. (na palestra, usei o exemplo de uma loja de peixes) Para o cliente, é natural em seu domínio, que se consiga “buscar” coisas. A idéia é recuperar “objetos” do domínio (entities) previamente conhecidos, baseado eventualmente em algum critério.

A noção de repositório surge justo dessa necessidade: chegar nos objetos de conhecimento do domínio. Na palestra, eu levantei a questão de que o nome repositório não deve ser algo interno ao código, mas deve fazer parte da Ubiquitous Language, deve aparecer nas conversas e no Domain Model. Ou seja, repositório deve ser um conceito que o especialista de domínio também entende e, por que está no Model, é ele que vai para o código.

Não há problema em trazer palavriado técnico para a Ubiquitous Language, desde que o príncipio da UL seja mantida: todos entendem o conceito. E, se, eventualmente, no contexto do domínio sendo tratado, outro nome faça mais sentido que repositório, esse nome deve ser usado (mesmo que nós técnicos saibamos que no fundo aquilo é um repositório).

Repositório como interface? Classe concreta delegando? DAO implementa Repository?
Tanto faz. Um outro ponto fundamental do DDD é: nada tem resposta definitiva. Se você entende a questão toda do Domain Model e aplica essa noção na programação, pode usar diversas formas diferentes de implementar tudo isso.

Na palestra, eu representei o Repository como uma interface dentro do Model. E a implementação (que, do ponto de vista do DDD, não importa) era um DAO com Hibernate na camada de infraestrutura.

Concluindo

Meu ponto principal na palestra foi mostrar a Ubiquitous Language e o Domain Model, que são o coração do DDD. Vou escrever um segundo artigo com códigos e mais comentários da palestra, mas paro esse artigo gigante por aqui.

Termino linkando para um excelente post do Philip Calçado que ele publicou essa semana (parece até que combinamos) sobre DDD falando justo que o que conta no DDD é o Domínio e não os Patterns. Ele conta uma historinha de um projeto onde todos “entendiam” DDD, usavam Repositórios, Entities etc, mas infelizmente não falavam a mesma língua do domínio.

Essa última semana tive a oportunidade de palestrar no RioJUG sobre JPA e Hibernate, onde fui muito bem recebido pelo Guilherme Chapiewski e Magno Cavalcante. Isso ocorreu durante o treinamento de Arquitetura Java que demos para diversos desenvolvedores da Globo.com, e onde tive o prazer de conhecer alguns desenvolvedores e arquitetos, como Vitor Pellegrino, Anselmo Alves, Wesley Silva, Alexandre Gazola, Tiago Motta, entre outros. Também vi o Ettore Luglio e o Daniel Passos.

Infelizmente durante a palestra não tive tempo de mostrar muitos recursos avançados e boas práticas do Hibernate, então vou usar este espaço para tal.

Precisamos conhecer todo pontencial de qualquer ferramenta, framework ou biblioteca que vamos usar em um projeto. Uma ferramenta boa, sem o devido conhecimento, resulta em projetos atrasados, com problemas de performance e desculpas do tipo “O problema é o [Hibernate|Struts|JSP, insira sua tecnologia aqui...], que gera uma quantidade excessiva de [queries|objetos|scriptlets|...] durante [lazy loading|requisições|...]“. Isso vale em especial para ferramentas mais antigas, como JSP e Struts 1. Hoje em dia ambas possuem recursos poderosos que auxiliam em muito o desenvolvimento, mas alguns desenvolvedores acabam não se aprofundando e desconhecem esses detalhes que podem ser vitais no uso de determinadas tecnologias.

Com o Hibernate não é diferente. É muito comum as pessoas culparem o Hibernate pela queda do banco de dados, performance das queries, número de objetos em memória, LazyInitializationException, e outros inúmeros problemas os quais em sua maioria poderiam ter sido evitados com a utilização de alguns recursos, boas práticas e bons hábitos no uso desse framework.

Sem mais demora, os 7 hábitos:

Connection Pool - Usar o pool de conexões embutido com o Hibernate é um erro comum, e a própria documentação diz que você não deve usa-lo em produção! Pode acontecer até connections leak!
A Caelum teve ótimas experiências com o C3P0, e é muito fácil configurá-lo como Provider para o Hibernate.

Second Level Cache - Todos já passamos por situações em que precisamos criar caches para as linhas de banco de dados mais acessadas. Aqui temos diversos problemas: sincronismo, gasto de memória, memory leak, tamanho do cache, política de prioridade da fila (LFU, LRU, FIFO, etc), tempo de expiração e modos de invalidar o cache. Escrever um cache eficiente e seguro é um grande trabalho, imagine ainda dar suporte a um cache distribuído e que possa se aproveitar do disco rígido para não gastar tanta memória? Esse é o papel do second level cache. Você pode usá-lo com diversos providers, sendo o EhCache um dos mais conhecidos.

Query Cache - Um recurso fantástico do Hibernate. No caso de você ter queries que são executadas inúmeras vezes, você pode pedir para o Hibernate fazer o cache do resultado desta query. O interessante é que ele não vai armazenar todos os objetos resultantes, e sim apenas suas primary keys: no momento que ele precisar executar novamente aquela query, ele já tem todos os IDs resultantes, e através destes ele consulta o second level cache, sem fazer um único hit ao banco de dados! Esse cache será invalidado quando alguma das tabelas envolvidas nesta query for atualizada, ou um determinado tempo passar.

Controle do Lazy - Algumas pessoas costumam reclamar do lazy loading, dizendo que em alguns casos teria sido melhor ele carregar tudo em uma única query. Você sempre pode redefinir o comportamento desses relacionamentos quando fizer uma query, através de um eager fetch.

Stateless Session - Algumas vezes precisamos fazer um processamento em batch de objetos, ou mesmo inserir uma quantidade grande deles na base de dados. Em muitos casos uma bulk operation é o suficiente, mas se quisermos manter a Orientação a Objetos, devemos tomar cuidado com a grande quantidade de objetos que ficarão armazenados no first level cache. A StatelessSession resolve esse problema: simplesmente não há first level cache e nenhum objeto se comportará como managed, tendo praticamente o mesmo efeito que chamar entityManager.clear() a cada operação.

Open Session in View - Na arquitetura MVC, muitas vezes renderizamos em nossa view diversas entidades do nosso modelo, e essas podem ter sido carregas pelo Hibernate. Se essas entidades possues relacionamentos lazy, precisamos que a sessão esteja aberta no momento da renderização da View, caso contrário teremos uma LazyInitializaionException ou algum código macarrônico para carregar relacionamentos que nem sempre precisamos. Para isso devemos manter a session aberta através de um filtro, interceptador ou algum outro mecanismo. Isso resulta no pattern Open Session in View e também se aplica ao EntityManager.
O mesmo efeito pode ser obtido através de inversão de controle e injeção de dependências através da anotação @PersistenceContext, que é tratada por containers EJB3 e também por muitos frameworks web, como o Spring. O EJB3 ainda possui o conceito de um contexto de persistência extendido, quem é interessante em casos de conversações longas: o EntityManager usado será o mesmo enquanto aquele stateful session bean não for removido.

Evitando número de queries excessivas (n+1) - Se uma NotaFiscal possui muitos Items, e essa coleção é lazy, gastaremos duas queries para buscar a NotaFiscal e seus respectivos Itens. Mas se temos uma lista de NotaFiscal resultante de uma query, para cada NotaFiscal teremos uma nova query executada para todo getItems invocados. 1 query para listar NotaFiscal, N queries para pegar os relacionamentos: é o problema das n+1 queries. Você deve usar as configurações de batch-size e fetch-size para pedir ao Hibernate carregar as entidades/relacionamentos em blocos em vez de um em um. Você também pode utilizar o second level cache nesses relacionamentos, diminuindo consideravelmente o número de queries disparada.

Essas são apenas alguns dos hábitos, poderíamos ainda falar sobre o bom tratamento de exceções, o cuidado ao fechar todos os recursos abertos pelo Hibernate, o uso de queries nativas, o mapeamento de queries nativas para entidades através do ResultTransformer, filtros de coleções, dynamic insert e update, a criação do seu próprio tipo de persistência, e muitos outros. Conhecer bem o capítulo de performance do Hibernate é fundamental além de um bom começo.

Aconteceu no último final de semana o Conexão Java 2007, evento organizado pelo GUJ, PortalJava e Tempo Real Eventos. A Caelum esteve lá com stand, palestras e tutoriais.

Muito bom rever os amigos do GUJ, do PortalJava e ex-alunos da Caelum. As palestras foram ótimas e ainda tivemos os tutoriais. Paralelamente, o Philip comandava a muvuca com discussões acaloradas sobre arquitetura.

Lá no GUJ há um tópico onde o pessoal está colocando impressões sobre o evento e palestras (as nossas estão logo após as fotos).

Algumas fotos dos mini-cursos, do auditório e da muvuca lá fora:

Este ano, a Caelum ministrou 3 tutoriais e uma palestra no evento. Você pode baixar o material de cada um logo abaixo:

• Tutorial Hibernate 3.2 com Nico Steppat
• Tutorial de JSF e AJAX com Sérgio Lopes (sexta) e Fabio Kung (sábado)
• Tutorial Java ME com Sérgio Lopes
• Palestra Java ME com Thadeu Russo