Para quem não conhece, a InfoQ estará abrindo as portas aqui no Brasil e temos um evento de lançamento no dia 01/11 (sábado) com a presença de muitas pessoas das comunidades Agile, C#, Rails e etc… Estarei presente participando de mais um painel sobre Métodos Ágeis (Mais uma vez… tá vendo? Quem mandou não estudar mais sobre arquitetura?)
Link para as incrições: http://www.fratech.net/infoq
Tive uma dúvida nos últimos tempos.
Fiquei bem surpreso como nos dois últimos eventos de Java falamos muito sobre Ruby e Rails (TDC e JustJava). Digo isso não nas palestras, mas sim nos bate-papos. Eu confesso! Nos últimos eventos gostei mais das conversas nos intervalos do que das palestras.
A minha dúvida era: “Se num evento de Java se fala muito sobre Ruby, o que se fala num evento de Ruby?”. Para minha surpresa, o que se fala muito num evento de Ruby é BUSINESS. Isso mesmo! O Rails Summit da Locaweb teve muito bate papo sobre negócios e como ganhar dinheiro com software. O que mais me chamou a atenção foi uma “certa aversão” ao termo Agile nas conversas dentro e fora das palestras. O Guilherme Chapiewski ficou meio revoltado quando eu disse que logo vão exigir “Scrum Masters Certificados” nas licitações (sim… eu ouví esse papo nas minhas andanças no Planalto Central). O Shoes foi categórico: “Não falo sobre Agile”. Já com o Vinicius Teles, batemos muito papo sobre negócios, produtos, não trocamos uma palavra sequer sobre Agile. Também estavam presentes muitos outros agilistas, railers, gujeiros, alunos da Aspercom e etc…
O Ivan Sanchez foi o cara que fez o treinamento CSM junto comigo no início de 2007, e teve o azar de cair no mesmo grupo comigo! O Ivan é um agilista e grande evangelista de Coding Dojos. Atualmente trabalha na Signature Technologies no Reino Unido.
James Shore (Jim) é lider do projeto FIT (criado por Ward Cunningham), atua em projetos ágeis desde 1999 (sim, existem projetos ágeis antes do Manifesto Ágil) e escreveu o livro “The Art of Agile Development“.
Uma das coisas legais de escrever na MundoJava é ter contato com esses caras lá de fora e poder trazer estes conteúdos para nossa comunidade. Escrever com o Scott Ambler e o Jon Kern foi muito legal. Este artigo com o James Shore também foi especial. Infelizmente eu recebo mais não do que sim, mas ainda vou continuar insistindo com os mestres! Ah… vocês querem o trecho grátis do artigo, certo? Então aí vai:
Uma das questões comuns é: Quem escreve os dados de teste? Pela estratégia do FIT, os dados de teste são escritos a “oito mãos”. É comum que tudo inicie com o usuário ou cliente e com o analista de negócios, capturando cenários de teste iniciais que formatam alguns critérios de aceitação. Depois disso, um desenvolvedor pode verificar a formatação das tabelas, referenciar as Fixtures e assim obter o RED do ciclo TDD. Ao mesmo tempo os testers podem participar colocando mais cenários. Logicamente, o FIT é uma ferramenta ágil. É importante uma rica colaboração face a face de todos os envolvidos para que exista sucesso na adoção dessa abordagem.
Uma atenção especial deve ser dada ao trabalho do analista de negócios. Atualmente é comum que esses profissionais capturem requisitos em documentos texto e alguns diagramas. Geralmente este tipo de abordagem é muito pobre para o desenvolvedor, principalmente se não existe uma comunicação rica entre eles. Comunicação com documentos é uma forma muito pobre de comunicação (veja artigo “Modelagem Ágil”, MJ 27). Um modelo de requisitos em texto é muito deficiente na maioria das vezes. Pare para pensar: Não existe teste sobre documentos em texto e nem compilador para diagramas!
Rodrigo Yoshima
O que é o FIT e porque se importar com ele? O FIT é parte do seu arsenal ágil de prevenção de bugs. Diferente da abordagem tradicional para a qualidade, onde focamos em encontrar e remover defeitos, as práticas ágeis focam-se primeiramente em previnir que bugs sejam criados. Isso nos leva a alguns resultados impressionantes. Times ágeis experientes produzem poucos bugs por mês.
As “práticas ágeis de engenharia” pregadas pelo Extreme Programming (XP) são parte da solução. Essas técnicas como Test-Driven Development (TDD), programação aos pares, propriedade coletiva do código, design simples e trabalho energizado previne a maioria dos erros de programação. Elas garantem que o código faz exatamente o que os programadores pretendiam que ele fizesse.
James Shore
FIT ou Framework for Integration Testing é uma ferramenta excepcional no auxílio ao desenvolvimento de um software. O cliente (ou analista de negócio) escreve tabelas mostrando o que o sistema deve fazer através de exemplos. O desenvolvedor escreve o código das fixtures, que são as classes que ligam as tabelas com o sistema que está sendo implementado. A partir daí as tabelas se tornam “executáveis” e as regras definidas podem ser validadas de maneira automatizada.
FitNesse é a implementação mais popular de FIT, que funciona na forma de um wiki. Cada página representa um teste executável e é possível executar múltiplas páginas para validar um sistema como um todo. Além disso, por se tratar de um wiki, favorece a colaboração entre cliente e desenvolvedores, podendo servir como uma ótima base de conhecimento sobre o sistema que está sendo construído.
Ivan Sanchez
O FIT é uma ferramenta muito interessante: Uma coisa que chama a atenção em projetos onde utilizamos o FIT é que produzir as tabelas com os dados de teste é uma atividade de modelagem intensa. Modelar não é fazer diagramas, é muito mais profundo do que isso!
Já nas bancas!
Julho é um mês agitado aqui na Aspercom. Todo o pessoal está de férias e muitos querem se manter atualizados nas novidades do mercado e etc… Ministramos treinamentos para aproximadamente 100 pessoas neste mês.
Sala de Treinamento da Aspercom
Computadores DELL Core 2 Duo e monitores LCD de 21″
Uma das grandes “novidades” é que dessa vez mais pessoas levantaram a mão quando perguntei se elas estão aplicando desenvolvimento iterativo. De acordo com a pesquisa rápida, creio que 60% dos alunos disseram estar aplicando desenvolvimento iterativo. 40% ainda era cascateiro. Bem, creio que isso é uma grande vitória, pois é muito comum 100% da turma ser cascateira. Será que as empresas estão caindo na real?
Eu acho que a comunidade Agile está fazendo um bom trabalho. Estamos dando o recado de maneira muito clara. Tem várias outras boas novidades de empresas grandes e pequenas buscando melhorar seus processos. Logicamente também aparece um ou outro louco afundando a adoção de Agile em algum lugar.
Foi muito legal neste mês de julho conversar com muitas pessoas de muitas comunidades diferentes. Uma das motivações de ter escrito o “Rigidez Conceitual Burra em Java” é o dinamismo da comunidade PHP. Realmente vejo eles buscando sistemas mais organizados através de frameworks bastante influenciados pelo Rails. Por conta de um sitezinho que precisei fazer, estudei o CakePHP. Infelizmente o site era bem simples e não deu para aprofundar muito, mas é fato que o sistema fica mais claro, mais fácil de manter e com uma melhor separação de responsabilidades. Logicamente a sintaxe do PHP é o que não ajuda!
O fato de ter escolhido PHP é que o provedor do cliente não tinha Rails “inicialmente”. Problema de comunicação! Quando fui colocar a primeira iteração no ar para testes, ví a seguinte tela:
Por melhor que seja o PHP, me desculpem! Rails é Rails! O provedor do cliente atendia Rails sim! Como estava ainda na primeira iteração logicamente que valia a pena migrar para Rails. Deus abençoe a Phusion. Uma das razões que me faz apostar no Rails é o Passenger (mod_rails). Logo logo o mod_rails se tornará padrão em qualquer provedor. Pra falar a verdade, creio que a popularização do mod_rails marcará o início da queda do PHP.
No treinamento Scrum do dia 19 de julho, conhecí o André e o Antônio Carlos (pessoal da Stefanini) que estão num grande projeto Web para a Fnac. O que chamou a atenção é que este projeto é Scrum + DDD + .NET + Escopo Negociável. Sendo sincero com vocês, é raro pessoas que trabalham com .NET aplicar DDD corretamente como este pessoal. Infelizmente, é comum o DsPLPC (Data Set pra lá e pra cá). Vamos ver se isso muda com o Entity Framework (isso se a M$ não fizer nenhuma besteira). Mas fiquei contente que o Antônio Carlos relatou como nosso treinamento auxiliou na adoção do Scrum com o Team System. Realmente estamos torcendo por vocês.
Muitas outras histórias e relatos tive nessas turmas. Realmente foi muito enriquecedor! Gostaria agradecer a todos os alunos pelas conversas nos coffe-breaks e pela excelente avaliação feita dos treinamentos.
Creio que na minha caixa de email deve ter pelo menos umas 300 mensagens de leitores da MundoJava e de participantes da UML-BR pedindo informações sobre a certificação UML. Como repito as mesmas coisas a cada mail que respondo creio que passar este post em link vai me ajudar um pouco a dar uma resposta melhor. 
Valor de Mercado
Na minha opinião é até meio sem sentido. A certificação OCUP da OMG é uma certificação originalmente direcionada a Tool Vendors (os caras que criam ferramentas UML), mas o mercado é meio viciado em certificação, principalmente as certificações “raras”, então, a certificação UML da OMG é bem valorizada. Creio que fui um dos primeiros a obtê-la aqui no Brasil.
Existem 3 níveis de certificação UML: Fundamental, Intermediate e Advanced. A Fundamental representa os famosos 20% da UML que é utilizada em 90% dos projetos [Jacobson] e creio que seja o nível que todos os profissionais aqui do Brasil possuem. Não vejo muita utilidade e nem tanto valor de mercado em investir mais do que a Fundamental.
Como é a prova OM0-100 (Fundamental)?
São 84 questões onde somente 80 valem para a avaliação. As 4 questões que não valem pontos são logo no início da prova e simplemente é uma pesquisa (não perca muito tempo com elas). Todas as questões são múltipla escolha, porém, tem aquelas famosas questões onde você deve assinalar mais de uma como correta. Exemplo: What applies to a Package? (mark 2).
A prova é bem conceitual. Ela valida bem o conhecimento da UML e as perguntas são baseadas na UML Superstructure Specification, v2.0 (05-07-04). A prova não é baseada na versão mais atual da UML2.
O que cai na prova Fundamental são conceitos básicos, diagrama de classes, diagrama de atividades, diagrama de sequências e diagrama de casos de uso. Se quiser fazer a prova, preste muita atenção no seu plano de estudos porque para o nível Fundamental não é tudo que cai na prova sobre cada diagrama. Como exemplo, sobre diagrama de atividades, Forks e Joins é um assunto que não cai na prova do nível Fundamental. No site de certificação existe um PDF que diz exatamente o que cai em cada nível baseado na Superstructure. Preste atenção exatamente no que cai para não estudar mais que o necessário.
A maior dificuldade da prova é o tempo. Minha recomendação é que se você sabe um pouco sobre UML não tente fazer a prova na caruda achando que UML é fácil. A prova é baseada na especificação da UML e não simplesmente diagramas onde você vai responder “Qual elemento é o ator?” ou “O que aquela linha com seta vazada significa?”. Vou dar o meu relato: já trabalho com “UML” deste o método Booch e a OMT (alguém se lembra do CoolJex?) mesmo assim não sobrou tempo. São 80 questões para responder em 90 minutos e algumas questões sobre diagrama de sequências e casos de uso você realmente precisa parar para pensar! Uma outra recomendação é que se você tem um inglês fraco pense duas vezes antes de fazer a prova. A prova é conceitual e o inglês é formal e técnico. O tempo é o maior desafio nessa prova.
Sugestão de estudo
Um ponto interessante é que literaturas tradicionais de UML (Ambler, Fowler, “Três Amigos”, Larman) vão te ajudar muito pouco. São ótimos livros, mas não para a certificação. Uma literatura que não existia na época que me certifiquei é o UML 2 Certification Guide: Fundamental & Intermediate Exams. Não posso comentar sobre este livro pois não lí. O livro que estudei para a certificação é o UML Bible do Tom Pender. É uma literatura bem completa que uso como referência muitas vezes. Aborda questões da Superstructure, tem exemplos e fala também da UML 1.X.
Se quiser estudar pelo Tom Pender meu guia de estudo é esse:
Conceitos Gerais: Capítulo 1 a 4
Diagrama de Classe: Capítulo 5 e 6 e Diagrama de Objetos do Capítulo 7.
Diagrama de Interação: Capítulo 9 (até Interaction Occurence)
Diagrama de Use-Case: Capítulo 12
Diagrama de Atividade: Capítulo 13
Independente da literatura que você escolher, a idéia é olhar o programa da prova citado, estudar primeiramente por algum livro e logo após estudar pela própria UML Superstructure Specification, v2.0 (05-07-04). O estudo pela Superstructe é obrigatório. Mas a Superstructure é um texto bem chato de ler.
O estudo pela Superstructure é importante por duas razões. A prova é baseada nesse texto e algumas perguntas como “What is a Namespace?” não constam em literatura nenhuma. Só está na especificação. Em segundo lugar algumas questões da prova apresentam diagramas que constam na especificação. Saber os diagramas exemplo que estão na Superstructure pode ser a chave para ir bem na prova.
O curso UML da Aspercom
Nosso curso UML 2.0 & Unified Process não é focado em certificação, mas fornece uma boa base para a prova se você não quiser estudar sozinho pela literatura indicada. Nosso curso é mais focado em demonstrar 3 bases importantes para análise e design de projetos orientado a objeto: Requisitos com Casos de Uso, Modelagem e Arquitetura. Um dos nossos alunos, o Daniel Guttermeyer (Iconophobia), relatou na lista UML-BR que obteve a certificação fazendo nosso curso e estudando pela Superstructure.
A Aspercom não é uma empresa muito fã de certificações, apesar de não ser 100% contra. Somos fãs de conhecimento. Isso pode ser constatado na nossa Visão e Missão.
Simulados
Buscando por “UML” no http://exams.googletoad.com/ achei dois simulados da OM0-100 (Fundamental): O da Pass4sure e o da ActualTests. Dei uma olhada bem por cima e creio que esses simulados podem ser uma referência sobre as questões que caem na prova. Não se assuste. Como disse a prova não é ver um diagrama e mostrar qual elemento é uma classe!
Mais informações:
O preço de cada prova de certificação é US$ 200. O centro de certificação é a PearsonVue. Para mais informações visitem os links abaixo:
http://www.omg.org/uml-certification/
http://www.pearsonvue.com/omg
http://exams.googletoad.com/?examsQ=uml
Vou listar aqui algumas coisas da nossa comunidade que me irritam profundamente:
1. Engolimos a J2EE
Todos nós fizemos BMPs, Service Locators, DTOs desnecessários. Empilhamos várias classes para ter um Session Bean. Implementamos várias javax.ejb.EJBObject, lançamos várias RemoteExceptions. Nós realmente pensamos que nossas aplicações teriam trilhares de usuários.
Não só isso. Nós olhamos para o Spring no início e não achávamos que isso iria dar em alguma coisa. Não demos crédito para o Hibernate no momento certo. Os POJOS poderiam ter tomado a cena muito antes. Nós demoramos para compreender que a Sun não era detentora da sabedoria suprema. Até na comunidade .Net essa ficha caiu mais rápido.
2. Nós pervertemos os POJOS
Livres do modismo J2EE e EJB 2.1 pra baixo, estávamos livres para melhorar nossos modelos, aplicar nossa teoria OO, parar de fingir que distribuimos objetos e ter uma visão mais enxuja. Infelizmente muitos de nós caíram na cilada do modelo anêmico. Ainda com sangue “Core J2EE Patterns” na veia, implementamos factories, DAOs e por influência de Struts 1, DTOs (com nome de VOs) emergiram como rãs nas pragas do Egito.
Fizemos o Martin Fowler perder seu precioso tempo escrevendo sobre Anemic Domain Model.
Pojos não são DTOs, pelo amor de Deus!
3. Nós cultuamos os XMLs
struts-config.xml, web.xml, hibernate.cfg.xml, persistence.xml, context.xml, ejb-jar.xml…
Sim, desenvolvedores foram para a plataforma .Net por nossa exclusiva culpa.
4. Torcemos o nariz para novidades
Quem não reclamou de Generics? Quem não reclamou de Annotations? Que atire a primeira pedra! Somos eternos insatisfeitos só para não sair da zona de conforto. Há quem diga que não gosta de tipagem dinâmica, Jboss Seam, Groovy, JDK com várias linguagens, scripting. Sim, ainda tem muita gente usando Struts 1, implementando DAOs na mão (afinal, hibernate é complicado….), implementando milhares de Factories, controlando transações na mão e estacionados na JDK 1.4.
5. Rigidez conceitual burra
Sinto muito, mas aqui eu não vou usar “nós”. Vocês são os primeiros a sacar os padrões. Vocês ainda estão discutindo framework MVC web. Vocês empilham classes, se enchem de interfaces. Vocês preferem fazer algo complicado por medo das críticas. Não estou suportando mais as discussões sobre DDD, repository, JPA e Hibernate. Por favor compreendam o que o Evans quis dizer com “Don’t Fight your Framework”. Não aguento mais ver trocentas camadas e DTOs. Não apliquem otimização prematura. Sejam pragmáticos. Respirem YAGNI. Abusem das Spike Solutions. Façam a coisa mais simples possível que funcione.
Enquanto vocês estão discutindo os padrões, todas as outras comunidades estão correndo por fora. Desculpem o desabafo. Teve um determinado momento onde gostava dessa rigorosidade da comunidade Java, porém, hoje vocês estão me fazendo flertar com a comunidade PHP.
Bem, nem só de Scrum vive esse blog! O propósito deste post é falar um pouco da nova arquitetura que adotamos para o projeto Hotmotors. Desde que publiquei aqui no Débito Técnico o artigo “UML não é documentação”, onde disse que a arquitetura (Struts 1 + Hibernate) de 2006 não me dava muito orgulho, várias pessoas entraram em contato para ajudar no desenvolvimento de uma nova arquitetura Seam. O Rafael Benevides foi o cara que topou a parada e começamos o trabalho.
Pra falar a verdade fiquei até surpreso como a conversão de uma arquitetura para outra foi rápida. O Rafael me entregou a primeira iteração em 2 dias (OK, talvez ele seja um code hose). O trabalho dele foi portar o Hibernate para JPA, passar todos os JSP para xhtml e retirar o Struts de cena implantando o JSF/Seam. Segundo o próprio Rafael, o fato de termos um bom design ajudou bastante, principalmente o fato de nosso Domain Model estar bem fundamentado.
Por que o Seam Framework?
Eu já trabalho com sistemas baseados em web a bastante tempo. A evolução que esse tipo de sistema foi desde escrever vários servlets na mão que cuspiam html, seguido a inclusão de JSPs, as infinitas Tag Libraries, a introdução de composite-views (como o Tiles), o Struts e a segunda geração de frameworks (WebWork, Spring MVC, VRaptor, Mentawai, só para citar alguns). Correndo meio que por fora disso temos o JSF. O JSF é controverso. A idéia do JSF era ter em Java a mesma idéia que existe no Web Forms do ASP.Net. Um event-based framework que melhorasse a produtividade na construção da view (junto com muitas outras coisas mais). Por que ele é controverso? Bem, primeiramente o JSF é um tipo de tecnologia que visava uma dependência de ferramenta (como uma boa IDE). Muitas outras coisas foram discutidas numa longa, mas muito longa thread do GUJ (note que ela iniciou em 2005).
http://www.guj.com.br/posts/list/29623.java
Um outro fato é que JSF-based tem várias implementações alternativas (ADF Faces, RichFaces, MyFaces só pra citar alguns). Se você usar a reference implementation da Sun você não terá coisas muito interessantes e ainda sofrerá de “configuration hell” com XML, mas usando essas alternativas você ganha uma view limpa e uma grande facilidade em fazer RIAs com Ajax.
O SeamFramework inicialmente era bem baseado no RichFaces, porém, atualmente na versão 2.x, ele é mais independente do framework web que você escolheu. De qualquer forma, o Seam é uma excelente alternativa para integrar sua camada view em JSF à sua camada de aplicação, oferecendo uma consistente implementação para ligar tudo isso. Como falei, eu já passei em vários frameworks web, principalmente os Action based. Usando o Seam, basicamente os benefícios que ví foram:
1. Convention Over Configuration (não é necessário configurar nada em XML - tenho nojo de XML)
2. Component-based e não Action-based (de fato, não há uma boa definição sobre essa diferença)
3. Boa integração entre JSF e EJB3.
4. Conversation Model (não ví nenhum framework web resolver isso da maneira que o Seam faz)
5. Menos Javascript para coisas banais
6. Injeção de Dependências via anotações
7. Integração com outras coisas como o JBpm.
Muitas outras razões você pode ver no site www.seamframework.org. O SeamFramework foi uma das razões para eu voltar a gostar de fazer aplicações web em Java. Faz mais ou menos 2 anos que estou utilizando o Seam, algumas coisas já estão no ar e realmente são aplicações confiáveis.
Algumas coisas que me incomodam… e outras que resolví.
Aos 4 ventos eu promovo o Seam como uma boa arquitetura de caixinha em JEE. Mas nem tudo é um mar de rosas. O Seam é um monstro. É um framework muito grande e precisa de uma infraestrutura no lugar para que ele possa rodar. Desde que iniciei com o framework tive dificuldades em fazer DI fora de um ambiente JEE. Isto é um problema quando você quer tomar uma estratégia TDD de verdade. Como exemplo, para fazer um SeamTest rodar você precisa ter um Embeddable Jboss. Isto é, você precisa de um JNDI, um EntityManager Factory e toda parafernália JEE no ar. Numa máquina mediana isso pode tomar de 20-50 segundos para subir. É irritante aplicar TDD com o Jboss Seam. Para falar a verdade, só para subir um EntityManager JPA com umas 100 entidades já toma aproximadamente 15 segundos. Isso é uma coisa para o pessoal do Hibernate pensar a respeito.
Esse “peso” para usar o Seam num ambiente “plain JSE” é uma das coisas que tinha me decepcionado muito no framework, isso foi bom pois me empurrou para estudar Rails/Ruby mais a fundo. Uma das coisas que encanta no Rails é a leveza. Tudo é leve! Desenvolver é leve, subir um WEBrick para desenvolvimento não toma mais que 2 segundos (é isso mesmo, 2 segundos). Você pode fazer o que quiser e não precisará reiniciar o servidor quase nunca. No PHP também é assim. Até no ASP é assim. Isso é chamado de development turnaround time. O turnaround do Ruby, PHP e outros citados é baixo. O Java causa uma cegueira técnica nesse sentido: qualquer coisinha que você mexa na implementação o Java chia que você tem que reiniciar o servidor para “pegar” as novas classes, anotações ou configuração que você fez. Nós nos acostumamos a perder tempo com isso e não reclamamos! Muito se discute, mas pouco se faz na prática.
Como o berço do Seam é a Jboss, não ví uma iniciativa por parte deles para melhorar isso (eles tem uma tendência a usar todos os outros produtos Jboss). Nesse ponto, usar o Jetty é algo que evolue pouco nas discussões da comunidade Seam e não consta em documentação. O Jetty é uma implementação leve de um servlet container que é muito usado para desenvolvimento (e também para produção). Olhando para o Seam, desde o início ví que teria uma maneira de usar o Jetty, mas não tive tempo de implementar isso. Vasculhei até achar um blog que dizia como fazer o Seam rodar no Jetty. Foi uma vitória, e além disso, este post ainda tinha esse projeto Seam Mavenizado (não sei se outras pessoas usam essa palavra).
A única pedra agora é que este projeto estava integrado com o Spring. Nada contra o Spring (fora o fato dele sofrer de configuration hell com XML, já falei que tenho nojo disso?), mas o ponto é que nossa aplicação Hotmotors seria simplesmente Seam. Bem, inicialmente coloquei o Maven para rodar dentro do Eclipse e depois, tratei de ver documentação e desplugar o Spring dessa implementação (e contornar alguns probleminhas do Jetty no Windows, meu MacBook Pro só vai chegar no final de agosto pra piorar minha vida miserável de programador).
Depois de tudo isso eu pude dormir mais contente: tenho uma referência do Seam Mavenizado e rodando no Jetty. Isso já melhorou muito o turnaround time em desenvolvimento. Creio que isso deixará mais alguns outros programadores felizes. Finalmente revivemos o Hotmotors! As próximas iterações vêm aí e nosso próximo passo é integrar as ferramentas de teste automatizado (provavelmente Fit e Selenium) e ver alternativas para o TDD. Aguardem!
Para baixar esse release, acesse a página do HotMotors.
O Seam é comparável com o Rails em produtividade? A comunidade Seam se posiciona como concorrente do Rails. Essa resposta eu não tenho ainda, mas minha idéia é reimplementar tudo em Rails para tirar essa dúvida.
Queria agradecer muito pela colaboração do Rafael para a comunidade. Valeu!
Obs. Veja mais informações de como rodar este release no blog do Rafael.
Surgiu uma discussão na UML-BR sobre como modelar um Jogo da Memória. O rumo da conversa foi sobre pensar nas classes e modelar antes, influenciados por um post anterior. A thread sobre o jogo da memória está aqui:
http://br.groups.yahoo.com/group/UML-BR/message/9936
Eu comecei a pensar nesse problema e até pretendí mandar um diagrama de classe demonstrando uma provável solução, porém, este “mini” sistema é muito mais direcionado a comportamento do que a classes propriamente dito.
Atualmente tenho estudado bastante Ruby. Concordo com o Rodrigo Kumpera quando ele diz que Java “educou a grande massa sobre bom desenvolvimento OO” mas “cheira naftalina”. A linguagem continua em evolução, porém, algumas coisas no Java me irritam muito. A maior delas é o turnaround imenso. Volta e meia precisamos reiniciar o servidor. No Ruby as coisas são mais fáceis. A comunidade Ruby faz as coisas serem mais fáceis. Para resolver o problema do Jogo da Memória quis usar o RSpec. Para instalá-lo bastou:
gem install rspec
No Java já me imaginaria instalando uns 20 jars irritantes.
Voltando ao assunto “Jogo da Memoria” iniciei esse desenvolvimento pensando: “O que é necessário para jogar?” Por sorte sou pai de 2 filhas pequenas e tinha um Jogo do Mico aqui. Não é exatamente um Jogo da Memória mas serve pois são cartas aos pares. Com as cartas na mão me lembrei do nosso amigo Kent Beck e a “Spike Solution”: “Eu não preciso de 15 pares para testar o Jogo da Memória. Eu só preciso de 2 pares para ter uma solução plausível que diz que minha aplicação funciona.”
Uma mesa, um jogador e dois pares de cartas: Tudo que é necessário para um Jogo da Memória completo.
Com essa metáfora e esses “elementos” na mão o próximo passo seria como montar a “partida” focado em comportamento. Pensei no meu próprio comportamento quando montei esse cenário para a foto.
Este seria o comportamento esperado do jogo logo ao iniciar. Pense no objetivo do jogo. Nós queremos ganhar certo? Logo no ínicio nós precisamos ter um parâmetro palpável para saber se ganhamos ou não. Logicamente no ínicio do jogo ele não está ganho. A implementação desses comportamentos nesse momento está listada abaixo:
A prática do BDD é extremamente próxima do TDD. BDD não é nada novo. É apenas uma visão unificada de TDD e DDD fornecendo uma Ubiquitous Language para essa abordagem de desenvolvimento.
OK. Neste momento temos um Jogo montado. Um aspecto importante para este jogo é saber comparar cartas. Vamos adicionar este requisito como comportamento.
Vamos agora implementar isso na classe Carta.
Cada vez que faço um passo desses eu tenho requisitos (comportamentos) e implementações em paralelo. Minha especificação (jogo_memoria_spec.rb) vai direcionando o desenvolvimento da minha aplicação (jogo_memoria.rb). Cada passo é mensurável e pode ser avaliado como válido. Além disso, minha aplicação possui as características de um design emergente. Dados e comportamentos só são adicionados quando realmente há embasamento em requisitos.
Com a capacidade de saber quando cartas são iguais, o próximo passo seria poder “virar” uma carta e em seguida virar outra carta que não seja par com a primeira. É um critério de falha com relação ao objetivo de ganhar o jogo. O comportamento e a implementação do comportamento estão abaixo:
Vamos agora definir o comportamento e a implementação para o sucesso de virar duas cartas encontrando o par:
Com esses últimos comportamentos seria possível avaliarmos a nossa implementação do Jogo da Memória com 4 cartas. Para efetuar o download da aplicação completa acesse os links abaixo:
jogo_memoria_spec.rb
jogo_memoria.rb
O que eu tenho gostado muito em aplicar técnicas de TDD é ter requisitos executáveis. O BDD só nos traz mais ferramentas conceituais. O BDD tem foco no próprio comportamento e não em testes dos comportamentos. A evolução de ferramentas como o próprio RSpec poderá nos trazer a um mundo novo onde nunca mais teremos documentos de requisitos desatualizados.
Cada dia que passa a especialização e a divisão do trabalho fazem menos sentido no desenvolvimento de software.
(amigos rubistas: não sejam muito rigorosos com meu código, estou aprendendo ainda)
Na edição 19 da Revista MundoJava em meados de 2006 iniciei a publicação dos meus trabalhos na coluna MundoOO. Este primeiro artigo publicado teve um impacto extremamente positivo e até hoje muitas pessoas comentam sobre esta publicação.
Eu já ministrava treinamentos UML há algum tempo e participava de muitos fóruns de discussão como o UML-BR e o GUJ. O mercado tem um entendimento muito ruim sobre UML e modelagem em geral, assim, o que eu já pregava nos cursos transformei em literatura.
O artigo “UML não é Documentação” demostra o uso da UML de maneira prática e concisa, bem próximo da visão de modelagem ágil de autores como Scott Ambler e Martin Fowler.
Numa iniciativa conjunta do Blog Débito Técnico e o pessoal da MundoJava, estamos deixando este artigo disponível para download no site da Aspercom na página do projeto HotMotors. Este projeto com fins acadêmicos que anda parado (e com uma arquitetura que apesar de popular em 2006 não me dá muito orgulho) ainda será reativado um dia. Minha idéia é portar isso para Seam e também Rails. Seria um ótimo comparativo! Alguém da comunidade se habilita?
Atualmente surgiram algumas discussões em fóruns sobre a entrada de itens técnicos no Product Backlog do Scrum. A apostila do nosso curso Scrum pode dar uma idéia sobre o que é um Product Backlog:
“Os itens que aparecem no Product Backlog são qualquer tipo de funcionalidade ou tarefa que possua um valor para o Product Owner ou ao grupo de Stakeholders que este Product Owner representa. Esses itens seguem um conceito do SCRUM chamado incremento de funcionalidade potencialmente implantável. Uma funcionalidade potencialmente implantável significa que quando esse item do Product Backlog for finalizado ele estará completamente funcional e resolvendo algum problema de negócio dos Stakeholders.”
Rodrigo Yoshima, Gerenciamento de Projetos com Scrum
As discussões estão listadas abaixo:
http://br.groups.yahoo.com/group/agile-brasil/message/1738
http://br.groups.yahoo.com/group/scrum-brasil/message/751
Eu particularmente sou contra enfiar coisas que não agregam valor para o PO no Product Backlog. Bem, pra falar a verdade, defendo uma outra visão. Pode ser que existam itens criados por recomendação da equipe, mas tudo lá agrega valor de negócio para o PO. Lembre-se: O Product Backlog é um importante registro de métricas como prazos, produtividade, pesos funcionais e etc… É preferível que essas métricas importantes para o negócio não sejam poluídas com problemas técnicos da equipe (apesar desses problemas interferir nas métricas, são ortogonais à visão que defendo aqui). Gerar um script do Ant não é algo que constaria nos meus product backlogs.
Débito Técnico é um problema da equipe técnica. Se existem Débitos Técnicos é culpa (responsabilidade) da equipe técnica. Agora, nenhuma aplicação que desenvolví ou qualquer outra que tive contato É 100% LIVRE DE DÉBITO TÉCNICO. Já olhei código de algumas dezenas de projetos Open Source. Todos tinham algum débito, porém, isso é natural. Como vocês todos sabem, débito técnico é comparado com inflação. Tem que ser gerenciado. Nenhum economista consegue gerenciar algo como os 100.000% de inflação do Zimbabue.
É capaz que existam itens do tipo:
- Efetuar um teste de usabilidade com os usuários finais
- Efetuar um teste de carga com 480 usuários simultâneos
Já passei por essas duas situações. Mas esses itens foram para afastar riscos do negócio e não “Débito Técnico”. Esses itens constaram no Backlog sugeridos pela Equipe pois eram “técnicos”, mas negociamos com o PO. Esses itens constaram no Backlog pois tomaram muito tempo. Como exemplo, o teste de carga tomou quase 1 Sprint para ser efetuado.
Débito Técnico, Débito Funcional, Débito do Projeto
Atualmente defendo uma tese que nossa preocupação são as 3 qualidades do software. A qualidade interna, qualidade externa e qualidade do projeto (ver artigo “Modelagem Ágil”, MundoJava #27). Só para revisar, listo as 3 qualidades do software:
1. A solução atende ao negócio (qualidade externa).
2. O software é fácil de manter e evoluir (qualidade interna).
3. Menor custo e prazo possível (qualidade do projeto).
Um ponto que não mencionei no artigo é que com essa visão das qualidades nós temos 3 “listas de débitos” para gerenciar: débitos técnicos, débitos funcionais e débitos do projeto. Exemplos:
1. Débitos Técnicos:
- Melhorar o Build
- Melhorar a Documentação Técnica
- Melhorar a cobertura de testes
- Fazer passar PMD, Checkstyle
- Código Macarrônico
- Baixa coesão, alto acoplamento
- POG
2. Débitos Funcionais:
- Bugs
- Algumas funcionalidades pequenas não implementadas
- Funcionalidades não implementadas por conta de bugs em bibliotecas de terceiros
- Melhorar usabilidade
- Melhorar a “beleza” da aplicação
3. Débitos do Projeto:
- Uma linha de burndown acima do planejado (cheiro de atraso)
- Custo acima do esperado
- Falta de comprometimento dos Stakeholders
- Falta de financiamento
- Baixo ROI
- Falta de comprometimento da Equipe
Bem, logicamente essa minha tese ainda carece de melhores fundamentos teóricos. De qualquer forma não é algo novo. Simplesmente juntei vários aspectos que já constam em outras literaturas. Essa visão fez e faz sentido nos projetos que participei. Seu processo de desenvolvimento deve focar nas 3 qualidades e os 3 débitos devem ser gerenciados.
Documentando os Débitos
Débitos Técnicos podem ser facilmente gerenciados dentro do próprio código e com suporte das IDEs atuais. A maioria deles constam como //TODO:. Nas IDEs atuais como o Eclipse temos uma boa visão dos To Dos através da View “Tasks”.
Relacionados com Débitos Técnicos temos restrições arquiteturais. Restrições arquiteturais não são débitos técnicos, mas podem se tornar um, principalmente em projetos ágeis e iterativos. Restrições arquiteturais importantes podem constar num documento de arquitetura.
Para documentar débitos funcionais podemos usar o proprio Product Backlog, porém, a granularidade desse tipo de item (débito funcional) costuma ser bem pequena (como os exemplos que citei). Eu relaciono débito funcional como uma funcionalidade pequena que não impede que os usuários dêem a história como pronta, mas não deixa de ser desejável. Vendo dessa maneira, talvez essas pequenas funcionalidades podem constar como issues do Bug Tracking.
Já o débito do projeto pode ser melhor compreendido como o sentimento dos envolvidos com relação ao projeto (vide exemplos citados). Débitos do projeto costumam surgir nos bate-papos das reuniões ou durante o cafezinho da equipe técnica. Para documentar isso de maneira iterativa uma lista de risco é uma boa opção. Essa lista pode ser revista e atualizada durante cada Retrospective ao fim das iterações.
Um alerta importante é: NÃO ADIANTA SÓ DOCUMENTAR! Débitos devem ser vencidos. Para exemplificar, é muito comum que um Gerente de Projetos tradicional encha uma lista de riscos e vire as costas para o problema que ela representa, assim como um programador que faz um código ruim e não tem preocupações com a qualidade interna.
Estude mais:
http://blog.fragmental.com.br/2008/02/17/gerenciando-debitos/
http://josepaulopapo.blogspot.com/2008/04/qualidade-cdigo-manutenibilidade.html
