Mas a idéia do Post é outra, que tal contribuir com um sorriso inocente neste natal? Então.. uma amiga minha está com uma vakinha em aberto para comprar brinquedos, roupas, doces para as crianças carentes.. então quem quiser contribuir, de alguma forma, com qualquer valor, ela (e as crianças) ficarão muito agradecidos. Só clicar aqui. Quem não puder, mas quiser ajudar com um twitt ou um curtir, já está ótimo também.

Abraços.

É muito bom mudar, transformar, e isso deve ser feito com cuidado, mas nunca, jamais, da noite pro dia. É o erro que o pessoal (principalmente da geração Y) comete com freqüência. Resolvi aqui listar alguns destes erros que eu já fiz, presenciei e superei. Mas não vou deixar ninguém na mão, deixo na verdade a minha opinião sobre estes pecados e a forma que eu agiria em cada situação. Espero que sirva de aprendizado para o seu sucesso profissional.

#1 – Não faça críticas ao legado. É legado e todo legado tem problemas. Sua empresa não é exceção ao todo, todos têm legados e todos sofrem com este. Não julgue um legado pela linguagem que este fora implementado. Por pior que seja, se for, ainda é um ativo da empresa, afinal, é o que mantém o negócio no ar. Idéias revolucionárias para substituí-lo continuam a ser idéias, ainda não existem e não estão em produção. Não faça o novo criticando o presente/passado. Principalmente se alguém que faz parte do presente/passado esteja na sua equipe. E se você for de alguma consultoria, mais atenção ainda, pois ninguém quer ouvir que o seu sistema legado é uma droga. Eles querem soluções. Não cometa este erro para não ouvir um “faça melhor”. Na verdade, faça melhor e quando for virar à chave, o agradeça e as pessoas que nele trabalharam. Todos ficaram felizes.

#2 – Não tente implantar uma metodologia ágil da noite para o dia. As pessoas que trabalham na sua empresa podem estar acostumadas e confortáveis com a atual metodologia de trabalho, por mais burocrática e engessada que esta venha a ser, implantar uma metodologia nova em um ambiente de TI é necessário muito esforço, alinhamento com sua equipe, gerencia e seus clientes, para piorar, este alinhamento é incremental: primeiro planta-se uma sementinha sobre uma oportunidade e depois vá regando até brotar e crescer, mas atente-se  ao risco de morrer na primeira tempestade. Por exemplo, um dos programadores conhece o negócio, mas não sabe usar determinada API, enquanto outro sabe da API, mas não conhece o negócio… Coloque os dois lado a lado, mostre para eles que, se os dois pensarem juntos, se alternarem no comando do teclado e do código, algo bom pode fluir. Diga ao final que isso se chama programação em par, uma técnica da metodologia ágil Extreme Programming, certamente eles vão querer saber mais sobre este tal de XP. Veja oportunidades nas dificuldades, é a melhor forma de se conseguir algo, resolvendo um problema real. Fazer sua equipe comer agile com farinha falhará.

#3 – Tenha opiniões formadas, do contrário, não opine! Você pode ser questionado e não saber se defender, conseqüentemente sua moral irá despencar. Se quer tratar um assunto com alguém, saiba do que está falando. Quer falar de Test-Driven Development com alguém? Domine isso antes. Tenha tido experiência com isso antes. Tenha escrito testes antes (duplo sentido). Ser xiita, defender algo que conhece apenas teoricamente ou porque leu em algum artigo por aí é um erro fatal. Fuja disso.

#4 – Não seja resistente com o fornecedor picareta. Eu e você (e até eles) sabemos que, o que eles mais querem é vender (menos o seu gerente, que costuma acreditar em conto de fadas)! Quanto ao negócio propriamente dito, eles tratarão disso vendendo consultoria depois. Mas o primeiro passo continua a ser vender o software “faz tudo” de um milhão de dólares. Isso não significa que você vai falar para seu gerente não comprar. É uma variante do pecado #3, afinal, você vai saber argumentar o motivo de não comprar? Ou vai dizer apenas que a empresa é picareta, pois um amigo do seu irmão lhe disse? – Monte uma apresentação, faça gráficos (gerentes adoram gráficos), mostre as alternativas, soluções open-source e a economia que ele terá escolhendo X ao invés de Y. É assim que se toca, camarada. Fuja da resistência, apresente alternativas e os benefícios relacionados.

#5 – Não force ninguém a usar o que você usava na sua empresa anterior. A empresa atual usa cruisecontrol? Aprenda cruisecontrol antes de falar do Hudson. Sua empresa usa JDeveloper? Aprenda JDeveloper antes de falar do Eclipse. Sua empresa usa bugzilla? Use o bugzilla antes de falar do Jira. E por ai vai… Critique apenas o que você conhece e sabe que existe algo melhor, para então sugerir. Você corre o sério risco de ser ignorado e/ou ser visto como uma pessoa resistente, por mais certo (ou não) que esteja.

Se você achou os cinco pecados coerentes entre si, você captou a mensagem! E você, poderia contribuir com esta lista?

Robson

http://twitter.com/irobson

Feito!

As oportunidades são para Porto Alegre/RS – mas não nos importamos se você for daqui ou da Polônia, mas sim se você está disposto a mudar pra ca. Vale lembrar que algumas oportunidades também exigem disponibilidade para viagens.

Os interessados devem encaminhar currículo para o e-mail curriculos at ilegra.com, identificando a vaga para a qual pretende concorrer.

As vagas: 2 para DBA Oracle (pleno/sênior); 3 para Analista de Sistemas; 1 para Programador Java/Plsql; 2 para Arquiteto de Software; 10 para Programador Java; 2 para Programador Plsql; 3 para Programalista Java; 1 para Oracle developer; 1 para Programador LINC II (SP); 2 para Gerente de projetos.

See you.

Bem, na verdade existem dois tipos de Value Objects, que são os criados pela Sun, para mascarar os problemas das primeiras versões das distribuições EJBs e o que faz sentido num paradigma O.O.. Em minha humilde opinião, o segundo é mais coerente, pois de fato favorece um padrão, do contrário do primeiro, que na verdade acabou virando um anti-pattern. Portanto, focaremos este simples post no segundo e ao final, fazendo uma ressalva ao primeiro.

De acordo com Martin Fowler, Eric Evans e outros evangelistas de um modelo de domínio rico, um Value Object é um simples objeto, usualmente com atributos que não referenciam outros objetos, imutáveis e sem identidade, pois são meramente representativos. Em outras palavras, um verdadeiro objeto de valor – O objeto vale mesmo alguma coisa.  Exemplos:

Numero: é um típico exemplo de um VO. O seu valor justifica sua existência. É imutável, pois você não consegue mudar os valores de um numero. Deve-se criar um novo para isso. Sua comparação não se resume em todos seus atributos, comparando apenas o valor o qual representa é suficiente.

Dinheiro: Philip Calçado, provavelmente baseado no exemplo de Fowler, dá um ótimo exemplo de VO falando do objeto Dinheiro. Um dinheiro, supomos aqui, Reais, possui um valor: dois, cinco, dez, vinte, cinqüenta, etc… na vida real, é um papel. Obviamente, alterar seu valor resultaria em rasura ou problemas com a policia, justificando assim sua imutabilidade, no entanto, se eu te empresto dez reais, não há necessidade de receber os mesmos dez reais de pagamento. Pode ser outra nota, tanto que tenha o mesmo valor.

Cor: Oras, uma cor vale, herm… uma cor! Por isso que para representar cores é muito melhor usar Enums, a propósito, tudo, ou a grande maioria do que é VO deveria ser possível de se representar utilizando Enumeradores.

Deu para entender a grande sacada do verdadeiro VO? Ele representa um valor, simples e intuitivo, certo? Muito próximo do que chamamos de primitivos, afinal, se os criadores de linguagens de programação conhecessem todos os VOs possíveis, não precisaríamos ter objetos explicitamente declarados para estes, pois nossos compiladores reconheceriam um simples R$ 10,30 no editor, sendo dez reais e trinta centavos.

Mas então, não era bem isso que você achava que era um VO? Bom, vejamos se eu adivinho: Pra você, um VO era uma estrutura, com getterns and setters, comumente utilizada para transportar valores entre camadas e camadas. Então, é bem esta mesmo a confusão. Este é o TO (Transfer Object) – uma adaptação do padrão Data-Transfer Object (também catalogado por Fowler) – O TO na verdade é um valor composto por vários atributos, serializado (é transportado entre camadas), servindo principalmente para minimizar o trafego de objetos numa rede.

Recapitulando o que você vê nos sistemas por aí, não são VOs e sim TOs! Mas e se eu te falar que a utilização deles normalmente ocasiona em redundância do seu modelo, você acreditaria? Então, é. A grande maioria dos sistemas que utilizam TOs, de duas uma: ou realmente não sabem o que estão fazendo ou não seguem o principio “você não vai precisar disso no futuro”. É balela. Como já disse, TOs são para trafegar objetos de JVMs distintas entre TIERS (dica: vide padrão memento para construir arquiteturas distribuidas com TOs, eficazes). Quantos destes sistemas aí realmente precisam fazer isso? A grande minoria, creio. Ter TOs em LAYERS é puro hype.

Layers vs Tiers.
Não precisa cortar seus pulsos se você concordava comigo desde o inicio, é que gosto de manter a interatividade nos meus post subestimando meu leitor. Afinal, este tipo de post só é util para quem está aprendendo e não para quem já sabe

Siga-me, maldito.

Mas este é um blog de tecnologia e esta, esta sim “bombará” nosso pais em 2010. Muitas consultorias novas por aqui, desde a Thoughtworks se instalando aqui em Porto Alegre até as XPTOs indianas oferecendo mão de obra barata e burrocracia elevada para os CIOs “dilbertirianos”, mas tudo bem, todos tem suas fatias no mercado. E, que bom que tem muita gente investindo. Prevejo muitos hypes à tona de forma errada também: CMMis ágeis, Domain-Driven Designs em arquiteturas BOLOVO, acrônimos flutuando por currículos sem nenhum sentido, selos de qualidade e canudos de formação sendo mais importantes do que o próprio conhecimento e, de quebra, os que se dizem “gurus” da informática bolando novos planos infalíveis para tornar o processo de desenvolver software o mais parecido possível com o de produzir sapatos. Pense. Repare. Parece que não teremos tantas novidades assim… então que venha 2010.

Feliz ano novo, para você e sua família.

Tudo que você faz, o faz como se você mesmo fosse usar? Pense nisso antes de construir a próxima linha de código lá no seu trabalho, esqueça seu chefe chato (não que o meu seja, caso o mesmo leia este post…) e codifique como se você mesmo fosse seu próprio usuário, como se você dependesse do seu próprio sistema para realizar seu trabalho.

Afinal de contas meu caro colega, os usuários gostariam tanto, mas tanto, que o que tu faz realmente funcionasse, que eles seriam capazes de te dar um beijo nas nadegas a cada dia de caixa fechado sem bug no sistema. E eu, sendo o cara que irá dar manutenção no seu código, adoraria tanto ver uma suite de testes unitários bem construidos quando o pegasse, que seria capaz de.. te pagar uma Polar bem gelada no boteco mais badalado da cidade baixa aqui de POA.

“Ah, mas eu já escrevo todo aquele código e testo tudo no main..  ainda tenho que escrever testes unitários pra ele?” Amigão, se tu quiser não precisa mais escrever este código todo.. escreva apenas os testes então. Ééé, isso mesmo. Esqueça aquela coisa toda logo de cara e vá direto aos seus @Test.. apenas coloque na cabeça: só entregue este código depois que os testes passarem! Se por acaso, tu ter que codificar um pouco para os testes passarem, beleza, tu faz classe a classe, mas espere, a classe não precisa existir para tu escreve-la pela primeira vez no seu teste… deixe o Eclipse chorar mesmo, só depois tu cria, ou melhor, rode a droga do teste sem a classe, para tu VER na tela que nada funciona sem a presença da maldita classe. É bem simples, não precisa ler um livro para começar.. são regrinhas básicas: da direita (seus testes) <simula erro> para a esquerda (implementação de uma pequena porção de código) <testa>.

“Mas quando eu sei que não preciso mais testar?” Quem disse que não precisa mais testar? Sempre que tu tocar aí tu vai testar, a unica diferença é que não precisará mais se preocupar com o que já está testado, pois se der algum tipo de erro, tu saberá exatamente onde consertar. Eu mesmo, sei quando não preciso mais testar quando o código que eu preciso para entregar a minha estória está pronto e é suficiente, pois de acordo com o TDD, se ele já está pronto, é porque existe um teste para ele!

Finalizando.. “eat your own dog food” .. estou ficando louco ou:

a propósito (falando em loucos), aproveitando a presença do Rod Johnson na TDC, nos diga Rod: o que faz a SpringSource, usar PHP no seu portal? http://www.springsource.com/index.php, Por quê não o nosso amigo SpringMVC?

E que calor infernal em Porto Alegre…

Uma reclamação idêntica à minha pode ser conferida aqui.

Abraços, e bom FDS. (sorry pelo post fora de foco)