Archive for the ‘guj’ Category

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.

Falando em Java 2009

Saturday, March 14th, 2009

Tem um tempinho a Caelum anunciou a terceira edição do Falando em Java, que definitivamente para mim é o melhor evento nacional sobre o tema desde o ConexãoJava.

Pelo que eu entendi será realizado no mesmo espaço que o Falando em Agile, um excelente centro de convenções com restaurantes próximos (especialmente se você gosta de sushi) e bema cessível mesmo para os que, como eu, não conhecem a cidade de São Paulo.

Em 2007 eu tive o prazer de apresentar na primeira edição do evento, com a infame “A Web 2.0 somos Nozes”:

Infelizmente este ano não vou poder participar. Apesar da minha mudança recente para Sydney estou trabalhando num projeto em melbourne (sim, eu vôo segunda de manhã para Melbourne e volto sexta de noite para Sydney, toda semana!) e por enquanto não posso ter planos de viajar em médio prazo.

Interessante que olhando agora a apresentação do FeJ2007 eu vejo que mais uma vez eu estou trabalhando numa grande empresa de mídia tradicional tentando fazê-los entender o que é Web 2.0 e como não ficar atrás. Estamos construindo um agregador de blogs utilizando coisa bem legais como Atom Publishing Protocol e microformatos, além de novamente uma estrutura de widgets.

Mas voltando ao evento, pela bagatela de R$ 95,00 você não vai perder essa, vai?

Brazilian Tour 2008: Falando em Agile, Domain-Driven Design

Monday, September 1st, 2008

Outubro vai ser um mês bem interessante. Vou entregar um dos meus projetos mais importantes até agora (pelo menos é o que nossas previsões dizem) e vou passar 15 dias entre férias e eventos no Brasil.

O motivo principal é para realizar uma apresentação no Falando em Agile 2008, mais um evento da Caelum. As inscrições estão abertas e inscrevendo-se com antecedência você consegue desconto.

Minha palestra vai ser sobre um tema que venho desenvolvendo há algum tempo: como adoções ágeis que tinham tudo para dar certo afundam. Antes de entrar para a ThoughtWorks eu já tinha vivido esta situação pelo menos duas vezes, nestes nove meses trabalhando numa grande consultoria especializada eu já vi umas três. Todas tinham um grupo de sintomas bem parecidos o quais estou tentando estruturar. Não é lá muito fácil mas acho que o resultado tende a ser bom. Se você acha que Vovô viu a uva, a web somos nozes, arquitetura BOLOVO e amigos foram piadas infames e de mau-gosto mal podem esperar pela temática desta apresentação…

Uma das coisas mais interessantes sobre o FalandoEmAgile 2008 para mim vai ser a presença do Danilo Bardusco na grade. O Danilo foi meu gerente na Globo.com antes de assumir tudo-menos-webmedia, quando passei a responder diretamente ao Antônio Carlos. Naquele momento a empresa viva diversas histórias tristes com métodos baseados em Waterfall, micro-management e consultorias CMMI 5; apesar dele não acreditar que aquilo ia dar certo no início foi sua perseverança e abertura à inovação que possibilitou aquele trabalho inicial que hoje, graças ao trabalho de todos, é referencia. O grande defeito dele é aquela mania infeliz de usar Vi quando todo mundo sabe que emacs é o único editor de texto que deveria ser utilizado. Mas eu perdôo.

Como falei, são 15 dias no Brasil. Eu ainda não sei as datas do que vou fazer mas devo ter algumas outras apresentações de palestras no Rio (certamente no RioJUG) e em São Paulo.

Como eu já estava vindo para o Brasil, acabei fechando com a Caelum uma série de oficinas em Domain-Driven Design. A idéia é cobrir os principais aspectos desta filosofia de design de uma maneira descontraída mas substancial. O primeiro post que menciona Domain-Driven Design neste blog é de 2005, e foi importado do meu antigo blog no blogger.com. Nesta época quase ninguém havia ouvido falar do conceito. Hoje ainda é algo relativamente obscuro mas um pouco mais popular. Claro que com a popularidade vem os problemas. Muita gente no GUJ, em blogs e outros fóruns está simplesmente associando Domain-Driven Design com um bom design Orientado a Objetos, ou pior ainda: com qualquer design OO.

Ao contrario do recente mito popular, Domain-Driven Design não é “voltar para Orientação a Objetos”. Orientação a Objetos foi criada como uma maneira de gerenciar dependências e criar unidades coesas e atômicas de código, não necessariamente uma forma de modelar uma Camada de Negócios. O que Domain-Driven-Design traz de volta é a possibilidade de utilizar as vantagens da Orientação a Objetos para criamos um modelo que reflita o mundo real de maneira mais íntima. Você não precisa sequer de objetos para aplicar o coração de Domain-Driven Design, ou mesmo seus Patterns.

A parte do “substancial” que falei acima é exatamente esta: não misturar Orientação a Objetos com Domain-Driven Design e sim trabalhar a relação entre eles. A parte “descontraída” é na forma de passar este conhecimento. Após alguns anos ministrando treinamentos eu não tenho a fórmula ideal para passar este tipo de conteúdo (altamente abstrato e que requer conhecimento posterior) mas eu já aprendi por tentativa e erro diversas formas em que isso não dá certo –pelo menos não comigo. Duas delas são: aulas expositivas e laboratórios. Se você não entende porque aulas expositivas não servem para este tipo de coisa pense sobre todo o conteúdo que é quase que literalmente jogado em cima de alguém numa faculdade e quanto dele é entendido (e entender não é tirar 10 na prova). O problema de laboratórios é que sempre perde-se tempo com a máquina, ou a linguagem (este não é um workshop Java ou Ruby ou C#, é um workshop sobre objetos).

Eu não tenho as datas nem preços (já encheu o saco da Caelum hoje?) mas vamos ter sessões em outubro no Rio e São Paulo, a preços acessíveis.

J2EE Spider no InfoQ

Thursday, March 13th, 2008

Saiu no InfoQ uma matéria sobre o J2EE Spider, do Bruno Braga. Eu recebi um email do Bruno há algum tempo me convidando para fazer um review da nova versão da ferramenta, e dando ênfase no fato que não é um gerador abrace-o-mundo como vemos por aí.

Ainda não tive tempo de fazer o teste da ferramenta mas já deixo aqui os parabéns pela notoriedade.

Você Pergunta: RAD

Thursday, January 24th, 2008

Uma pessoa me escreveu um email sobre o tópico anterior. Novamente não vou citar nomes porque não pedi permissão (e não tenho motivos para expôr esta):

Shoes, beleza cara?

Então, lendo sobre a discussão sobre o Maker eu cheguei no seu blog e li sobre RAD.
Aquela ferramenta no NetBeansLixo pra fazer GUIs é um RAD? Ele desenvolve parte de um software, eu sei, não é um modelo de processo de desenvolvimento, né??

Enfim, acredito que existam mais algumas por aí como Maker e queria saber da sua opinião: todas essas ferramentas são RADs e todas elas cometem gafes? Onde quero chegar é na pergunta: Hoje em dia, SEMPRE teremos um desenvolvedor por trás da solução?

É que eu sou totalmente contra essas ferramentas de gerar códigos automáticos… não confio muito nessas coisas… prefiro eu mesmo fazer os códigos, mas tenho a dúvida: estou muito antiquado (no sentido de muito atrasado e não acompanhando as tecnologias que estão evoluindo hoje) ou estou no caminho correto?

Bom, se você respondeu que sim na primeira pergunta (do NetBeans sobre GUIs), a principal desvantagem das ferramentas RAD (se é isso que aquele Lixo é) é a manutenção e evolução, certo? Uma vez, fazendo um trabalho pra faculdade, tive que usar aquele NetBeans. Quando fui usar Refactoring… nossa cara, que coisa mais chata… tive que refazer praticamente toda a interface gráfica.

Abraço.

Apesar de usar, eu odeio o termo RAD. Ele significa um grupo enorme de coisas e ao mesmo tempo não significa nada. O livro Software Development: Building Reliable Systems define RAD:

For the last ten years, many software projects have incorporated the use of “Rapid Application Development” methodologies in an effort to decrease development times. RAD, as it is generally referred to, incorporates an umbrella of methodologies based on spiral, iterative development technologies. RAD techniques range from the simple use of GUI development tools to quickly build prototypes, to processes incorporating complete, cross-functional business analysis. [...]

Então vou considerar que você quer dizer por RAD “ferramentas geradoras de código” do contrario este post nunca vai acabar. Sim, o Matisse do Netbeans é uma ferramenta geradora de código.

Ferramentas geradoras, em geral, são úteis quando não querem dominar o mundo. Eu adoro quando o Hibernate ou o Rails gera meu DDL SQL e eu não tenho que escrever CREATE TABLE. Eu adoro quando o Eclipse gera meus getters e setters e coisa do tipo. O problema é que esses geradores não costumam sobreviver num projeto de verdade.

O grande problema do gerador de código padrão, como o citado, é que ele possui diversos vazamentos de abstração. O Joel Spolsky fala especificamente sobre geradores:

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.

Como pode-se perceber pelas discussões citadas o mercado destas ferramentas é… complicado. Um desenvolvedor que entende como a plataforma funciona (Java EE, no caso) dificilmente se encantaria pela ferramenta. Ele pode utilizar algo como um Spring IDE para gerar arquivos de configuração mas sabe que isso não é tão simples assim.

Os programadores mais recentes na plataforma Java podem não ter consciência disso mas uma ferramenta chamada xdoclet era muito usada quando sofríamos diariamente com EJBs 2.1. O que o xdoclet faz é gerar código, ele gerava todo o mapeamento do EJB (uns 3 arquivos XML diferentes, pelo menos) a partir de anotações JavaDoc (não existia Java 5 naquela época). O xdoclet era a salvação da lavoura, conseguia abstrair muitos problemas mas.. não era perfeito, nem pretendia.

Eu já trabalhei em projeto onde 50% do código era gerado pelo xdoclet e do restante ele não dava conta. A ferramenta não possui o tal do round-tripping então não dava para misturar código gerado com modificado. A solução foi optar por uma arquitetura que isolava as duas partes em módulos diferentes e só conseguimos chegar até ela porque –como disse o Joel- sabíamos como a ferramenta funcionada. Essa é uma ferramenta de automação, não de “geração automática de sistema”. Ela automatiza o trabalho que você teria, não te livra do fato de conhecer o que… bem… é sua profissão.

Acho que o Matisse se enquadra neste tipo.

O problema é que essas ferramentas –e seus persuasivos vendedores- dizem que irão abstrair todo o desenvolvimento. Para os cenários ideais elas podem fazer todo o prometido mas não houve até hoje uma ferramenta que conseguisse real sucesso fora dos casos mais simples e isso porque não é assim que construímos sistemas hoje. Nossos sistemas são uma salada de linguagens, conceitos, mapeamentos e configurações que uma ferramenta deste tipo não consegue acompanhar.

O que geralmente elas fazem é te prender à uma ou algumas arquiteturas genéricas que servem razoavelmente para alguns casos -geralmente sitezinhos CRUD de intranet- mas não para todos ou sequer para a maioria. Como arquitetura não é commodity não se pode simplesmente aplicar a mesma estrutura em todos os cenários.

Apos algum tempo em TI você começa a entender que o dia-a-dia desse mercado é um grande “mais do mesmo”. Você sempre está criando as mesmas coisas. Da última vez que contei eu já tinha criado uns sete gerenciadores de conteúdo web. Dá para utilizar a mesma arquitetura em todos? Não. Uns eram simples formulários, outros se integravam com back-ends complicados, outros era assíncronos, outros tinham integração com legado… cada um tinha uma história. Se há oito anos atrás eu comprasse uma ferramenta dessas e a tivesse aplicado nestes projetos eu teria que fazer personalização (i.e. sair do maravilhoso mundo do fluxograma) a cada projeto.

Mas eu estou falando de desenvolvimento de software de um tipo, não do mercado todo. Quando estive na faculdade pela última vez (antes da segunda fuga) estudei com uma pessoa de 43 anos que desde os anos 80 vive fazendo software em coisas como CLIPPER para lojinhas e boutiques. Ele não ganha mal. Pelo que entendo dos softwares deste tipo (já trabalhei neste ramo) a arquitetura é quase sempre a mesma. Talvez ele se favorecesse de algo assim nos seus negócios, apesar de que eu ainda acharia um risco desnecessário.

Então sim, hoje precisamos de desenvolvedores para projetar um sistema. Desenvolver sua arquitetura, seu design e verificar para que tudo seja eito da maneira mais adequada para o projeto (que nem sempre é a técnica mais adequada). Mas e o futuro?

O futuro prevê o uso de ferramentas de um nível mais alto, mas de maneira diferente. O ponto crucial é que essas ferramentas não são geradores de código Java (ou C#, ou Ruby ou o que for), elas mudam a visão sobre o código. Ferramentas como Domain-Specific Languages aumentam o nível da linguagem não tornando-a mais abstrata apenas mas sim levando para perto do negócio. Ferramentas de visualização criam pontos de vista diferenciado sobre o mesmo artefato, dependendo de com que olhos se enxerga.

Tudo indica que para desenvolver softwares no futuro o desenvolvedor não terá o mesmo papel que tem hoje. Ao invés de criar o código do sistema em si iremos criar as ferramentas que dão suporte à criação de sistemas pelos usuários.

Seja qual for o futuro ele não é sobre gerar código. Isso nós já fazemos à décadas e serve apenas como quebra-galho para nos livrar da complexidade que nós mesmo criamos.

Expressividade no Código

Friday, December 28th, 2007

Um post no GUJ mais uma vez rende uma resposta maior do que se supunha. A thread em si é bastante útil mas existe muito ruído então vou tentar sumarizar:

Vocês pegam códigos que te faz passar horas e horas tentando entender o que está sendo feito? Valores que você nem imagina de onde estão vindo?

Eu sou muito ruim ou isso é normal?

E logo surge alguém sugerindo que deveria haver documentação. Existem casos onde documentação, seja JavaDoc, especificação funcional ou etc. é fundamental mas neste caso é diferente. JavaDoc, especificação textual e etc. devem ser uma fonte importante quando que está interessado nessa informação não vai lero código, é como reutilizar uma biblioteca ou um framework. Ninguém quer abrir o Spring para entender como utilizá-lo, precisamos de documentação para isso.

Um cenário completamente diferente é quando você recebe de presente um código já existente para dar manutenção. Neste caso o código tem que fazer sentido, tem que dizer algo. Tem que ser expressivo, mostrar suas intenções claramente.

NOTA: O trecho abaixo foi escrito direto no editor de texto, sem ajuda de compilador ou IDE. Por favor me corrijam.

Qualquer programador meia-boca sabe sua linguagem. Sabe o domínio dela. Veja o trecho abaixo:

abstract class A{
 public abstract int d(){
 }
}

class B extends A{

 int z= 0;
 int x=-1;

 public B(int z, int x){
  this.z=z;
  this.x=x;
 }

 public int d(){
   if(z==15) return x + x* 0.15;
   esle return x;
 }

}

Você entendeu muito bem, tenho certeza, que A é uma classe abstrata implementada por B. Que B tem um construtor que recebe dois inteiros, os armazena e usa numa computação simples com uma ramificação abaixo. Ótimo.

Imagine que você recebeu um email do seu usuário dizendo: “Precisamos fazer com que clientes do sexo feminino que comprem mais de R$1000,00 ganhem 10% de desconto.”. Tente implementar isso no código acima enquanto eu vou almoçar.

E aí, terminou? Sim, sim, claro que é impossível sem saber d que se trata. Então depois de procurar bastante você encontra no diretório onde fica a documentação do projeto um arquivo que pode te ajudar a entender. Após umas cinquenta páginas de diagramas de alto nível inúteis explicando tudo que acontece no container web você chega a uma descrição de algo como:

A classe A tem a lógica abstrata de uma venda. As vendas são sempre feitas de acordo com critérios específicos por isso existem classes que implementam vendas específicas. No momento (01/10/2003) só existe uma implementação, na classe B, que é a venda para uma pessoa física.

A primeira coisa que você pensa é: se desde 2003 ninguém precisou de outra implementação para que essa maldita classe abstrata? Mas ants de mexer no código precisamos entendê-lo, então vamos em frente.

O méodo e questão recebe três argumentos: a quantdade em reais vendida, o sexo da pessoa (segundo código vindo do mainframe na tabela ETXS32) e se a compra é casada ou não (um booleano).

De acordo com o caso de uso UC171 o sexo do comprador é utilizado para aplicar descontos.

TABELA ETXS32
15 -> masculino
22 -> feminino

Se a compra for casada o processamento é feito delegando para outra classe, mantendo o padrão Strategy, Composite e Adapter do Decorator. Note que o Chain of Responsibility do Bridge é usado com Visitors para passar as instâncias de Flyweight pelos Interpreters[...]

Após a sequência de buzzwords de padrões é bom parar. Acho que a informação necessária já está aí em cima e olha que não se passaram nem 4 horas de procura! Vamos lá: recebemos o valor, o sexo segundo um código numérico sem lóica que vêm de outro sistema. Também é passado um boolean.. cadê o boolean?

Procurando no histórico deste arquivo no CVS (poxa vida, eles ainda usam CVS!) você vê que no meio de 2005 alguém tirou o boolean de lá com um comentário ‘Removido compra casada. Ninguém usa isso e ninguém entende isso. Ninuém vai sentir falta’. Acho que a pessoa estava correta mas ela esqueceu que existem uns 300 documentos que precisam ser revistos porque todos fazem referência a esta tal venda casada, do caso de uso, diagrama de domínio até diagrama de deployment. Cada mudança simples implica em editar 300 documentos… provavelmente mais tempo atualizando a tal documentação que o código… dá pra culpar o desenvolvedor?

Bom, agora você entende o que o código faz ao menos. Ele está aplicando um desconto de 15% para homens, você não conseguiu achar isso no caso de uso mas se ninguém está reclamando em produção é porque deve ser assim mesmo. Amanhã (afinal, você perdeu o dia inteiro hoje na ‘documentação’ do sistema) você faz a mudança.

Novo dia e você está pronto para alterar este código. Hmm… alterar pode ser muito rápido e sujo ou devagar e bem feito. Como disse o Uncle Bob recentemente sujo nunca é rápido então você opta pelo caminho com mais qualidade (e mais ético).

Como desenvolvedores profissionais escrevem testes (e gerar você deve começar por aí. Você sabe muito pouco sobre este sistema e o teste vai te dar alguma garantia que a menos esta pequena parta que está mexendo vai continuar funcionando após suas modificações. Vamos lá:

class TestVenda extends TestCase{
 public void testDeveAplicarDescontoSeSexoDoCompradorForMasculino(){
  B vendaParaUmHomem = new B(15, 100);
  assertEquals("Valor final sofreu 15% de desconto", 85, vndaParaUmHomem.d());
 }

 public void testDeveNaoAplicarQualquerDescontoSeVendaNaoCaiEmNenhumaPromocao(){
  B vendaParaUmHomem = new B(9999, 1);
  assertEquals("Valor final intacto", 1, vndaParaUmHomem.d());
 }
}

Os testes executam. Agora vamos alterar um pouco esta classe, pensando no pobre coitado que for mexer nela após você. Vamos começar agregando nomes mais expressivos:

abstract class VendaAbstrata{
 public abstract int vender(){
 }
}

class Venda extends VendaAbstrata{
 static final int NAO_INFORMADO = -1;
 static final int MASCULINO = 15;
 static final int FEMININO = 22;

 int sexoDoComprador= NAO_INFORMADO;
 int valorDaCompra=-1;

 public B(int sexoDoComprador, int valorDaCompra){
  this.sexoDoComprador=sexoDoComprador;
  this.valorDaCompra=valorDaCompra;
 }

 public int vender(){
   if(sexoDoComprador==MASCULINO) return valorDaCompra - valorDaCompra* 0.15;
   esle return valorDaCompra;
 }

}

Já está bem melhor, não? Compare com a primeira versão do código Os testes passam? Então é hora de commitar (eu acho esse neologismo horrível mas alguém sugere algo melhor?).

Vamos para o segundo round: pequeno refactoring. Já é possível fazer a alteração neste código mas anda temos tempo para deixá-lo um pouquinho mais legível, mais claro, mais expressivo. Vamos alterar:

abstract class VendaAbstrata{
 public abstract int vender(){
 }
}

class Venda extends VendaAbstrata{
 static final int NAO_INFORMADO = -1;
 static final int MASCULINO = 15;
 static final int FEMININO = 22;

 int sexoDoComprador= NAO_INFORMADO;
 int valorDaCompra=-1;

 public B(int sexoDoComprador, int valorDaCompra){
  this.sexoDoComprador=sexoDoComprador;
  this.valorDaCompra=valorDaCompra;
 }

 public int vender(){
   int valorFinalDaCompra = aplicarDescontosSobreValorDaCompra();

   return valorFinalDaCompra;

 public int aplicarDescontosSobreValorDaCompra(){

  int valorComDesconto= valorDaCompra;

  if(sexoDoComprador==MASCULINO)
   valorComDesconto = descontarPorcentagem(15, valorDaCompra);

  return valorComDesconto;
 }

 public int descontarPorcentagem(int porcentagem, int valorOriginal){
  return valorOriginal * (porcentagem / 100.0);
 }

}

Agora que tal esta versão do código + teste unitário contra a versão antiga + trezentos documentos e especificações? A implementação da regra nova ficou fácil? Acho que sim, tanto que deixo como exercício ao leitor, bem como algumas dezenas de refactorings que vão deixar o código acima decente.

A resposta curta para a thread do GUJ é: geralmente o problema não é seu mas de quem escreveu o código.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

-Martin Fowler, “Refactoring: Improving the Design of Existing Code “

Programadores Profissionais Escrevem Testes, Ponto Final.

Wednesday, October 31st, 2007

O tópico já tem oito páginas. Acho que chega à 10. Por mais que minha mão coce para comentar lá eu não vou, simplesmente porque já tive problemas demais com o pessoal do Mentawai.

De qualquer forma sempre me preocupa a possibilidade de algum desenvolvedor ler o tópico e pensar “Poxa, se esses caras que fazem todos estes frameworks não usam testes por que eu vou usar?”.

Desenvolvedores profissionais escrevem testes. Simples assim.

Uma pessoa que não ganha milhões de dólares mas escreveu uma das obras mais clássicas deste ramo deixa bem claro em sua primeira aula que programar é gerenciar complexidade. Nós precisamos gerenciar complexidade o tempo todo, por isso criamos funções, objetos e tudo mais. Não adianta, mesmo Einstein teve que provar que suas fórmulas e execuções estavam corretas, que poderiam ser verificadas. Na faculdade aprende-se isso desde as cadeiras básicas (e o fato de ser esquecido como “coisa teórica inútil” me faz novamente perguntar sobre o valor do ensino formal).

Existe uma grande diferença entre fazer Test-Driven Development e testar. TDD é sobre modelagem de objetos e especificações, não sobre testes (tanto que Behaviour Driven Development está se consolidando como algo mais eficiente que TDD) apesar de que no final você acaba ganhando uma suíte de testes de graça.

É muito difícil achar um projeto open-source relevante que não tenha testes. Na verdade os projetos decentes só aceitam um relatório de bug ou um patch se vier acompanhando por um caso de testes. Imagine uma aplicação feita colaborativamente por diversas pessoas, como saber que o que eu acabei de fazer commit não vai quebrar o que você modificou ontem? Boas práticas de orientação a Objetos? Não se iludam, OO não foi feita para este tipo de verificação! Com boas práticas você consegue minimizar o impacto de mudanças diminuindo dependências mas você não vai ter certeza disso.

Eu sinceramente não sei que técnica é essa que faz programação defensiva evitar testes. Eu já li bastante sobre Orientação a Objetos e programação defensiva e não vi nada deste tipo, pelo menos não vindo de uma fonte com um mínimo de credibilidade. Um exemplo simples, imagine que o framework web imaginário Pagai possui um código parecido com este:


Acao acaoSendoExecutada = controladorPrincipal.acao(requisicao.acaoDesejada());

Simples, não? Agora imaginemos que o código do método acao(String) seja algo assim:


public Acao acao(String pathInvocado){
//verifica se acao possui o formato desejado, deve ter uma barra e deve ter dois itens separados por barra apenas
if((pathInvocado.indexOf("/") == -1) || (pathInvocado.split("/").size < 2)) throw new IllegalArgumentException("Path invocado ["+pathInvocado+"] nao possui o formato adequado (consulte a documentacao XYZ)");
//lógica...
}

Isso é programação defensiva: eu não estou aceitando o que me passam, eu verifico se é o que deveria e se for eu continuo, se não eu paro ali mesmo e deixo alguém tomar conta do problema, seja a classe em questão ou alguma outra mais acima.

Imagine que eu por engano commitei um código que utilize “” em vez de “/” nesta requisição. Se for numa parte central do código é bem possível que uns testezinhos peguem mas imagine que é utilizado apenas em um caso específico e que, por um acaso, eu baseei meu sistema de controle de jatinhos particulares 9meu chefe tem muitos jatinhos) nele. Quando eu fiz o comit não alertou. Quando eu fiz o build não alertou. Quando eu fiz meus testezinhos não alertou. Quando foi para a produção eu tive erro.

Ok, acontece. Programadores de qualquer tipo cometem erros. Eu vejo o problema muito rapidamente e o corrijo, temos uma versão beta em 15 minutos no ar, fantástico. Aí daqui há um mês outro programador comete o mesmo erro. Quando fizer o build não vai alertar. Quando fizer seus testezinhos não vai alertar. Quando for para a produção… Isso não é profissionalismo.

O que eu preciso é de uma suite de testes, unitários e de integração, que me digam que o sistema está incorreto já no processo de build, sem lançar jars beta, alfa ou gama.

Mas se tem um argumento nessa história toda que realmente me irrita é quando as pessoas dizem que “num mundo capitalizado não há tempo para testes” ou que “o cliente não quer saber como é feito, ele quer que funcione”. O cliente realmente não quer saber como funciona, ele quer que funcione. Mas ele também não vai querer saber que você alterou uma classe que usava barra para barra invertida e tudo parou de funcionar, ele quer que o problema não aconteça e se acontecer que seja corrigido rapidamente. Se seu sistema não tem qualidade -e testes fazem parte de qualidade- você não consegue isso. TI gasta fortuna das empresas reescrevendo sistemas simplesmente porque não foram feitos por profissionais, e profissionais se preocupam com a qualidade do que fazem. E isso inclui testes.


Não seja um amador.

Conexão Java 2007

Tuesday, October 23rd, 2007

Mais um ano vai, outro ano vem e o Conexão Java está aí. Este é certamente o evento mais descolado da comunidade Java do Brasil.

O CJ é um grande encontro entre as pessoas que participam em fóruns como o GUJ, o PortalJava e o RioJUG. O foco do evento são os mini-cursos que agem na formação de novos profissionais. Bem, formação não exatamente, ninguém sai de um curso de meioa dúzia de horas especialista em nada mas é uma boa oportunidade de ter contato mão-na-massa com algumas tecnologias e técnicas.

Este ano a estrela do evento é ninguém menos que Carlos Villela. Radicado em Londres pela ThoughtWorks há… bem, há alguns anos… o cv vem falar de algo bem atual: o declínio dos arquitetos monoglotas.

Também teremos algo um pouco diferente. Possivelmente deve haver um repeteco da minha palestra sobre arquitetura do JustJava 2007 (infelizmente sem o Paulo que vai estar de férias) mas enquanto isso é confirmado ficamos com mais uma atração: Oficina do Arquiteto.

Essa é uma idéia meio maluca que acabamos de fechar, vai funcionar mais ou menos assim: alguém traz uma arquitetura -seja de um projeto existente, livre ou de uma empresa, ou desenhado na hora- e nós debatemos esta. Na conversa vão sobrar padrões arquiteturais, guidelines e uma boa dose de bate-papo sobre o que nós, arquitetos, estamos fazendo por aí. Se você já tiver alguma idéia me adiante por email para organizar melhor as coisas, eu vou preparar algumas arquiteturas clássicas para usarmos quando não houver nenhuma na roda. A idéia é bem simples: debate, informação e diversão.

Arquitetos McDonald’s

Monday, October 15th, 2007

Estava eu lendo sobre um novo framework criado por alguma agência governamental de um estado qualquer. Geralmente eu não resisto e faço algum comentário sobre a utilidade de um framework que não traz nada de novo ou de bom e gasta dinheiro público (dinheiro público o caramba, seu dinheiro!) para isso mas desta vez me contive só em olhar os tutoriais da ferramenta, que sempre resulta em bons anti-exemplos para postar aqui.

Não me entendam mal, eu já trabalhei para empresas públicas e aquelas que andam na zona cinza entre empresas públicas e privadas e já vi muita coisa boa sendo feita lá. O problema de empresa pública hoje é o concurseiro profissional, esta praga que assola os cofres públicos atrás de cargos que pagam bem (quem nunca viu algum informata aprendendo direito para passar em provinha?) e depois pulam para outro que paga melhor. Enfim, o problema não é ser um órgão público, poderia ser numa empresa privada (a diferença é que se você considerar como uma empresa privada tem que considerar que você é acionista que investe muitos-% do seu salário nela e deveria ter algum resultado).

O ponto inicial é que arquiteturas de referência são um conceito falido. Ter guias arquiteturas, modelos, sugestões é uma coisa, impor uma arquitetura única é outra. O Luca já deu diversos motivos para não fazer este tipo de coisa e eu lembro de um projeto que participei há alguns anos atrás em uma grande empresa que utilizava esta técnica.

Toda a parte de logística da empresa, um mega-departamento com seu próprio vice-presidente, utilizava um framework que foi definido por uma equipe arquitetural. Eu conheci o arquiteto em questão e não acho que ele seja um mau profissional, pelo contrário é bem talentoso. O problema é o diálogo:

- Fulano, estamos cansados de gastar dinheiro nesta arquitetura mainframe, precisamos migrar para Java logo.
- Ok, falei com a consultoria XYZ e eles alertaram para o fato de que não existe ‘desenvolvimento Java’, você tem que escolher uma plataforma diferente a cada projeto!
- Mas @#$#! Se eu vou comprar Java eu vou comprar algo que sirva para tudo que venhamos a fazer. Eu quero uma solução, Fulano, se vira!

(…)

- Arquiteto José, precisamos definir a tecnologia utilizada.
- Mas precisamos testar…
- Cara, a gente paga você pra tomar decisão, aprende isso de uma vez. Sabe o projeto da agenda telefônica? Aquele que não tem a menor importância? Então, pega ele pra fazer, junta seus melhores programadores e faz uma prova de conceito de uma arquitetura.

E lá vai o arquiteto fazer um projetinho sem valor nenhum com a tal tecnologia. O projeto invariavelmente é um sucesso mas se falhar ninguém liga. Daí agora todas as aplicações usam o framework.

E esquecemos o que há de mais importante na arquitetura. O engenheiro analisa a obra do ponto de vista técnico, o arquiteto analisa de diversos pontos de vista. Lembro de um caso recente onde um amigo precisou criar um sistema complexo rapidamente. O sistema exigia uma complexidade grande e deveria ser feito em pouquíssimo tempo com uma equipe de desenvolvedores junior. O arquiteto viu o cenário como um problema e traçou um plano: criou uma camada de abstração forte (quase uma DSL) que permitia aos programadores desenvolver rapidamente mesmo sem muito conhecimento sobre Java. Quando o projeto foi bem-sucedido apareceu o gerente de tecnologia maravilhado! Ele queria adotar essa prática em todos os projetos, minimizando drasticamente custos e tendo sistemas prontos na data. Bala de prata.

Este arquiteto em questão se negou a fazer parte do grupo que definira o novo framework. Experiente do jeito que é ele sabia que uma arquitetura que dá certo em um projeto não necessariamente vai dar em outro e ele não apostaria sua carreira e prestígio profissional num projeto furado desses. Como era consultor ele foi remanejado para outro cliente e a última notícia que tive da empresa é que ela criou seu framework com Velocity, Struts e JDBC, com uma versão em EJB 2.1 -nenhum projeto com este framework foi um sucesso até agora.

Ainda que o projeto que originou a arquitetura de referência tenha sido muito complexo e um sucesso absoluto isso não quer dizer que outros com esta arquitetura serão. Não é porque objetos foram feitos para arquiteturas do tipo Domain Model que ela é a mais adequada sempre, não é porque EJBs são o mecanismo padrão de distribuição que ele deve ser utilizado para qualquer RPC.

Existe um paradoxo nas arquiteturas de referência: para se ter uma boa arquitetura (de referência ou não) é necessário um bom arquiteto mas a primeira coisa que um bom arquiteto vai dizer é que arquiteturas de referência são uma péssima idéia.