codificando.com

Certa vez, passei por uma situação que acredito que você já passou um dia na sua vida profissional. Tive que implementar uma funcionalidade nova num projeto e precisava alterar diversas partes do código desse projeto para implementar essa funcionalidade. Infelizmente esse projeto não tem uma boa cobertura de testes automatizados. Existem até alguns testes, mas não o suficiente.

Dentro do “possível”, adicionei testes no projeto para melhorar o nível de confiança nas alterações e conseguir trabalhar um pouco mais sossegado quanto a qualidade do que estava sendo desenvolvido. Aproveitei a oportunidade para estimular meus colegas no uso de testes automatizados. Eu poderia simplesmente ignorar os testes e manter o “padrão” atual do projeto, mas como bem disse uma vez o Guilherme Chapiewski num excelente post sobre inclusão de testes num projeto, no momento em que comecei a modificar o código desse projeto foi o momento em que comecei a colocar testes nele.

Nessa experiência, enumerei 3 sintomas que podem ser um indício de que seu código está virando o Código do Pânico. São eles:

1. Classes/Metodos/Atributos que aparentemente não são mais usados não são removidos, pois não existe certeza de que a remoção deles não vai causar problema.
2. Existe um medo enorme em modificar um método. Geralmente cria-se outro que faz “quase a mesma coisa” e com um nome parecido, pois estragar aquele método pode gerar até uma demissão.
3. Desenvolvedores adicionam gambiarras (ou bacalhau pra quem prefere) sem a menor pena, afinal de contas, o código já está cheio delas mesmo.

A maioria dos problemas que tornam o código do seu projeto um Código do Pânico se resolvem com praticas como TDD, mantendo uma boa suite de testes e também retirando as gambiarras do seu código, que quando não removidas, estimulam outros desenvolvedores a adicionar mais um pouco sempre que a pressa pede.

O quanto você tem medo de alterar o código do seu projeto?

Uma discussão que sempre vem a tona no forum do GUJ e em conversas entre colegas de trabalho, é sobre o uso do pattern TO/DTO (Antigo VO, que hoje em dia significa outra coisa). Eis o trecho do livro Core J2EE Patterns:

Transfer Object

Problem
You want to transfer multiple data elements over a tier.

Forces

• You want clients to access components in other tiers to retrieve and update data.
• You want to reduce remote requests across the network.
• You want to avoid network performance degradation coused by chattier applications that have high network traffic.

Solution
Use a Transfer Object to carry multiple data elements across a tier.

O Pattern Transfer Object, foi criado para solucionar os problemas dos Entity Beans (EJB 2.x), quando retornados para outro TIER, geralmente a apresentação, pois geralmente ficam em JVMs separadas. Quando você tenta retornar um Entity Bean, o que é retornado na verdade é um Stub para acesso ao mesmo. Quando são invocados os Getters deste, é aberto uma conexão de rede para cada invocação. Isso é extremamente custoso, gerando um overhead extremamente desnecessário.

Bem, mas nosso papo é tradução certo?

INI-UPDATE: Consegui o livro em português com um colega e estou adicionado a tradução em português também.

Vejamos a tradução para o português:

Transfer Object

Problema
Você deseja transferir diversos elementos de dados sobre uma camada.

Forças

• Você deseja que os clientes acessem componentes em outras camadas para recuperar e atualizar os dados.
• Você deseja reduzir as solicitações remotas ao longo da rede.
• Você deseja evitar a degradação do desempenho da rede causada pelas aplicações muito ruidosas que têm alto tráfego de rede.

Solução
Use um Transfer Object para enviar vários elementos de dados por uma camada.

O leitor atento perceberia que o segundo e terceiro item da seção Forças fala de tráfego de rede e degradação do desempenho da mesma.

FIM-UPDATE

Acontece que, o termo TIER, foi traduzido erradamente no livro em português para camada. O mais correto seria camada física ou nó. Em Java isso pode ser considerado simplesmente “em uma outra JVM”. Essa tradução gera confusão a todo momento. Se você conversar com 10 desenvolvedores, vai perceber que a maioria acredita que TO/DTO pode/deve ser usado entre LAYERS (i.e. camadas lógicas, usadas apenas para organização do software). Eis um grave problema de tradução, pois uma grande parte não sabe a diferença entre LAYER e TIER, e o uso do Pattern dessa forma se mostrou uma solução sem sentido, conforme diversas discussões no próprio GUJ.

Outro grave problema recorrente é a tradução dos livros de Patterns. Pegue por exemplo o PEAA traduzido e veja o Pattern Active Record. O nome do Pattern foi traduzido para Registro Ativo. Parece piada, considerando que um dos maiores valores de um Pattern é a criação de um vocabulário comum.

Em fim, existem diversos outros exemplos ruins, e só quem perde com isso é o leitor.

Mas nem tudo está perdido. Existem sim traduções bem aceitáveis, porém em quantidade extremamente reduzida e demoram a sair. Você está disposto a esperar? Não acha melhor comprar o livro em inglês mesmo?

Mas se eu não domino o inglês?

Sinto informar, mas você vai ficar refém de boas traduções, isso quando tiver tradução. Sem contar os podcasts, como por exemplo os videos disponibilizados no InfoQ. Na verdade, muita coisa não tem tradução e nem vai ter, isso é fato.

Esse cenário serve pra reforçar a idéia de que o inglês na área de TI é fundamental para o profissional se manter atualizado, visto que existem livros que não são traduzidos, e os que são, ou a tradução é horrível, ou demora muito para ser traduzido após o lançamento da versão original.

Mesmo que o cenário mude, ainda assim tem muita coisa que você estará perdendo. Quem sabe um emprego no exterior?

No último fim de semana (13 e 14 de junho/2008), participei com alguns amigos do Workshop de Modelagem ágil e DDD promovido pela Fratech em São Paulo.

O Workshop foi bem interessante, abordando temas atuais e de extrema importância no conhecimento do Desenvolvedor de Software.

No primeiro dia, o foco foi bastante em FDD, M3 e Agile Draw. Foi bem legal esse primeiro dia, pois eu experimentei algumas técnicas que nunca havia tentado. Confesso que não simpatizei muito com a modelagem com as figurinhas, nem muito com a FBS, mas eu vou pensar mais sobre o assunto e tentar me aprofundar um pouco pra tirar melhores conclusões.

Da esquerda pra direita: Colega de verde(rs), Gustavo, Eu, Colega de Branco(rs)

No segundo dia, o foco foi todo vontado para Domain Driven Design e UML em Cores. Foi bem interessante, pois o assunto tem um hype nos dias de hoje e é um assunto bastante motivador também.

A técnica de UML em Cores me ajudou um pouco a identificar algumas coisas em Model Driven Design, mas ainda assim, preciso testar mais pra definir se usarei essa técnica.

No mais gostaria de dar os parabéns ao Felipe Rodrigues e o Manoel Pimentel pelo evento que foi muito legal e tenho certeza que surgirão outros.

Da esquerda pra direita: Adndré, Eu, Felipe, Gustavo e Manoel

O unico problema é ter que se despencar do Rio de Janeiro toda vez, pois aqui estamos meio carentes de coisas do tipo, exceto pelo fato que as ultimas reuniões do RioJUG foram excelentes.

A área de Desenvolvimento de Software passa por uma grande mudança nos últimos anos. Existe um apelo muito grande na comunidade de desenvolvedores de software para práticas ágeis, menos burocracia e soluções práticas e eficientes para se trabalhar.

Acontece que pessoas com perfil inovador, ou mesmo pessoas mais tradicionais mas de mente aberta, se empolgam facilmente e tentam convencer as pessoas que essas “novidades” são ótimas e que a forma”antiga” com que fazemos as coisas não funciona, ou melhor nunca funcionou de forma decente.

Ai começam os problemas. Por mais incrível que pareça, as pessoas de TI em sua maioria são muito mente fechada, e quando se fala de algo do tipo a maioria delas tem uma resistência enorme e geralmente faz alguma gozação, ou simplesmente menospreza dizendo: “Meu filho, a IBM que criou isso? A Sun? A Oracle? Ah, foi Fulano de tal? quem é esse cara? Não quero saber disso não ..”

Felizmente, encontro pessoas abertas, que ouvem, percebem e ao menos procuram conhecer sobre os assuntos e na maioria das vezes a pessoa passa a entender as mudanças e se tornar adepto.

O problema disso tudo é que em vários momentos tem gente mente fechada que nos enxerga como maluco, quase uma comunidade de anarquistas, algo como se fosse uma rebelião contra o modelo atual. De fato, é uma insatisfação total, pois a coisa já ta mais que provado que não funciona, basta ver os prazos estourando, pilhas de documentos que estão sempre desatualizados e software com qualidade a baixo do aceitável.

Depois de levar tanto fora e ser tratado mau algumas vezes por algumas pessoas, será que ta valendo a pena ainda oferecer a pílula vermelha?

Acho que vou adotar a idéia do Morpheu e evitar oferecer essa pílula para as mentes adultas (Aqui você entende como quiser). Melhor oferecer com mais critério, não pelos mesmos motivos do filme matrix, mas pra evitar desgaste com pessoas, que é muito chato.

Com as mudanças que ocorreram e ainda estão ocorrendo na área de Desenvolvimento de Software, como agile, TDD (Acreditem, apesar de não ser novo tem muita gente que ainda nem sabe o que é isso), SCRUM, etc, é muito comum que as pessoas com perfil inovador, ou mesmo pessoas mais tradicionais mas de mente aberta, se empolguem bastante e tentem convencer bastante gente de que essas mudas são ótimas e que a forma com que fazemos as coisas nas grandes corporações aqui do Brasil, com processos burocráticos, quilos de documentação, metodologias Waterfall disfarçadas de RUP, simplesmente não servem mais, ou melhor, nunca serviram.

Nos últimos meses, tenho ajudado a empresa onde trabalho a escolher um fornecedor para implantar SOA na casa. Infelizmente, não nos está autorizado a fazermos nós mesmos. Os fornecedores escolhidos pela empresa para nossa avaliação, são quase todos fornecedores [A-Za-z]{3}.

Tenho percebido de maneira geral que a maioria desses fornecedores não conhece muito do que nos tem apresentado. Uma simples pergunta sobre Message Broker e ninguém, absolutamente nenhum dos fornecedores soube responder direito. Na verdade, alguns deles confundiram com o produto Message Broker da IBM e outros com ESB.

Teve uma outra empresa, que não posso mencionar o nome por motivos óbvios, que conseguiu vender um projeto SOA aqui dentro, que não era nada mais que instalar um ESB, um servidor de processos e fazer um sisteminha de referência e só !!!! O Pior de tudo é que ganharam uma grana preta com isso.

O fato é que está muito difícil opinar sobre qual fornecedor a empresa deve confiar o “projeto” SOA, e o cenário atual, com a pressão vinda de cima pra baixo para implantar alguma coisa de SOA, só porque está na moda e sem as vezes nem entender o que é, faz como que muitos fornecedores consigam essa maravilhosa TETA pra mamar nas grandes corporações.

É impressionante como aqui no Brasil este movimento de ferramentas IDE que se propoem a gerar código, “programar pra você”, ainda continua ganhando força. Recentemente chegou uma pessoa na empresa onde trabalho oferecendo a ferramenta JCompany para a empresa. Segundo o mesmo, a ferramenta monta a arquitetura toda do sistema, gera os CRUDS e muito mais. Ai eu me pergunto: Não precisamos mais de arquitetos certo ? Precisamos de meia dúzia de code monkeys para codificar o que sobrar e pronto, tudo resolvido. Não vou ficar falando muito da ferramenta em questão pois hoje em dia qualquer menção sobre algo e vem um processo em cima de nós. Em fim, a ferramenta que promete gerar tudo e tornar o trabalho do programador algo banal.

Pouco antes desse dia, teve uma apresentação de uma empresa sobre SOA, mostrando um monte de ferramentas de modelagem de processos, servidor que roda os processos (além do servidor de aplicações), IDE turbinada, e o cara teve a coragem de dizer que com SOA não existe mais sistema, tudo é serviço, proibiu durante a apresentação a palavra sistema, de acordo com essa tese. Disse também que reduziriamos drasticamente o número de programadores, teriamos tudo prontinho, e …, mesma balela (o pior é que teve gente acreditando nisso e gostando muito).

Essas duas experiências me fizeram pensar sobre o fato de existirem diversas pessoas ignorando completamente o que é um programador e para que serve o mesmo. E pior, ignorando a capacidade de um ser humano raciocinar e fazer escolhas de acordo com problemas, acreditando que arquiteturas engessadas resolvem o problema de pessoas não treinadas, e ainda ignoram a evolução da indústria de ti, com DSLs e outras coisas mais.

Triste, é triste ver que tem gente que faz faculdade, pós, mestrado, etc e fica só com o que aprendeu lá, e muita das vezes nem aprendeu, apenas foi aprovado.

Mais uma vez estamos naquela velha discussão sobre performance versus manutenabilidade ….

Essa história tem muita semelhança com a nossa vida de desenvolvedores de software.

Nessa historinha que vou contar eu reforcei alguns conceitos e aprendi outros. Vou aproveitar para colocar algumas lições em geral. Talvez no começo da leitura você se pergunte o que isso tem a ver com TI mas calma, leia até o final é um paralelo.

Faz alguns meses que resolvi converter meu carro para utilizar GNV. Escolhi uma convertedora líder de mercado apenas pelo nome. Ai começaram meus problemas …

Lição número 1: Nunca escolha alguna coisa na sua vida apenas pelo nome. Procure indicações. Se não conseguir nenhuma, procure mais informações sobre a empresa/produto/profissional/etc que esta querendo comprar/contratar/etc.

Ao verificar as opções de instalação verifiquei uma que tinha maior performance ao mesmo custo. Um Chip eletrônico GNV que substitui N componentes e ainda reduz o tempo de instalação do Kit. Parece perfeito, não gasto nenhum real a mais e vou ter uma solução com a performance melhor e o tempo de instalação reduzido.

Alguma semelhança com o desenvolvimento de software ?

Ai o dono da loja me informou que a instalação do chip é feita apenas na matriz (que é muito longe da minha casa). E eu, fascinado pela performance e pela facilidade da instalação (Parece até a nossa amiga M$), resolvi prosseguir assim mesmo.

Lição número 2: Se você está percebendo cheiro de bosta se limpe antes de ficar todo cagado. Ps: Eu me caguei todo

Bom, após instalar a solução mágica, tive alguns problemas do carro não desenvolver direito, etc, etc, etc, como vocês já sabem, carro da problema ainda mais com um componente adaptado.
Nesse momento cai a ficha da besteira que eu fiz. Ue mas Chip GNV é uma inovação tecnológica de ponta certo ? Correto mas só na porcaria da loja matriz que dá manutenção na benção do Chip GNV.

Lição número 3: Antes de decidir por alguma coisa, pense sempre como vai manter em funcionamento aquilo que escolheu ou se está so arrumando um abacaxi que só vai te dar dor de cabeça.

Levei meu carro na loja onde comprei o Kit GNV, Mudou todo mundo da loja inclusive a gerência e eu fiquei tontinho sem saber o que ia acontecer. O Dono da loja, muito simpático por sinal, me atendeu super bem e resolveu me ajudar (Estava tudo na garantia bah …. isso geralmente não adianta de nada). Deu uma olhada, andamos com o carro e no fim de tudo ele me disse o que eu esperava mas não queria acreditar de jeito algum: Olha amigo, o problema deve ser no Chiv GNV mas aqui não damos manutenção no Chip, somente na matriz (Que fica a 50km da minha casa e so está aberto no horário que estou trabalhando).

Lição número 4: Compre/Utilize/Procure soluções/produtos/coisas que sejam padrões de mercado/indústria pois você consegue ajuda de outros profissionais/fornecedores (Desculpem as barras exessivas vai .. rs). Caso contrário, vai sofrer muito igual a mim quando pintar algum problema ou mudança)

O fim da história é facil, tenho que levar o carro na matriz pra verificar o problema e toda vez que ocorrer algum probleminha vou ter que ir na matriz (50km da minha casa).

Lição número 5: Meu carrro não ia andar na F1, portanto não precisava ganhar 4CV a mais de potência por causa de um Chip milagroso e nossos sistemas geralmente conseguem atender os requisitos de performance mantendo a manutenabilidade boa e sem precisar escovar bits a troco de nada.

Agente dá nossas cabeçadas na vida né ? Vamos pelo menos aprender com elas