Archive for the ‘fragmental’ Category

Minhas Propostas para a Agile Brazil 2010

Saturday, February 27th, 2010

Acabo de submeter algumas atividades para o Agile Brazil 2010, evento que se realizará em Junho em Porto Alegre. Pelo que entendi, as propostas serão avaliadas pelo comitê organizador do evento.

As propostas estão disponíveis no site e o público pode fazer comentários. Minhas submissões:

Líder Técnico - O Ex-Arquiteto virou Faz-Tudo!

Ele era o centro das atenções. Nenhuma classe era criada sem a sua aprovação. Nenhuma biblioteca era introduzida sem que ele homologasse. Nada entrava ou saía sem a sua verificação. Seus diagramas formavam o livro sagrado do sistema, se o sistema não reflete o diagrama então os desenvolvedores devem ser punidos, obviamente eles não entender seu Grande Plano para Tudo™.

E daí veio este tal de agile. Não apenas introduziu práticas de qualidade duvidosa (duas pessoas, um computador? Sério?) mas também quer eliminar seu papel de visionário. Como um time poderia funcionar sem a visão inpiradora? Como um mero desenvolvedor pode decidir o que é melhor para um projeto onde são investidos milhões?

Pior ainda, o que o líder faz agora que não existem mais diagramas para desenhar?

Arrumando a Casa Após a Festa: Saindo do Pseudo-Agile

Tudo parecia muito simples. Os cartões vão na parede, os times se auto-gerenciam, o tal do Product Owner escreve nos cartões, o time faz retrospectiva… Tantos casos de sucesso por aí, tantos sorrisos e tapinhas nas costas…

Por que está dando tão errado aqui? Por que está fazendo da minha vida um inferno? Por que meu time não está aumentou a produtividade? Por que meus produtos continuam sendo uma porcaria? Por que parece que ninguém sabe o que está acontecendo?

Este é o saco de dúvidas que tenho encontrado por aí.

A maioria vai achar que basta seguirmos os 12 passos do programa e, eventualmente, as coisas vão entrar nos eixos. A maioria acha que basta demitir os gerentes de projeto e colocar coisas coloridas na parede. A maioria acha que basta escrever testes e seu código vai ter qualidade. A maioria acha que basta quebrar casos de uso em histórias e você terá melhor comunicação.

A maioria vai falhar miseravelmente.

Nos últimos anos tenho gasto uma boa parte do meu tempo tentando fazer clientes entender que não importa a cor do cartão na parede, não importa a sua plataforma de desenvolvimento, não importa se você usa cruise ou hudson, não importa se retrospectivas são quinzenais ou mensais… a única coisa que importa nesses tais métodos ágeis é termos ciclos de feedback curto.

Nesta sessão vamos conversar sobre alguns cenários, todos baseados em projetos reais, e no que pode ser feito para tirar o pseudo do seu agile.

E, além das duas palestras, o Rodrigo Yoshima me convidou para ajudá-lo no seu workshop de modelagem:

Reconheça! Você não sabe modelar! Iniciando Projetos Ágeis

Neste workshop prático vamos simular o planejamento inicial de um projeto ágil utilizando as mais variadas técnicas de modelagem como Domain-Driven Design, CRC Cards, User Stories, Paper Prototyping e Brainstorming.

Ajude o cliente a compreender melhor o problema, melhorando seu planejamento e auxiliando as suas estimativas. Um bom modelo ou protótipo serve como uma simplificação de algo complexo, uma abstração útil para o desenvolvimento do projeto. Em projetos ágeis a modelagem está presente, porém, ao invés de uma modelagem solitária numa ferramenta UML, equipes ágeis inovam em colaboração, usando artefatos simples numa dinâmica divertida.

Domain-Driven Bolovo, Passando Conhecimento e etc.

Monday, January 18th, 2010

Segue uma seqüência aleatória quase coesa de pensamentos que me vieram a cabeça enquanto esperava meu vôo para Salvador.

Paulo Silveira surgiu com o termo BOLOVO, usado para indicar uma arquitetura baseada em VOs e BOs, enquanto preparávamos os slides para nossa apresentação em conjunto no JustJava em 2007.

O artigo original sobre BOs e VOs fala basicamente sobre como a arquitetura proposta por EJBs na especificação antiga (2.x) prejudicou o entendimento da comunidade em geral sobre como criar a aquitetura de uma aplicação.

Três anos se passaram mas o artigo ainda recebe um numero de acessos razoável –e eu vivo prometendo que vou atualizá-lo. A última vez que tive que escrever um EJB 2.x foi em 2007, desde então –talvez por sorte- nunca mais entrei em um projeto que usasse estas aberrações. Muitos programadores de hoje em dia começaram suas carreiras na época que EJB já estava morrendo e nunca tiveram o desprazer de lidar com esta porcaria. É de se esperar que estas pessoas, tendo estado sempre cercado por IoC, DDD e técnicas bem razoáveis, iria olhar para um artigo como o que escrevi da mesma forma que eu olho para um livro de linguagem de máquina para Apple II –interessante no contexto histórico mas quase que apenas uma curiosidade.

Vira e mexe, entretanto, eu sou lembrado do porque o artigo ainda recebe tantas visitas todo dia. Os programadores mais novos podem não ter sido influenciados pelos problemas dos EJBs mas ele ainda foram ensinados à programar de uma só maneira: código procedural.

Quando estava preparando a primeira iteração do workshop de Domain-Driven Design que faço em parceria com a Caelum eu escrevi um texto para explicitar meu raciocínio sobre como Domain-Driven Design se difere de Orientação a Objetos. No workshop em si eu dediquei boa parte da manhã falando sobre este tema.

E por quê? Porque da mesma maneira que as pessoas utilizavam os conceitos de EJB completamente fora de contexto o mesmo está acontecendo com Domain-Driven Design. É bem comum, em uma conferencia ou algo do tipo, alguém vir conversar comigo sobre como a empresa dele está eliminando todos os BOs e VOs. No meio da conversa a pessoa começa a me explicar a arquitetura e eu vejo que praticamente o que eles fizeram foi renomear UsuarioBO para UsuarioService e UsuarioVO para Usuario. Repositórios, então… estes são tão mal utilizados que deram origem à vários textos aqui:

Independente do uso de DDD e seus padrões ou não eu realmente esperaria que, em 2010, as pessoas já houvessem entendido como objetos deveriam ser criados. A quantidade de material disponível gratuitamente na Internet e em múltiplos idiomas é ridiculamente grande.

Me levou muito tempo para entender que não importa a quantidade de material disponível. Em minha experiência, a maneira mais eficiente de introduzir estes conceitos é programação em par. Quando um cliente me chama para introduzir estes conceitos em seu time eu sempre tenho que tentar explicar porque isso não pode ser apenas um treinamento. Ë difícil de entender porque eu posso treinar alguém em algo complexo como uma linguagem de programação mas não em uma técnica com mais de 40 anos que exige como pré-requisito nada mais que conceitos lógicos básicos. Eu, pessoalmente, não faço a menor idéia do porque as coisas são assim, só sei que o são.

Normalmente eu começo o trabalho com uma apresentação rápida, apenas para tentar fazer as pessoas entenderem o que diabos eu vou tentar fazer. Um exemplo de uma destas apresentações:

E logo depois começamos a parear. O ideal é termos pelo menos 1 coach para cada dois pares, mas nem sempre este número é viável. Quando a quantidade de pessoas exceed muito a quantidade de coachs a melhor solução parece ser pareamento promíscuo, mudando os pares em intervalos bem curtos de tempo.

Nestes últimos anos eu tive diversas oportunidades de reencontrar clientes e parceiros depois da conclusão do projeto ou treinamento. Na minha experiência os times que tiveram apenas treinamento retêm apenas uma ou outra coisa do todo, eles entendem o todo mas não conseguem aplicar na prática –e aí mora o perigo do Domain-Driven BOLOVO. Os times onde utilizei coaching como meio de transmissão de conhecimento tendem a ser o contrario: eles usam as técnicas no dia-a-dia mas não entendem o todo. Ao não entender o todo eles não conseguem evoluir alem do que o que lhes foi passado durante aquele período.

É de se esperar que o primeiro grupo seja mais valioso para um empregador. Na prática, entretanto, não parece ser o caso. Um treinamento, um livro, etc. podem curar a deficiência do segundo grupo e tendem a ser bem mais baratos e eficientes que gastar dinheiro com um consultor que cobra por hora. O grande benefício que o consultor vai te trazer é que ele sabe –ou deveria- como utilizar aqueles conceitos na prática. O melhor uso do consultor neste caso é trabalhar com o time no dia-a-dia e realizar pequenas sessões de treinamento –no meu caso geralmente isso significa 20 minutos por semana- conforme necessário.

Preparações e Desculpas Esfarrapadas

Monday, October 26th, 2009

Para variar, a desculpa para não ter escrito mais frequentemente é a preparação requerida para a viagem ao Brasil. Eu sei que é uma desculpa esfarrapada mas infelizmente esta etapa envolve mais do que fechar malas e comprar canguru de pelúcia para as sobrinhas, meus últimos dois projetos requereram muita atenção e neste exato momento eu estou finalizando os últimos detalhes de um deles.

Isso fez com que meus planos se alterassem um pouco. Infelizmente não vou ter tanto tempo quanto gostaria para encontrar pessoas, especialmente fora do Rio. Ainda vou em alguns lugares mas nada perto do que tinha em mente antes.

Sobre o evento, acho difícil haver alguém que ainda não tenha esbarrado com um dos banners ou coisa parecida sobre o Caelum Day. A programação está bem interessante e promete ser um dia útil e divertido.

Minha apresentação vai focar no que eu mais tenho feito nestes últimos dois anos: fazer com que times de desenvolvimento saiam do marasmo e comecem a entregar. Não me venha com essa história de “minha metodologia não deixa”, “meu chefe é mau”, etc., todo lugar tem problemas e as coisas dependem de você. A apresentação possui dicas e fundamentos técnicos mas sem vontade nada vai pra frente.

E para, refletir de maneira bem realista o clima da indústria de desenvolvimento de software, este ano eu escolhi mais uma vez filmes de terror para servir de pano de fundo (e comic relief). Ao contrário do ano passado, entretanto, eu escolhi um filme em específico. O primeiro comentário quem acertar o filme baseado na capa da apresentação abaixo ganha… algo… que eu ainda vou decidir:

caelum rio day

As inscrições ainda estão abertas aqui.

Para o workshop de Domain-Driven Design não há mais vagas –mas existe uma lista de espera.

Algumas pessoas ficaram curiosas porque escrevi no meu blog em inglês que acho o assunto (DDD) tedioso. Existe uma enorme demanda de cursos sobre o tema e o Paulo Silveira e eu decimnos que valia a pena realizar mais uma rodada dos cursos. Eu continuo usando Domain-Driven Design em meus projetos e textos, mas o assunto já está meio batido e mastigado.

Na minha opinião, DDD deveria ser parte de um curso maior sobre design em geral, um workshop específico tem relevância quando o assunto é novidade mas perde o apelo quando a técnica começa a ser utilizada por mais gente. Tenho lido mais sobre outras coisas e, se tudo der certo, vamos ver se em 2010 eu consigo aposentar o workshop de DDD e partir para estas novas coisas.

Bom, por enquanto é isso. Nos vemos semana que vem.

Projeto Brazil 2009 - Preenchendo Lacunas

Wednesday, July 22nd, 2009

Bom, com a passagem na mão e devidamente autorizado pelas autoridades competentes eu posso publicar aqui que este ano, mais uma vez, eu vou passar alguns dias no Brasil em uma clássica e manjada parceria com a Caelum.

O plano original é emendar tudo com o lançamento do livro -que eu, relapso que só, ainda não mencionei neste blog- mas este plano pode mudar. De qualquer maneira o esquema básico é o mesmo do ano passado: uma conferência e alguns workshops. Ainda não posso falar sobre nenhum deles porque nada foi decidido mas assim que eu tiver definições eu posto aqui.

Mas meu objetivo com este post é me colocar à disposição. A viagem deste ano é totalmente a trabalho -tirando alguns dias para a família e os amigos, claro- e eu pretendo visitar o maior número de grupos de usuários, empresas e comunidades de desenvolvimento de software que eu conseguir. Faz dois anos que estou na Austrália e apesar de meu contato diário com a comunidade brasileira uma coisa é falar de longe e outra é ver de perto.

Eu tenho algumas visitas já marcadas e, infelizmente, não muito tempo disponível então vou ter que priorizar as coisas. A minha idéia original é chegar no grupo de usuários/empresa/etc., fazer uma apresentação de uns 30 minutos e depois passar algum tempo pareando com as pessoas e atualizando minhas percepções sobre o mercado brasileiro em geral. Eu chego dia 31/10 e volto dia 15/11, estarei, a princípio, no Rio durante toda a viagem mas topo viagems próximas.

Topa? Me manda um email. Não sabe meu email? Se vira.

Refletindo sobre Tendências

Friday, July 10th, 2009

Recentemente muita gente tem me procurado nos instant messengers da vida para perguntar sobre tendências. Existe uma idéia no Brasil de que quem está de for a “traz as novidades”. Isso podia ser verdade antes da Internet mas agora as coisas se espalham com tanta velocidade que em muitos aspectos o Brasil está muito na frente da Austrália.

Mas existe o outro lado que é o trabalho na ThoughtWorks. Os projetos que nós enfrentamos geralmente começam da mesma maneira que os que qualquer consultoria, de três letrinhas ou três pessoas, enfrenta. O diferencial que faz ser um lugar interessante para se trabalhar é o que acontece durante o projeto.

O que segue neste post é uma amarrado de impressões pessoais sobre os últimos doze meses, tanto sobre a Austrália quanto o que sei de outros escritórios. Se ele não for coeso ou fácil de ler eu peço desculpas mas encare como um braindump.

Os projetos para bancos e empresas do mercado financeiro em geral continuam bem parecidos. Em 2007 houve uma euforia em torno da bolha econômica e muitos projetos megalomaníacos –e, por conseqüência, extremamente interessantes do ponto de vista técnico- apareceram mas a crise os tirou do baralho nos tempos recentes. Os bancos estão gastando menos e buscando fazer mais dinheiro reutilizando a estrutura existente. A maioria dos projetos que eu tenho conhecimento dentro de bancos é para estender uma determinada oferta para novos clientes ou é para migrar de uma plataforma legada para algo menos dispendioso.

O interessante sobre o “legado dispendioso”, dentro e fora de bancos, é que muitas vezes ele se trata de coisinhas como WebSphere, Aqualogic, Biztalk, Tibco e produtos parecidos. Apos gastar rios de dinheiro implantando estes e não ver nenhum centavo de retorno real muitos dos grandes estão migrando para plataformas mais eficientes, quase sempre baseadas em software livre. Hoje em dia são comuns projetos de migração de Websphere para Jetty ou de BizTalk para serviços RESTful usando IIS, JSON e ASP.Net MVC, por exemplo.

Na parte de aplicações para Internet, onde geralmente eu me envolvo mais, as coisas também têm mudado bastante. Basicamente os projetos têm se dividido em startups e legado. As startups aparecem com um problema e algum montante de dinheiro. A plataforma mais utilizada para atender estes cenários é Ruby on Rails, geralmente fazendo deployment em algum serviço de Cloud Computing.

Cloud Computing é um tópico extremamente relevante tanto para ThoughtWorks quanto nos nossos clientes. Uma das coisas interessantes que fizemos no início do ano foi trabalhar junto com o Google no lançamento da AppEngine em Java (e outras linguagens).

As empresas com legado de Internet são sempre interessantes. Geralmente elas são algum grande prestador de serviço na área de mídia e possuem um ou mais websites antigos que têm aquela arquitetura manjada de rodar em um Weblogic ou Tomcat com um Apache de front-end. O problema é que hoje em dia o numero de usuários é muito superior e a velocidade com que funcionalidades têm que ser adicionadas e alteradas é muito maior. Após entender que os Googles e Facebooks da vida não usam Java EE e não pagam licença para a IBM as empresas estão desesperadas para atingir o mesmo nível de eficiência.

O que temos feito nesta área é utilizar a já citada Cloud Computing para realizar tarefas que não precisam ser executadas dentro do firewall (de crawling até rodar teste de carga), refatorar aplicações grandes para atingir escalabilidade horizontal e simplificar processos de deployment e gerenciamento de recursos.

Na área mais de programação em si as coisas não têm sido lá muito excitantes. As plataformas em específico não têm nenhuma novidade marcante mas a programação poliglota é uma realidade. Até hoje todos os projetos que tive alguma participação dentro da ThoughtWorks utilizavam mais de uma linguagem de programação (já descontando Bash e JavaScript).

Uma surpresa agradável foi a que tive no meu projeto atual, em que voltei a programar em .Net após 3 anos afastado. A maioria das coisas que eu realmente não gostava sobre C# e seu ecossistema foram removidos (exceto Windows e Visual Studio, duas peças que eu considero de qualidade inferior). A Microsoft continua enfiando frameworks e ferramentas terríveis pela guela dos seus clientes (MSBuild? TFS? WCF? WTF?!?) mas no geral as coisas estão bem melhores.

Em termos de livros sobre programação eu tenho me focado quase que exclusivamente nos conceitos presentes em linguagens e paradigmas de programação. Esta é a lista de livros relacionados que eu li desde que cheguei aqui:



Esta é a fila dos que faltam:


(fora os que ainda estão no meu carrinho de compras na Amazon. Livro na Austrália é ridiculamente caro)

Na parte de gerenciamento de projetos e metodologias as coisas estão engraçadas. Tem horas que a euforia anima, tem hora que dá náusea. Eu acho que o Bellware resumiu muito bem:

early agile adopters were looking for a way to do things better. later adopters are just trying to do agile, thus the failures

Eu vim para a ThoughtWorks para ver como é que quem introduz métodos ágeis há anos trabalha. Nos últimos meses eu trabalhei com pessoas que fazem isto há mais de dez anos e em empresas que adotaram agile antes de eu saber que ele existia. O que eu aprendi neste período inicial é exatamente o descrito acima: quando seu objetivo é ser ágil você falha, quando seu objetivo é sempre melhorar você tem chances de sucesso.

Todos os projetos que participei foram bem sucedidos? Depende de para quem você pergunta. Mesmo os clientes mais difíceis que tive acabaram ficando satisfeitos no final mas muitos projetos que participei (e o número de projetos é bem maior que o número de clientes) foram executados de uma maneira que o time não ficou satisfeito. Eu acho que neste caso é perspectiva. Como a maioria dos projetos são um fracasso colossal basta ter algum nível de sucesso que o projeto vira referência. O time, em compensação, tem um critério de sucesso muito mais alto e não considera o projeto como bem-sucedido.

É claro que no fim das contas o que vale mais é a opinião do cliente –tanto porque o problema dele foi solucionado bem como porque é ele quem paga a conta no final- mas eu já vi diversos problemas decorrentes deste tipo de coisa. De builds que começaram em 10 minutos e terminaram em duas horas de duração até um time que perde 50% do seu tempo corrigindo defeitos por falta de uma suíte de testes decente. Os problemas podem não ser grandes para aquele projeto em específico mas não prestar atenção há eles é mortal em médio prazo.

Minha conclusão é que a indústria está num estado melhor do que há alguns anos atrás. Tecnicamente estamos entrando em uma espécie de renascimento e isso promete render muito material para posts aqui. Em termos de gerencia de projetos e processos as pessoas estão finalmente se convencendo que tudo tem limite, até ineficiência.

Cartinha do Leitor

Saturday, March 14th, 2009

Eu basicamente tenho postado “conteúdo original” no meu blog em inglês. Não acho que isso vá mudar tão cedo, então preciso pensar melhor o foco do blog em português. Eu tenho muito interesse em mantêr este blog mas é difícil dividir conteúdo que cai melhor aqui e que cai melhor lá. As vezes é bem óbvio, especialmente quando eu comento sobre o mercado nacional, mas nem sempre.

Então estou pensando em focar mais em posts do tipo “Pergunte ao Calçado”. Eu recebo muitos e-mail com algumas dúvidas bem interessantes e já até publiquei alguns aqui. Eu sei que ultimamente tenho sido uma lesma respondendo meus e-mails mas se você mandar uma mensagem com tópico “Pergunte ao Calçado” meu filtro do gmail vai colocá-lo em uma lista de prioridade mais alta. Não garanto que vá responder e/ou que vá vir a ser publicado aqui mas pelo menos é uma chance bem maior que mandar um email com subject ‘Dúvida’.

Vamos ver se dá certo.

Domain-Driven Design & Agile: Fechando Malas

Wednesday, October 8th, 2008

Como falei algumas dezenas de vezes estou no fim de um projeto, na verdade na minha última semana neste instante. Foi um projeto muito interessante onde pudemos aplicar diversas técnicas como Domain-Specific Languages para testes e promoção de testes de aceitação. Também foi o primeiro projeto Java sem container que participei desde 2006, apenas PicoContainer, Hibernate, JMX e um cliente JMS -sem mesmo interface de usuário.

Outro ponto interessante sobre este projeto é que foi uma reescrita de um sistema com o qual estive envolvido antes. O cliente está passando por um programa que compreende diversos projetos e muitas fases. Há alguns meses nós fomos chamados para entregar, em algumas poucas semanas, uma versão deste sistema. Na nova fase do projeto eles resolveram investir mais na qualidade deste e tivemos uns bons 3 meses para reescrever tudo. Não só o sistema foi completamente reescrito bem como teve um time diferente (no anterior erámos eu e um colega ThoughtWorker, no atual somos 5 pares entre TWers, empregados do cliente e outros terceirizados).

O problema agora é a pressa. Não, o projeto não está com pressa, nossa entrega é em uma semana e faltam poucos cartões na parede. Eu que estou. Estou saindo deste projeto com muita coisa que eu queria fazer ainda meio-acabada e nesta última semana estou me dedicando basicamente a criar tracing bullets para o desenvolvimento futuro já que quem toma conta do sistema a partir da entrega de 15/10 é o cliente. Não é fácil com tão pouco tempo.

E esta lenga-lenga foi um mea-culpa para maiores informações sobre minha viagem ao Brasil. O press-release ficou assim:

Dia 23 e 24 de outubro ocorre em São Paulo o primeiro grande evento de Agile do Brasil:
http://www.falandoEmAgile.com.br/

Ouça as histórias de empresas que tem obtido sucesso com Scrum, entenda como estas práticas podem ser implantadas em ambientes tradicionais de projetos, veja o que a indústria tem falado e feito com Agile e descubra quais serão os próximos passos a serem dados nesse mundo. Conta com o palestrante internacional David Anderson, reconhecido líder na comunidade Ágil e autor do livro “Agile Management for Software Engineering”, e com o primeiro Certified Scrum Trainer da Scrum Alliance da América Latina, Alexandre Magno. De tópicos de Scrum e CMMI até estudos de caso com Agile na Austália, Inglaterra, Estados Unidos e Brasil.

Ocorrerão mais outros eventos próximos a essas datas:

O Zen of Agile, nos dias 21 e 22, um workshop com David Anderson:
http://www.heptagon.com.br/ws-zen-agile-mgmt

O Certified ScrumMaster, dias 27 e 28 de outubro:
http://www.caelum.com.br/treinamentos/csm-certified-scrum-master/

E por três vezes Phillip Calçado, conhecido aqui no GUJ, ministrará um workshop de Domain Driven Design de 8 horas, dia 21 de outubro no Rio de Janeiro, e dias 27 e 28 em São Paulo:
http://www.caelum.com.br/treinamentos/ws-46-domain-driven-design/
http://blog.fragmental.com.br/2008/09/01/brazilian…em-agile-domain-driven-design/

Está sendo divertido montar este workshop. É algo estranho porque é maior que uma palestra e menor que um curso -ao mesmo tempo é tempo demais e tempo de menos. Eu quero começar desmistificando alguns conceitos sobre objetos, trabalhando a idéia das decisões em três níveis e só depois entrar em Domain-Driven Design. É impressionante como fica mais claro falar sobre DDD depois de quebrar mitos, numa palestra nunca se tem tempo de fazer isso.

Como falei antes, para maiores informações basta ligar para a Caelum do Rio ou São Paulo.

E com a confirmação das datas eu muito provavelmente vou estar também no último dia do Rails Summit.

Rastreabilidade em User Stories

Friday, July 18th, 2008

Pergunta na XP-Rio:

Me ajudem no seguinte, no processo unificado, espera-se que todos os casos de uso gerem algum tipo de artefato dentro do projeto. Na verdade, com os casos de uso espera-se chegar em classes que juntas formarão o sistema. Dentro da metodologia existe artefatos que quando feitos, permitem mapear todos os artefatos gerados a partir de um caso de uso. A matriz de rastreabilidade.

Gostaria de saber como o XP permite chegar as classes (código) a partir das User Stories. Por exemplo, dado uma User Stories, quais são as classes geradas para atender essa User Stories?

O XP permite isso? Como é feito?

Provavelmente a primeira coisa a se perguntar é: por que eu precisaria deste dados? Alguns modelos de processo como CMMI definem rastreabilidade, que geralmente é definida nesta linha:

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.)

- Gotel O.C.Z and Finklestein A.C.W (tirado da Wikipedia)

A necessidade parece justa e real, é preciso saber quais partes do software são afetadas por mudanças no negocio e vice-versa. O grande problema desta métrica é que transformações de modelo não são mais tão drásticas há algumas décadas. Ao utilizar qualquer tecnologia relativamente comum (Java, Ruby, .Net, Python, JavaScript…) não existe motivo técnico para que o software não modele o negocio em uma relação próxima de 1-para-1, desta forma saber qual parte de um código realiza qual tarefa torna-se bem simples.

Outro problema é que eu nunca vi um artefato de rastreabilidade, seja qual for, que não ficasse defasado. Se você abraça uma metodologia ágil sabe que refactoring faz parte da vida.

Mesmo com todos os problemas que esta métrica possui eu entendo que existem casos onde seu uso se faz necessário –especialmente por equipes tentando introduzir agilidade em ambientes tradicionais. Supondo que exista uma necessidade justificável para algum controle deste tipo, metodologias ágeis em geral possuem um mecanismo muito mais eficiente que documentos ou mesmos sistemas: testes.

Toda história, todo cartão, deve ter um critério de aceite. O critério de aceite traz o que o cliente considera ser o mínimo para que a história seja considerada concluída. Por exemplo:

História: Como administrador eu quero criar um novo grupo para que possa aplicar permissões à diversos usuários de uma só vez.
Critérios de Aceite:

  • O novo grupo criado deve possuir o usuário que o criou como seu administrador
  • O novo grupo não deve conter outros membros
  • O novo grupo não deve ser visível na listagem de grupos

Cada um destes critérios via um teste unitário e/ou funcional que é executado como parte da integração contínua. Para saber exatamente quais classes e códigos são afetados por cada um deles é simples: use uma ferramenta de test coverage como o Emma e execute apenas os testes de aceitação para aquele cartão. A ferramenta irá gerar relatórios como estes:

[class, %]	[method, %]	[block, %]	[line, %]	[name]
25%  (1/4)!	25%  (3/12)!	40%  (3012/7446)!	25%  (3/12)!	com.sun.tools.javac.v8.resources
94%  (16/17)!	49%  (41/83)!	48%  (1111/2292)!	45%  (201.1/450)!	com.sun.tools.javac.v8
88%  (45/51)!	61%  (242/397)!	54%  (3070/5729)!	52%  (809.6/1563)!	com.sun.tools.javac.v8.tree

Classes que possuem alguma cobertura foram afetadas pelo teste, logo são parte da execução daquela história. Não é difícil escrever um script que –talvez como parte do build- processe estes relatórios e gere o artefato de rastreabilidade que seu processo te obrigar a fazer. Melhor ainda: este artefato nunca estará desatualizado.

Só não se esqueça que melhoria contínua é um conceito importante. Se o artefato de rastreabilidade é algo tão ineficiente a obrigação de um desenvolvedor que perceba isto é mostrar para sua organização que o valor desta pratica é nulo. Não se acomode.

Nem só de troca de mensagens vivem os objetos

Sunday, May 25th, 2008

Percebi que boa parte das dúvidas quanto ao meu post sobre como objetos não possuem atributos se deve ao fato das pessoas não terem geralmente um conhecimento real sobre o que é troca de mensagens.

Perfeitamente compreensível. Na maior parte dos livros e faculdades as pessoas aprendem que Orientação a Objetos é sobre como utilizar classes e sobre como as funções são chamadas de métodos. Por algum motivo esquecido nas areias do tempo decidiu-se que chamar o método em uma classe era passar uma mensagem e por isso algumas pessoas notoriamente pedantes usam este termo ao invés de dizer apenas “chama a função”.

Bem, os conceitos no parágrafo acima estão errados. Orientação a Objetos não é sobre classes e sim sobre…er… objetos. Você pode ter OO sem ter classes, como JavaScript e Io e pode ter também OO sem mensagens.

Troca de mensagens é um conceito utilizado em diversas áreas, não apenas Orientação a Objetos. Você pode ter um Sistema Operacional baseado neste conceito -como o MINIX por exemplo- ou criar uma arquitetura de computação distribuída como SOAP.

O que distingue a passagem de mensagens é o fato de que o recipiente da mensagem, seja um objeto, um serviço ou um processo, é quem decide o que é feito em decorrência de sua invocação.

Para tentar içar um pouco mais claro eu criei um meta-modelo bem bobinho em Java. Este representa um sistema Orientado a Objetos com classes e passagem de mensagens. O código abaixo mostra como declarar uma Classe calculadora e enviar uma mensagem dizendo para que esta multiplique números.

BlocoDeCodigo bloco = new BlocoDeCodigoImpl<Integer, Integer, Integer>(){
			public Integer executar(Integer a, Integer b){
				return a * b;
			}
		};

		Classe classeCalculadora = novaClasse("Calculadora");
		classeCalculadora.declaraMensagem("multiplique", bloco);

		Instancia calculadora = instanciar("Calculadora");

		assertEquals(8, calculadora.enviaMensagem("multiplique", 2, 4));

Note os passos realizados. Primeiro criamos um bloco de código, uma função. Depois dizemos ao sistema que existe uma classe chamada calculadora. Logo apos registramos o fato de que calculadora responde a uma mensagem executando o bloco que havíamos declarado.

Em termos de semântica, este código é mais ou menos equivalente a este:

public class Calculadora{
 public Integer multiplicar(Integer a, Integer b){
  return a * b;
}
}

Depois nós instanciamos a classe e passamos uma mensagem para ela, o que seria equivalente a:

Calculadora calc = new Calculadora();
calc.multiplicar(2,4);

As classes relevantes:

public class Ambiente {
	static Map<String, Classe> classesDeclaradas = new HashMap<String, Classe>();

	static Classe novaClasse(String nomeDaClasse) {
		ClasseImpl classe = new ClasseImpl(nomeDaClasse);
		classesDeclaradas.put(nomeDaClasse, classe);
		return classe;
	}

	static Instancia instanciar(String nomeDaClasse) {
		return new Instancia(classesDeclaradas.get(nomeDaClasse));
	}
}

public class ClasseImpl implements Classe {

	private final String nome;

	private Map<String, BlocoDeCodigo> mensagens = new HashMap<String, BlocoDeCodigo>();

	public ClasseImpl(String nome) {
		this.nome = nome;
	}

	public void declaraMensagem(String nomeDaMensagem, BlocoDeCodigo blocoASerExecutado) {
		mensagens.put(nomeDaMensagem, blocoASerExecutado);
	}

	public String nome() {
		return nome;
	}

	public boolean respondeA(String nomeDaMensagem) {
		return mensagens.containsKey(nomeDaMensagem);
	}

	public BlocoDeCodigo codigoParaMensagem(String nomeDaMensagem) {
		return mensagens.get(nomeDaMensagem);
	}

}

public class Instancia {
	private final Classe minhaClasse;

	public Instancia(Classe classe) {
		this.minhaClasse = classe;
	}

	public Object enviaMensagem(String mensagem, Object... args) {
		Object primeiro = args.length > 0 ? args[0] : null;
		Object segundo = args.length > 1 ? args[1] : null;

		return minhaClasse.codigoParaMensagem(mensagem).executar(primeiro,
				segundo);
	}

	public Classe classe() {
		return minhaClasse;
	}

}

Esse meta-modelo é baseado em troca de mensagens. A classe Calculadora não recebe código a ser executado ela apenas recebe o nome de uma mensagem e parâmetros. Imagine que eu registre o mesmo bloco de código para várias mensagens, ou que eu use recursos de AOP e intercepte a execução do bloco. Nada disso é relevante para quem invoca a mensagem, ele apenas a envia e o que acontece em decorrência disso é responsabilidade do receptor.

Como quase todas as linguagens atuam desta forma pode ser difícil entender o conceito já que nunca se viu nada diferente. Vamos então implementar outro meta-modelo que não usa troca de mensagens mas sim uma outra forma chamada Data-Directed.

Nesta forma de invocar operações em objetos –que, como a anterior não é específica de OO- quem decide qual função será aplicada é o ambiente de execução, o runtime. Quando você invoca uma operação o ambiente vai procurar dentre os métodos registrados qual é o aplicável para aquele objeto e vai executar o método nele. Common Lisp utiliza este recurso de maneira tão poderosa em suas Generic Functions que praticamente elimina a necessidade de coisas como proxies e AOP.

Nosso meta-modelo para Data-Directed é executado dessa forma:

BlocoDeCodigo bloco = new BlocoDeCodigoImpl<Integer, Integer, Integer>(){
			public Integer executar(Instancia instancia, Integer a, Integer b) {
				return a * b;
			}
		};

		Classe classeCalculadora = novaClasse("Calculadora");
		registrarMetodo("multiplique", classeCalculadora, bloco);

		Instancia calculadora = instanciar("Calculadora");

		assertEquals(8, executarMetodo("multiplique", calculadora, 2, 4));

Repare que agora o bloco de código recebe como seu primeiro argumento uma referência para a instancia a qual se aplica (se você já usou java.lang.Method sabe que isso não é incomum quando se desce ao nível de implementação de linguagem). Caso nosso exemplo fosse minimamente usável seria desta forma que o bloco obteria acesso ao objeto em si.

Logo depois criamos a classe como antes mas ao invés de registrar uma mensagem na classe nós registramos um método no ambiente, dizendo que o método se aplica àquela classe. A invocação em si é bem parecida com a anterior.

Na implementação a única classe mais interessante é o Ambiente, que agora é bem mais esperto:

public class Ambiente {
	static Map<String, Classe> classesDeclaradas = new HashMap<String, Classe>();
	static Map<String, Map<Classe, BlocoDeCodigo>> metodos = new HashMap<String, Map<Classe, BlocoDeCodigo>>();

	static Classe novaClasse(String nomeDaClasse) {
		ClasseImpl classe = new ClasseImpl(nomeDaClasse);
		classesDeclaradas.put(nomeDaClasse, classe);
		return classe;
	}

	static Instancia instanciar(String nomeDaClasse) {
		return new Instancia(classesDeclaradas.get(nomeDaClasse));
	}

	static void registrarMetodo(String nomeDoMetodo, Classe tipoEmQueSeAplica,
			BlocoDeCodigo bloco) {
		metodo(nomeDoMetodo).put(tipoEmQueSeAplica, bloco);
	}

	static Object executarMetodo(String nomeDoMetodo, Instancia instancia,
			Object... args) {
		Map<Classe, BlocoDeCodigo> tiposAceitaveis = metodo(nomeDoMetodo);
		if (!tiposAceitaveis.containsKey(instancia.classe()))
			throw new RuntimeException("Metodo inexistente");

		BlocoDeCodigo bloco = tiposAceitaveis.get(instancia.classe());

		Object primeiro = args.length > 0 ? args[0] : null;
		Object segundo = args.length > 1 ? args[1] : null;

		return bloco.executar(instancia, primeiro, segundo);
	}

	private static Map<Classe, BlocoDeCodigo> metodo(String nomeDoMetodo) {
		if (!metodos.containsKey(nomeDoMetodo))
			metodos.put(nomeDoMetodo, new HashMap<Classe, BlocoDeCodigo>());

		return metodos.get(nomeDoMetodo);
	}

}

Agora não apenas registra as classes mas também os métodos que são aplicáveis à cada classe e faz a invocação dos métodos em si.

Estes exemplos são bem educacionais, sem muita aplicação pratica, mas como já vimos em posts passados o fato de se usar message-passing ou Data-Directed ou properties, ou componentes ou qualquer outra coisa interfere no modo como devemos projetar nosso software. Existe uma vasta literatura sobre este tema mas ainda assim é uma das coisas mais desconhecidas pelo programador profissional.

Australian Architecture Forum 2008

Thursday, May 1st, 2008

Falando em coisas agitadas, fui convidado para palestrar no Australian Architecture Forum 2008. O título é “Lightweight SOA Through Web Widgets” e falar de SOA com REST num evento onde vai estar presente o impagável Jim Webber é algo bem diferente.

Como meu Google Analytics diz que ese blog é acessado por pessoas aqui na Austrália fica o convite.