Débito Técnico

É bastante comum as pessoas reclamarem que a empresa que trabalha não é ágil. Da mesma forma é bastante comum culparem os gerentes, coordenadores, diretores, o cara que cuida dos processos e etc… Algumas pessoas lutam com muito afinco por mudanças e as vezes conseguem adotar uma ou outra prática do Scrum ou até contratam um treinamento. A questão é que na maioria das vezes o que vai impedir o sucesso da adoção Agile na empresa não é o seu gerente, nem seus gerentes de projeto e nem o cara que cuida dos processos: o que impede a adoção Agile na maioria das equipes que tenho contato é a falta de conhecimento de boas práticas de engenharia.

Como já havia citado aqui, design incremental é uma das práticas de engenharia que poucas equipes dominam. Poucas equipes sabem exatamente o que é um incremento. Um dos conceitos do Scrum que é bem pouco comentado e que costumo dar bastante enfoque no meu treinamento é exatamente a definição do pedaço de funcionalidade potencialmente implantável. O próprio Ken Schwaber disse no Gathering que somente 20% das equipes conseguem entregar algo potencialmente implantável ao final da iteração. Inclusive, essa é a motivação dele ter fundado a Scrum.org após sua saída da controversa Scrum Alliance.

Quando dizemos que estamos entregando algo potencialmente implantável isso nos leva a uma visão que poucas equipes Scrum tem: no andar das iterações é o cliente que decide a hora que ele quer ir para a produção, e seu software deve permitir isso. Tudo aquilo que você “incrementou” deve ser capaz de resolver algum problema de negócio sem depender de grandes investimentos em preparação de ambientes ou “Sprints de estabilização”. O que você incrementa além de atender a sua definição de PRONTO deve ser sólido, refatorável, bem arquitetado e durar para sempre. O software criado deve ser um ativo, que coloca dinheiro no bolso de alguém.

Quanto eu estou pareando com alguém ou trabalhando num incremento eu vejo algumas características na realização desse trabalho. Basicamente um incremento é:

- Documentado e especificado (usando BDD, TDD ou outros documentos)
- Analisado (parte do ciclo TDD, refactorings)
- Sólido (incremente com boas práticas OO)
- Coberto por testes (incrementos futuros não quebram o atual)
- Integrado Continuamente (há outros na equipe incrementando)
- Potencialmente Implantável (o cliente decide quando vai pro ar)

A prática dos Baby Steps

Um fato que é bastante interessante é a velocidade dos times ágeis: é um mito achar que times ágeis programam numa correria desatada e que agilistas trabalham num ritmo barulhento, frenético e alucinado. Muitas pessoas que tem contato com uma equipe ágil pela primeira vez pode até estranhar a calma, seriedade e tranquilidade que cerca esses times ágeis. Por incrível que isso possa aparecer, times realmente ágeis “aparentam” ser lentos. É comum ver eles mais pensando do que digitando. Porém, cada passo de bebê que eles dão são passos firmes, determinados, bem pensados e principalmente na direção correta. Numa equipe ágil a cada 2 ou 3 horas vários passos pequenos foram dados e cada incremento agrega valor para o projeto.

Chega ser ridículo quando vou conversar com certos empresários e eles dizem: “- Aqui já somos ágeis… é uma correria do cacete aqui!”

Mentalidade Cascateira do Programador

O maior motivador deste artigo é a minha experiência depois de ter ministrado algumas vezes o nosso novo treinamento Domain-Driven Design. Neste treinamento as atividades práticas são orientadas a testes, e tenho visto que alguns alunos penam para completar os exercícios mesmo quando nós já fornecemos os testes automatizados escritos.

Exemplo: Temos um caso de uso com 4 testes falhando para os alunos implementarem em uma hora. São 4 testes de integração, então, basta fazer cada teste passar em 15 minutos que a solucão está completa. Muitos não conseguem fazer isso, e a maior razão é não conhecer sobre Design Incremental. Eles olham aqueles testes falhando e entram em pânico. Saem cuspindo código sem rodar os testes querendo fazer todos eles passarem ao mesmo tempo. Nos últimos 5 minutos da atividade prática ainda está tudo RED e falham miseravelmente. Simplesmente não lhes parece natural fazer o primeiro teste passar, depois o segundo, depois o terceiro e assim sucessivamente. Eles não pensam em passos de bebê e nem em incrementos. Essa minha experiência é bastante relevante para a questão, e define a mentalidade cascateira:

O cascateiro é aquele desenvolvedor que espera que algo milagroso acontecerá nos últimos instantes do prazo, e tudo aquilo que não funciona passará a funcionar, seja por sorte ou intervenção divina.

Essa definição é essencialmente válida mesmo para quem diz que usa ciclos iterativos. Ciclos iterativos não necessariamente são Ágeis, pois se sua equipe ainda sofre para que tudo que foi implementado funcione ao final da iteração você ainda tem mentalidade cascateira, e precisa melhorar suas práticas de teste e integração contínua.

Você que é desenvolvedor pode fazer uma auto-avaliação prática. Acesse meu Github e baixe o projeto exemplo do treinamento Domain-Driven. Em seguida, acesse a classe CadastrarHospedeTest e tente fazer com que estes testes passem num prazo de uma hora. Pegue como exemplo a classe CadastrarQuartoTest. Depois, responda as perguntas:

1. Você conseguiu implementar em uma hora?
2. Quantas vezes aproximadamente você rodou os testes?
3. Você conseguiu fazer os testes passarem um por um?
4. De 0 a 10, como você avalia a confiabilidade do seu código?

Como eu sempre digo: Colar post-its na parede todo mundo quer, mas escrever testes automatizados ninguém quer.

Desde algumas polêmicas que ocorreram no Scrum Gathering neste ano, tenho discutido em diversos fóruns de discussões e eventos sobre o que tem ocorrido com a nossa comunidade de desenvolvimento ágil. Eu temo pelo o que pode ocorrer com o Agile aqui no Brasil. O que matou o RUP pode também matar o Agile.

Quando eu estava no começo da minha carreira, no início dos anos 90, por incrível que possa parecer os métodos eram ágeis. O cliente e os reais usuários eram muito próximos e participavam ativamente do projeto. O ciclo, apesar de não ter formalidades iterativas, era focado em entregas frequentes. Apesar das arquiteturas fracas, a qualidade era boa e a satisfação dos usuários era maior. Trabalhei com Clipper, Visual Basic 3-6, Mumps e outras coisas da época - além de administrar redes Novell 3.12 e Lantastic. Os projetos eram divertidos, focados em resultados e na maioria das vezes o financiador ficava no seu pé. Eu me lembro do Tonhão, o gerente financeiro da Rede America Burger & Pasta, meu primeiro (e único) emprego como programador CLT. O Tonhão todas as sextas batia na minha mesa no CPD e perguntava: “-E aí Japa, tá pronto?”. Todas as sextas, religiosamente às 15:00 o Tonhão cobrava sobre aquele sistema de controle de caixa das lojas que acabou com os disquetes e com muita burocracia, pois usava comunicação via modem.

Nos meados de 1996 recebí uma ligação de um amigo meu do colégio técnico dizendo que as consultorias estavam pagando R$ 22,00 a hora para projetos do Bug do Milênio em COBOL. Bem, para a época esse valor era bastante significativo, topei na hora e lá fui eu ter a experiência de uma empresa grande. Se existe uma coisa que você pode responsabilizar sobre a bagunça que existe no mercado de TI hoje essa coisa é O BUG DO MILÊNIO. Eu estranhei muito trabalhar em consultorias nessa época. Os projetos chegavam e nem tinha uma única reunião com o cliente. Na maioria das vezes tinha um gerente-proxy entre a equipe e os clientes. Os projetos Y2K eram ainda mais peculiares. Teve projetos que o trabalho era passar uma ferramenta de detecção de problemas Y2K, ir até o código indicado pela ferramenta e fazer as alterações, mas sem recompilar e sem qualquer teste. Eu me sentia um digitador. Levei até uma bronca de um coordenador por tentar compilar o projeto para ver se nossas alterações ao menos geravam os binários. Meu coordenador gritou que aquilo não era escopo do projeto. Nesse momento eu ví que qualidade não era uma preocupação central das consultorias.

Passada a fase Y2K, começaram os projetos Internet e de sistemas periféricos de grandes implementações ERP. O problema é que o desenvolvimento de software empírico (que eu apliquei nos meus estágios e lá na Rede America) não atendia às necessidades de projetos outsourcing. Gerentes queriam controles, relatórios e Gantt Charts. A preocupação maior era a mesma dos projetos Y2K - O ESCOPO. Se você estivesse numa consultoria no final dos anos 90, você compreenderia perfeitamente o mindset do SEI com o seu CMM. Os gerentes de consultorias buscavam algo que amarrasse a equipe ao contrato com o cliente. Meio por fora de tudo isso comecei a estudar Orientação a Objetos, OMT, Booch, e mais pra frente, a UML e o RUP. Minha primeira experiência prática com o RUP foi num projeto internacional para a Phillips Medical Systems em 1999.

Esse projeto da Phillips era um sistema orçamentário empresarial que integrava vários departamentos, inclusive a matriz em Rotterdam. Foi desenvolvido em Visual Basic, Orientado a Objetos e banco de dados Oracle. Quando olhei o RUP pela primeira vez gostei de Casos de Uso, Iteratividade e o foco Arquitetural. Neste projeto a equipe variou entre 3 a 5 pessoas. No início estabelecemos uma Visão para definir o problema junto aos usuários, o ciclo iterativo era de 30 dias e tinha perto de 15 casos de uso (que escrevemos de maneira correta). Usamos o famigerado Visual SourceSafe (o supra-sumo da época) e somente uns 6 ou 7 diagramas UML foram mantidos como artefatos (além do MER). O foco sempre era entregar o produto e não preencher artefatos. A gente até tinha alguns testes automatizados, mas a maioria dos testes era manual. Entregamos o projeto após 3 ou 4 iterações e foi um sucesso! A satisfação dos usuários foi além das expectativas. A partir desse projeto, o modo que eu instancio o RUP é assim: Iterativo, Orientado ao Usuário (Casos de Uso) e centrado em Arquitetura.

Quando voltei desse projeto para a consultoria um dos meus gerentes queria saber como foi o processo. Eu comecei a falar que o cliente participou bastante e que as entregas a cada 30 dias foram determinantes para diminuir os riscos. E a pergunta que se seguiu traduz bastante o mindset de um gerente (da época ou de hoje): “- Legal, legal, Rodrigo, mas quais eram os documentos que vocês preenchiam?”. Aí eu falei que usamos a Visão, os Casos de Uso, a UML, o MER… logo em seguida veio a pergunta número 2: “- Você poderia me dar um exemplo de cada um para usar no projeto XPTO?”. Hoje eu vejo que ele estava buscando respostas fáceis. Na época eu poderia ter dado minha cópia do livro sobre Unified Process dos Três Amigos, porém, o que eu fiz foi copiar um disquete com os artefatos. Ainda hoje ainda me culpo por ter feito aquilo, mas eu era ainda um profissional inexperiente, com pouco mais de 5 anos de estrada. Colaborei para a ilusão daquele gerente por respostas fáceis. Me desculpe se você era um dos desenvolvedores do projeto XPTO na virada do ano 2000. Me desculpe se um dia, um gerente chegou para você entregando um disquete dizendo: “- Olha, o preenchimento desses artefatos garantirão o sucesso do projeto.”

Na virada do Milênio, eu ví pessoas e empresas buscando processos como o RUP e outros pela motivacão errada. Eles achavam que a maneira “falar com o usuário - implementar - entregar” era pouco controlada. O pensamento era: “Ninguém assina nada?”. Nessa época os gerentes voluntariamente queriam uma burocratização. Era proibido falar as palavras empírico e pragmático nesta época. Não importando o Manifesto Ágil publicado em 2001, aqui no Brasil o que eu ví foi adoção de processos por pura burocratização.

No ano de 2003 eu ví a primeira palestra de um “especialista” falando absurdos sobre o RUP, no melhor estilo Waterfall. Ele disse coisas do tipo “Levantar todos os requisitos na concepção”, “Modelar tudo na fase de elaboração”, e principalmente, o cara pregava descaradamente a errônea sequência Casos de Uso - UML - Codificação - Testes, e uma irracional separação de papéis que está em uso até hoje. Ele teve até tempo de mostrar como preenchia alguns artefatos. Nesse tempo eu não era tão crítico como hoje, e nem mesmo para os meus amigos que assistiram a palestra eu alertei contra as falácias daquele fanfarrão.

A cada dia que se passou desde então, ví mais e mais pessoas falando absurdos do RUP. Quando se diz RUP atualmente no mercado muitos torcem o nariz, associam com cascata, associam com artefatos, associam com ferramentas Rational, e principalmente, associam com esse pensamento burocrático da virada do milênio. Muitos dos que criticam são agilistas famosos, mas que não tem mais de 10 anos de experiência. Eu queria que a maioria desses consultores e especialistas Agile estivessem lá nos anos 90, reclamando da implementação OO nos produtos base da Microsoft, tentando entender Objective-C e vendo uma esperança OO mais simples no Delphi como alternativa. A gente acreditava que a Orientação a Objetos resolveria todos os nossos problemas, mas 15 anos depois ainda temos modelos anêmicos e pessoas sem a mínima noção do que são dependências ou mensagens querendo discutir OO em fóruns colocando sua pilha de certificações na sua assinatura de e-mail.

Em 2003-2004 eu tive o primeiro contato com o Extreme Programming num projeto J2EE para um grande Call Center Vendas, um projeto único no mundo, clusterizado, distribuído, Swing e mensageria. Sobre o XP, quer saber? Não ví quase nada de novo. Agora Casos de Uso são User Stories menores, o ciclo iterativo é mais curto, o desenvolvimento é orientado a testes (isso sim achei uma boa idéia, apesar de não compreender bem nos primeiros projetos) e a programação é em par (isso também geralmente não é uma azeitona fácil de engolir logo de primeira). Eu particularmente tenho dificuldade em parear com algumas pessoas devido ao meu déficit de atenção. Eu olhei para o XP e no primeiro momento ví que muito do que diziam do XP era algo parecido com o que a gente fazia nos anos 90, principalmente a parte do cliente presente. Todos os meus clientes no início dos anos 90 eram presentes. Comparado com a visão do desenvolvimento de software das consultorias o XP era o cúmulo da controvérsia. Já na mentalidade de um desenvolvedor de software dos anos 90, o XP faz todo sentido do mundo. Meu primeiro contato com o Scrum foi em 2005. E mais uma vez tive aquele sentimento: Sim, é bem diferente das práticas erradas do mercado, porém, não é muito diferente do RUP. Ele diz mais sobre ROI e sobre um importante Product Owner, mas também me lembro do Tonhão como um Product Owner nato nos anos 90. Em 2005 o Scrum era o cúmulo do descontrole de custos do projeto, por conta do seu escopo aberto e por conta do mindset PMBOK, mas para um desenvolvedor dos anos 90, simplesmente é o retorno aquilo que a gente já fazia: nos anos 90 não tinha pressão para se entregar tudo, mas havia pressão para resolver os problemas de negócio do cliente. E eu me lembro do Tonhão todas as sextas me cobrando aquilo que estava pronto, doido para colocar a aplicacão no ar só para ter certeza que ninguém na rede estava roubando ele.

A grande questão sobre o Agile Movement é sua mudança cultural. Infelizmente são poucas as pessoas que se divertiram fazendo software nos anos 90 - se você costuma tratar os desenvolvedores como crianças, lentamente eles se convencem que são crianças. O manifesto é um grito contra as coisas erradas do mercado. É uma emancipação dos desenvolvedores que não querem ser crianças. É uma injeção pragmática contra o pensamento pseudo-tradicionalista, controlador e traumatizado que existe hoje no mundo empresarial, especialmente na indústria do desenvolvimento de software.

O que vocês devem estar se perguntando é: O que matou o RUP e pode matar o Agile? Como eu falei, eu temo pelo movimento Agile. Assim como foi em 2003, em 2009 eu ví o primeiro pseudo-especialista Agile falando absurdos - violando valores. A partir do momento que eu vejo a comunidade Agile discutindo e dando importância demais a post-its, quadro de tarefas e cartinhas de planning poker, eu temo pelo movimento Agile. Quando eu vejo a comunidade Agile buscando certificações, preocupados em como casar Agile com CMMI ou como adaptar Agile à contratos de escopo fechado, eu temo pelo movimento Agile. Sempre que eu vejo isso no mundo Agile, me transporto a 10 anos atrás e me lembro das discussões sobre templates de casos de uso, definições de padrões de modelagem UML, pensamento linear, check-lists de artefatos, uso incorreto de ferramentas, falta de compreensão sobre fases e o pior de todos: o departamento que cuida dos processos de desenvolvimento. Resumindo, quando vejo esse mindset de besteirols e libertinagens Agile, eu me lembro do mindset burro e burocrático que contaminou o RUP.

O que matou o RUP foi a falta de entendimento, e isso é o que vai matar o Agile. Lean é o próximo da fila. Escreva aí: em 5 anos, dependendo dos ventos da economia e do clima empresarial, muitos vão estar criticando Agile do mesmo modo que hoje criticam o RUP, sem autoridade de causa. Tudo vai depender do mindset vigente no momento. Tudo depende do mindset: se você der o Scrum e XP para um “tradicionalista” ele não vai mudar seu mindset, mas sim adaptar o Scrum e o XP às suas “crenças”. Se você der o RUP para um pragmático, ele também não muda o seu mindset, mas sim, adapta o RUP à sua realidade. Você pode decidir o seu mindset: ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha.

Mais sobre o assunto “queda do Agile”:

Agile está morto! D-us salve o Agile! - José Papo
The Decline and Fall of Agile - James Shore
Por que dizemos não à certificação de Scrum Master - Vinicius Teles
A Completa Irrelevância do Certified Scrum Master - Philip Calçado
Flaccid Scrum - Martin Fowler

Esse artigo e a palestra que ministro com mesmo título é inspirado em “What Killed Smalltalk Could Kill Ruby, Too”, Keynote do Robert Martin (ou Uncle Bob) na RailsConf ‘09. Uma das melhores palestras que já ví. Veja abaixo:

Domain-Driven Desing não é sobre padrões - isso gera muita discussão. Domain-Driven Design (ou simplesmente DDD) é sobre fazer software de maneira mais simples - e sei que muitos não vão concordar com isso, pois “parece” que é mais fácil e muitos se sentem muitos produtivos ligando Table Modules diretamente às telas e abusando de Transaction Scripts.

O objetivo deste artigo não é falar sobre o que a literatura diz sobre repositórios e nem tenho a pretensão de escrever o “post definitivo sobre Repositórios”. O objetivo aqui é demonstrar como tenho aplicado Repositórios nesses 3 anos de experiência em aplicação e ensino de DDD.

O que são Repositórios afinal?

Antes de mais nada, orientamos a aplicação ao domínio. O exemplo que vou montar aqui não é real, mas é bem próximo daquilo que apliquei em alguns projetos. Orientar a aplicação ao domínio significa que seu código será limpo e principalmente sua camada de negócios demonstrará o NEGÓCIO, suas regras, seu estado e suas associações. Se sua aplicação é de vendas, é esperado que o vocabulário do domínio “vendas” seja encontrado nas suas classes. As classes do domínio também não devem ser poluídas com o domínio técnico: o domínio “vendas” não sabe o que são tabelas, filas, sistema de arquivos e nem SMTP. O domínio técnico e do domínio do negócio tentam ao máximo não se misturar numa aplicação Domain-Driven.

Se minhas classes de negócio traduzem a linguagem de vendas, quero que você tente pensar num modelo que resolva os seguintes requisitos:

1. Um pedido de vendas possui cliente e itens
2. O valor total do pedido é a soma do valor dos itens
3. Somente produtos disponíveis podem ser vendidos

Imagine agora, como um ator Vendedor utilizaria o sistema. Ele criaria um pedido, colocaria alguns itens com produtos disponíveis e finalizaria este caso de uso. Quero que você pense bastante em como você resolveria o requisito número 3. No meu código, surgiria algo deste tipo:

A primeira pergunta natural é: Por que o repositório está como uma interface? Muitas vezes o Repositório simplesmente é uma abstração do domínio cuja responsabilidade é representar coleções de entidades, porém, ele ainda é um elemento do domínio. Muitas vezes nós temos um elemento que realiza esta interface para fornecer implementação para essas buscas.

Usar repositórios como interfaces é bom para a saúde da testabilidade da sua aplicação e ainda posso me beneficiar de injeção de dependência. Isso facilita o uso de Mocks e Stubs para testes unitários ou de integração, além de deixar seus objetos desacoplados.

Teve algumas situações peculiares onde a interface TodosProdutos era um elemento do domínio e a implementação TodosProdutosImpl era puramente infra-estrutura. Neste caso, TodosProdutos (a interface) estava empacotada no domínio (geralmente uso o nome domain) e a TodosProdutosImpl estava empacotado como infra-estrutura.

De qualquer forma, para a discussão aqui, simplesmente destaco que o repositório TodosProdutos é algo puramente do vocabulário de negócios. “Todos os Produtos” é algo que o meu usuário sabe o que significa. E TodosProdutos.getDisponiveis - a minha operação - faz mais sentido ainda para os usuários, pois eles também sabem o que são produtos disponíveis para venda (se isso para eles é uma interface ou uma classe isso é completamente irrelevante).

Repositórios como Coleções Parciais

Teve uma certa aplicação que desenvolvi que nas conversas com os especialistas de negócio um determinado termo era muito recorrente. Eles se referiam a um determinado conjunto de entidades com um nome especial: pedidos faturados. E nesse sistema, os “pedidos faturados” tinham uma força tão grande na Ubiquitous Language da DDD que passou a ser um contexto separado.

Várias vezes mostrei esse diagrama a arquitetos e programadores e muitos não entenderam isso facilmente. É bastante comum as pessoas associarem um repositório por entidade, enxergando-os como 1 para 1 com DAOs. Muitos desses programadores que não entendem DDD questionaram: - Por que separar isso? Minha resposta: - Não fui eu que separei isto… no domínio do negócio isso é separado. Não é uma opção arquitetural, somente estou transparecendo o domínio.

A maioria das respostas sobre a camada de negócios numa aplicação Domain-Driven é dada pelos usuários e especialistas do domínio e não pelos arquitetos e programadores.

O nome não deve ser XptoRepository?

Durante algum tempo, seguindo a linha do Hibernate, minhas classes de busca eram [NomeDaEntidade]DAO. Depois de um tempo meus DAOs eram repositórios, mas continuava chamando-os de DAOs, pois odeio o nome Repository dentro do meu código. Acho pior ainda o nome “Repositório” - que é uma tradução livre corrente. O nome Repositório é bem pouco expressivo em português (que raios é repositório?) - o termo em inglês é mais claro.

Ao fim de tudo isso, vejo que é bem pouco proveitoso chamar uma classe de domínio de PedidoRepository ou PedidoRepositorio. Teve uma aplicação que chamei meus repositorio de “Pedidos”, mas últimamente tenho usado mesmo “TodosPedidos”, “TodosClientes”, “PedidosFaturados”, “ClientesInadimplentes” e etc… Uso esses termos pois são mais próximos do domínio e não vejo a mínima razão para ter o nome do padrão no nome ou empacotamento das classes.

Pedido é uma entidade, nem por isso o chamamos de PedidoEntity, o mesmo vale para Value Objects, Services e Repositórios. O BufferedInputStream do Java é um Decorator, nem por isso chamamos ele de BufferedInpuStreamDecorator.

Repositórios mais Complexos

Associar repositórios com buscas nem sempre é verdadeiro. Repositórios respondem por conjuntos de entidades, não importando a dificuldade de se obter esse conjunto. Há repositórios que podem ter código de negócio complexo em sua execução onde determinadas operações podem à primeira vista aparentar simplesmente uma busca. Você deve levar em consideração se há inteligência de domínio envolvida, caso afirmativo seu repositório deverá ter essa inteligência embutida. Vamos colocar mais requisitos:

4. Se o pedido é para entrega imediata, os produtos disponíveis são aqueles que eu tenho em estoque no momento da venda
5. Se o pedido é para entrega futura, os produtos disponíveis são aqueles que estarão em estoque na data de entrega

Neste “TodosProdutos” refatorado, para obter os produtos disponíveis na data da entrega é necessário pegar o saldo atual do estoque, subtrair os pedidos de venda já comprometidos (saídas) e somar os pedidos de compra (entradas) até a data desejada. Tudo isso é inteligência de domínio que não deve ser delegado para o banco de dados. É um repositório que tem regras e pode até orquestrar junto a outros repositórios e services para cumprir o seu propósito.

Um ponto importante a destacar é que muitas outras variações de implementações de repositórios existem. O objetivo do artigo é somente destacar algumas implementações interessantes que implementei em alguns projetos.

É lícito acessar o EntityManager diretamente?

Discussões sobre Domain-Driven e implementações de respositórios são muito recorrentes em listas de discussões, principalmente no GUJ e na DotNetArchitects (sou novo nessa lista).

Uma das perguntas comuns é: “É licito eu acessar diretamente o EntityManager ou Sessão do Hibernate?”. Particularmente eu sou da opinião que se você está fazendo buscas que não são importantes para o negócio não há problemas acessar diretamente seu framework de persistência. Logicamente que isso não deve ser levado a ferro e a fogo, testabilidade e complexidade são pontos a considerar.

Um exemplo seria: imagine que para emitir o pedido eu tenha que preencher um combo com o tipo de venda (um dado simplesmente informativo). Se é uma busca de uma entidade fraca, que significa muito pouco para o domínio, para reduzir a complexidade, o repositório pode ser descartado sem muito prejuízo para a testabilidade.

Quando publiquei o artigo Product Owner: um desgraçado ganancioso a minha intenção foi quebrar uma visão errada que o mercado tem a respeito de Scrum e Agile em geral. Muitas pessoas que converso em clientes, eventos e listas de discussão tem uma visão muito romântica a respeito do Scrum. Muitas delas entraram em choque ao ler esse artigo que diz que o Product Owner é um cara que só pensa em dinheiro.

As pessoas tendem a achar que tudo no Scrum é romântico, não tem nada te pressionando, a colaboração é linda, o Product Owner é paciente, as coisas fluem naturalmente, o ScrumMaster é um líder terno e querido, é só colar post-its no quadro, entregar iterações, entrar em débito técnico, comer pipoca nos plannings e viver feliz para sempre.

Infelizmente o Scrum não é assim. Nós precisamos entregar o projeto! Eu sei que muitos CSMs, CSPs e CSTs podem não concordar com o que vou dizer agora, e vou deixar bem claro aqui: a Reunião Diária do Scrum é o melhor mecanismo de cobrança que existe.

Quando tive os primeiros contatos com Scrum em 2005 (e antes disso eu aplicava as práticas iterativas de gerenciamento de projetos do RUP), eu estava trabalhando num projeto internacional que seria implantado em mais de mil hospitais no Japão*. O primeiro projeto de nove dígitos a gente nunca esquece. O projeto estava indo bem com as práticas do RUP, porém, sabe como é uma criança com um brinquedo novo? Eu estava doido para aplicar o Scrum e a transição foi bem tranquila (a equipe era sênior). Nessa virada, tomei uma das decisões mais sábias da minha carreira: eu deleguei o papel de ScrumMaster para outra pessoa. Eu atuei como um membro da equipe.

Tomei essa decisão de não ser ScrumMaster porque vejo que muitas práticas que descem da gestão na maioria das vezes não fazem sentido para as equipes. Eu quis provar o Scrum sob todos os aspectos. Atuar como membro da equipe antes de atuar como ScrumMaster foi uma experiência valiosa. Um ScrumMaster jamais será um bom ScrumMaster se ele nunca atuou como membro da equipe num projeto Scrum.

Nos primeiros dias eu ví que as reuniões diárias mostravam uma coisa claramente: me faltava FOCO na execução das tarefas. Eu era arquiteto, e muitas vezes não cumpria as tarefas do projeto simplesmente porque estava correndo atrás de algum capricho arquitetural ou perdia o dia lendo mails e fazendo coisas na Internet. Quando eu via que estava “viajando” demais, eu lembrava que às 15:00hs teria a reunião diária, e eu não havia cumprido a tarefa sob minha responsabilidade. Eu me sentia cobrado porque a reunião diária estava se aproximando e eu não tinha trabalho nenhum para mostrar para os outros membros da equipe.

Vocês se lembram das perguntas da reunião diária:

1. O que você fez desde a última reunião diária?

2. O que você pretende fazer até a próxima reunião diária?

3. Tem alguma coisa impedindo o seu trabalho?

Nas perguntas 1 e 2 a equipe não está se reportando ao ScrumMaster! Nessas perguntas a equipe está se reportando para ela mesma de forma auto-gerenciável. E sabe o que é interessante? O comprometimento da equipe é maior com a própria equipe do que com os níveis hierárquicos superiores. Quando você está falando o que você fez para a própria equipe você sabe que eles estão no mesmo barco que você. Não há razões para constrangimentos, dissimulações e conflitos.

É muito fácil enganar um gerente de projeto que passa com um Gantt Chart perguntando “- Já terminou a tarefa? Quantos porcento ainda falta?”. Agora, não é tão fácil assim enganar os membros da própria equipe… Eles passaram o dia todo com você. Não adianta você falar que não cumpriu a tarefa porque teve problemas com o RichFaces, pois os outros membros viram que você ficou a manhã inteira procurando seu carro novo na Webmotors. Não adianta você falar que não conseguiu falar com o usuário - a equipe viu que você ficou discutindo sobre repositorios no GUJ. Não adianta reclamar que o build demora - a equipe sabe que você ficou rodando os testes só para conversar com aquela loirinha do projeto ao lado.

A reunião diária está chegando, então, mostre serviço! Por mais romântico que você queira ser com o Scrum e com a auto-organização/gestão, por debaixo dos panos o Scrum tem mecanismos de cobrança, e são mecanismos muito melhores que um gerente de projeto perguntando “percentuais de conclusão”.

* Sei que você arquiteto de plantão deve estar doido para saber como era esse projeto do Japão por dentro. Vamos lá: Usamos Domain-Driven Design, cliente Swing, JBoss e EJB3/JPA/Hibernate no servidor, integração via XML-RPC - o troço tinha que escalar. Conseguimos suportar 80 transações simultâneas numa máquina com 2 processadores (o objetivo do projeto era suportar 1.000 prescrições médicas por minuto). O maior desafio era a usabilidade: japonês gosta muito de telas TouchScreen (por isso que os botões são grandes). Outras características: segurança biométrica, assinatura eletrônica de documentos, integração com máquinas de diagnóstico por imagem e quando você ligava o japonês não dava nem pra navegar na aplicação, só decorando os labels. Foi um dos projetos mais interessantes que participei.

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…

Leia o restante deste artigo »

Na edição 29 da revista MundoJava escreví sobre o dia a dia de um agilista. Continuando uma série sobre TDD na Revista MundoJava nesta edição escreví um artigo sobre a ferramenta FIT para automação de testes. O artigo teve participação de Ivan Sanchez e James Shore.

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.

Como “peso” de conhecimento na minha opinião a certificação IBM Rational Solution Designer é muito melhor. Tem muito conhecimento da prova da OMG que simplesmente é dispensável para o nosso dia a dia. Geralmente digo que prova não prova nada, por esta razão, não critico tanto a certificação CSM da ScrumAlliance (a não ser pelo preço, acredite, tem gente lá fora ficando rico com isso). A certificação OCUP da OMG não prova que você sabe o que é orientação a objeto, nem que é um bom modelador. Só prova que você conhece a especificação da UML 2.

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 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

Este post é sobre a comunidade Java que está enferrujando (eu me incluo na comunidade Java). Não sei se é porque a comunidade cresceu. Não sei se é porque temos muitas JSRs. Não sei se é porque a linguagem popularizou. E nem sei porque ainda achamos que daqui a 10 anos ainda estaremos programando em Java.

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.