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?

Nas empresas que trabalhei até hoje durante a minha carreira, a maioria delas tinha uma coisa em comum: o funcionário tinha que trabalhar para agradar seu chefe, ao invés de trabalhar em favor da empresa.

Nesse momento, surge uma nova definição de processo de desenvolvimento: BDD - Boss Driven Development (Desenvolvimento voltado para o chefe). Basicamente funciona da seguinte maneira:

• Se seu chefe chega cedo, trate de chegar cedo, pois se ele chegar antes de você, é muito ruim e provavelmente você terá problemas com ele
• Se der a hora de você ir embora e por algum motivo ele ainda estiver na empresa, permaneça até ele sair, pois ele pode precisar de você para alguma coisa. Quem sabe pegar um café pra ele?
• Por mais que você saiba que precisa melhorar alguma coisa que não está muito legal no projeto, cuidado ao falar com ele, pois ele pode achar isso uma ofensa, ou até mesmo dizer que a culda disso é sua.
• Se ele pedir pra você ficar fazendo tarefas que nada tem a ver com a sua profissão/aptidão/vocação, não questione, afinal de contas, o segredo para crescer em uma empresa é fazer tudo que o chefe manda e ficar bem caladinho.

Por mais incrível que possa parecer, ainda existem muitas empresas que trabalham dessa forma. Especialmente as famosas consultorias [A-Za-z]{3}.

O BDD relacionado a testes de software é bem mais interessante, não é mesmo?

Graças a Deus onde eu trabalho não é assim.

Quanto mais leio algumas coisas, mais penso que processos empíricos e ágeis serão adotados por quase todos os segmentos existentes hoje.

O Phillip Calçado postou sobre o caso de uma indústria farmaceutica e sua opção por implantar algumas práticas totalmente diferentes do que tinham o costume de usar. O resultado foi o mesmo que temos visto nas empresas de TI que tem abraçado as metodologias ágeis.

O mais engraçado disso tudo é que tem algumas pessoas que por mais que você mostre reultados, elas insistem que isso é uma modinha e que daqui a pouco passa.

Será?!?!?

Quando entrei aqui na Globo.com não achei que ia postar alguma coisa tão rápido. Mas acontece que ontém colocarmos nos ar o site de inscrições para o BBB9. Como todo projeto na vida, esse teve seus desafios, afinal de contas, colocar o site de inscrições para o BBB9 em 1 semana apenas, só mesmo com metodologias ágeis.

Aproveitando esse post, vou falar um pouco do novo time e do novo ambiente de trabalho.

Bem, basicamente trabalhamos praticamente todos juntos no nosso “mesão”.

Como podem ver, o “mesão” é bem compacto, mas ao mesmo tempo cada um tem um espaço razoável pra não ficar apertado. Existem apenas 2 membros do time que ainda não migraram pra cá, mas o farão em breve.

Como estarmos todos bem perto um do outro, a comunicação foi (é) bem intensa, fazendo que o ruido na seja praticamente nulo. O compromentimento do time também foi algo bem interessante. O pessoal que por alguns momentos havia terminado suas tarefas, se prontificava a ajudar os demais membros do time para garantir a nossa entrega, afinal de contas, BBB é algo que tem data fixa pra entrar.

O melhor de tudo foi receber um email do Product Owner hoje pela manhã agradecendo e elogiando todo o time.

Os anuncios na TV estão bombando, e pra quem gosta de BBB o site de inscrições é: http://bbb.globo.com/

Na última sexta-feira, deixei a Bradesco Seguros, empresa onde trabalhava pela DTS Consulting para encarar novos desafios.

Gostaria de agradecer aos amigos que me apoiaram bastante e aos meus antigos chefes na Bradesco Seguros, e também da DTS Consulting, que deixaram as portas abertas para um possível retorno futuro.

Há mais ou menos 1 mês atrás, o Bruno Pereira me chamou para uma vaga na Concrete Solutions. Ele me deu ótimas referências da empresa e resolvi aceitar o convite. Após todos os acertos, estou trabalhando alocado aqui na Globo.com, desde o início desta semana.

É um novo desafio na minha carreira, pois terei a oportunidade de trabalhar com SCRUM, o qual fiz um curso em março passado na TeamWare, e num ambiente realmente ágil, que começou com uma iniciativa do Phillip Calçado no ano passado.

Já comecei em um Sprint/Iteração e a coisa está realmente quente. Na semana que vem vou postar sobre o assunto e começarei a postar algumas coisas interessantes sobre Agile/SCRUM, baseado na minha vivência aqui.

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.

Na segunda-feira passada, tivemos uma palestra do Fábio Kung sobre JRuby on Rails no RioJUG. Basicamente foi um repeteco da palestra do Falando em Java 2008, a qual estive presente no dia 18/05 passado.

A palestra foi extremamente importante para abrir os olhos de muita gente que acha que Java vai ser Mainstream pra sempre. Pelo que tenho percebido, o tempo de Mainstream de uma linguagem tem diminuído bastante nos últimos tempos. Antigamente uma lingagem ficava na moda por muito mais tempo que hoje.

Em fim, voltando a palestra, foi bem interessante ver uma visão arquitetural de alto nível do GUJ 3.0, observar as escolhas das gems, o problema com as gems nativas e os contornos utilizados.

A escolha de rodar o Ruby na JVM, foi também um fator que foi muito falado durante a palestra. Os fatores principais foram a questão do compartilhamento de sessão entre os nós e o empacotamento do JForum junto na mesma aplicação, sem a necessidade de mágicas para não precisar de 2 logins.

Um fato que me surpreendeu até (já no Falando em Java 2008), foi quando o Fábio disse que a implementação JRuby está sendo considerada a implementação com melhor performance. Isso é muito legal, o que mostra o esforço grande para se obter alternativas à linguagem Java. E o melhor de tudo foi saber que já dá pra rodar o bichinho no Jetty, gerando a mesma produtividade encontrada na dupla Java/Jetty. O trabalho do Fábio foi tão fantástico no jetty_rails, que no RailsConf2008, Jeremy Kemper incluiu o jetty_rails em seu Keynote. O próprio Fábio falou sobre isso.

Pra concluir, apesar do JRuby on Rails e das novas oportunidades que irão surgir, o que mais me deixou feliz foi ver um projeto brazuca fazendo sucesso internacionalmente, no maior evento de Rails da atualidade.

Ontém tivemos a reunião mensal do RioJUG com a palestra de REST do Bruno Pereira. Mas pera lá, o que a Mundo Java tem a ver com a história? rs. Bem isso eu conto mais pra frente.

A palestra foi bem interessante e apesar de já conhecer REST, agente sempre aprende alguma coisa, sempre. Por isso que eu vou a diversos eventos, como por exemplo o Falando em Java 2008, que tinha algumas palestras que teoricamente não iriam acrescentar muito a mim, mas tem sempre alguma coisa que o palestrante fala que agrega, e as vezes muito.

A palestra do Bruno Pereira foi bem legal, explicando bem os conceitos do estilo arquitetural, falou um pouquinho do framework Jersey e deu bons exemplos de código. Quem não foi perdeu …

E a Mundo Java, heim? Bem vamos lá.

Quando saia da empresa para ir ao evento, comentei com um amigo o fato de eu nunca ganhar nada nesses sorteios de brindes que tem nos eventos (pronto, acabou o suspense :)). No Falando em Java 2008 eu queria ter ganho o Nintendo WII, mas infelizmente não deu :(). Então, voltando ao papo que eu estava tendo com meu amigo do trabalho, comentei que eu queria ganhar a assinatura da Mundo Java, pois é a publicação de Java que eu gosto mais aqui do Brasil.

O engraçado do sorteio é que o Guilherme Chapiewski deixou a assinatura Mundo Java por útimo e eu fiquei naquela espectativa por nunca ganhar nada nesses sorteios.

E o resultado foi …

QUE EU GANHEIIIIIIIIIIIII
Espero que agora que eu ganhei alguma coisa pela primeira vez eu consiga ganhar novamente em outras oportunidades.

Esses dias eu estava procurando um curso básico em informática para minha esposa, que nunca gostou de computador, mas já se convenceu que não dá mais pra correr, rs. Acontece que me deparei com um curso profissionalizante chamado Programador de Sistemas. Será que alguém aprende a ser um programador com 30 horas de lógicca, 30 horas de modelagem de dados, 45 horas de VB.Net (que provavelmente só vai ensinar Visual Studio.Net) e 45 horas de Delphi? (Meu Deus, Delphi em 2008?). É uma irresponsabilidade total criar um curso desses pra enganar pessoas dessa forma. Eu jamais daria um curso desses, sabendo que a coisa não é tão simples assim.

Sabe o que eu fico pensando disso tudo?

1. A coisa ta cada vez pior em termos de ensino para um programador
2. Coitado das pessoas que tão entrando nesses cursos e achando que sairão profissionais em programação
3. Mais e mais gente despreparada entrando no mercado
4. Mais projetos indo pro buraco
5. Os poucos que são bons ganhando cada vez mais (Parece bom, mas tem os efeitos colaterais, que é você ter dificuldade de arrumar um lugar legal pra trabalhar, visto que a quantidade de profissionais preparados está ficando cada vez menor)

Por que todo mundo acha que pode ser programador? Eu acho que se eu tivesse que ser médico, morreria de fome, pois só de olhar sangue já fico tonto. As pessoas tem talentos diferentes e programação não é aprender a usar ferramentas. Programação é criação. Criação é talento. Talvez eu não tenha talento pra criar uma logomarca, mas para criar um software sim. E outra pessoa o inverso, que seja.

Cada um na sua, por favor.