Desenvolvedores Frágeis. Você é um deles?

O discurso de métodos ágeis nunca esteve tão popular no Brasil. Isto é muito bom e demonstra que estamos questionando os clássicos métodos da engenharia de software estabelecidos ainda no fim dos anos 60 nas famosas conferências de engenharia de software da OTAN.

É lamentável, entretanto, que pessoas sem as mínimas noções de engenharia de software e muito menos de métodos ágeis levantem bandeiras como se fossem do seu time de futebol ou partido político preferido por simplesmente desconhecer e não aplicar técnicas ágeis.

Baseado nas essências de técnicas ágeis sólidas de métodos como o XP e a Entrega Ágil Disciplinada, coloquei aqui um teste de fragilidade técnica. Notas baixas indicam um desenvolvedor pseudo-agilista que carrega uma bíblia mas sem saber nem o pai-nosso e a ave-maria de cada dia.

Teste de Fragilidade – Proibido para garotos enxaquecas que somente reclamam da vida, do chefe e do governo…

Para cada resposta A, some 3 pontos.
Para cada resposta B, some 2 pontos.
Para cada resposta C, some 1 ponto.
Para cada resposta D, não some pontos.

  1. O código fonte é o ativo mais importante resultante do trabalho do seu dia a dia. Você cuida dele apropriadamente? Se sim, quantas vezes por semana você aplica técnicas de refatoração sobre ele?
    1. 5 vezes. [Dou banho todo dia no meu código e observo métricas de qualidade de código como complexidade ciclomática com rigor]
    2. 3 ou 4 vezes [Ok. Às vezes me esqueço de dar banho no meu código.]
    3. 1 ou 2 vezes [Então. Sou meio porquinho e não gosto muito de tomar banho e não me importo com o mau cheiro dos meus códigos também.]
    4. 0 vezes [Refatoração? O que é isso?]
  2. Defeitos são indesejados e podem ser comparados a resíduos industriais de empresas ou baratas em esgotos. Você tem disciplina de testes de desenvolvimento? Se sim, quantas vezes por semana você cria testes de unidade e executa testes de regressão sobre o seu código?
    1. 5 vezes. [Piso em toda barata que vejo na rua! Portanto só saio do escritório com o teste de regressão executado com sucesso.]
    2. 3 ou 4 vezes [Sou atento e gosto de fazer testes de unidade mas às vezes falho para executar smoke testes e testes de regressão no fim do dia]
    3. 1 ou 2 vezes [Então. Sou meio preguiçoso para criar testes de unidade. Gosto de inventar desculpas e acho que isso é problema dos analistas de testes chatos que só fazem pegar no meu pé]
    4. 0 vezes [Regressão? Tem a ver com vidas passadas, certo?]
  3. Desenvolvedores normalmente trabalham em times e criam projetos através de repositórios como SVN, Microsoft TFS ou GIT. Quantas vezes por semana você tem contato com o seu repositório SCM?
    1. 5 vezes. [Desço e subo código todo dia, conheço e uso padrões SCM com excelência.]
    2. 3 u 4 vezes [Ok. Ás vezes deixo o meu código na minha máquina antes de ir embora para casa. Gosto de viver emoções fortes]
    3. 1 ou 2 vezes [“I’m a cave man. I’m a jungle man. A young man. A young man. I fight with my hands….”, Homem Primata, Titãs, Cabeça de Dinossauro.]
    4. 0 vezes. [SVN? Isso é marca do novo isotônico, certo?]
  4. Desenvolvedores normalmente trabalham em linguagens OO como Java, C# ou mesmo em linguagens híbridas OO-Procedural como C++ ou PHP. Quantas vezes por semana realizo modelagem ágil e organizo apropriadamente o meu modelo de classes executável?
    1. 5 vezes [Conheço padrões de análisepadrões de desenho e padrões GRASP e os uso com parcimônia sobre os meus códigos. Além disso, faço junto do meu time diversas sessões de modelagem com o uso de quadro branco]
    2. 3 ou 4 vezes [Gosto e aplico sessões de modelagem ágil, mas ainda não conheço plenamente técnicas de padrões e modelagem]
    3. 1 ou 2 vezes [Veja bem, a minha empresa não tem quadro brancos, nem cartolinas, nem papel, nem caneta? O que posso fazer?]
    4. 0 vezes [Comunicar com outros seres humanos em sessões de modelagem? Não, obrigado. Programar para mim é uma atividade individual. A propósito, o que é parcimônia mesmo?]
  5. Times ágeis entregam software funcionando em pequenos incrementos para os seus usuários com o uso de técnicas como integração contínua ou entrega contínua. Quantas vezes por semana você gera produtos potencialmente demonstráveis (Alfas ou Betas) para o seu Product Owner, Analista de Negócio ou cliente.
    1. 5 vezes. [Me espelho em projetos como a IDE Eclipse, que tem quase 50 milhões de linhas de código, é construído de forma distribuída no mundo inteiro e ainda assim gera produtos em base diária]
    2. 3 ou 4 vezes [Gosto de liberar produtos com frequência para demonstração para o PO, mas tenho dificuldades em fazer isso e às vezes falho]
    3. 1 ou 2 vezes [Estou começando a aplicar esta técnica, mas ainda tenho um longo caminho para trilhar neste aspecto.]
    4. 0 vezes [Veja bem. Na minha empresa tudo é impossível fazer isso e além disso você já sabe que gosto de inventar desculpas para enrolar no meu trabalho, não é]
  6. A priorização de requisitos e o cumprimento de acordos das metas dos sprints e metas diárias é parte indissociável de todo desenvolvedor ágil? Quantas vezes por semana você conversa com o seu time para reportar as metas diárias, impedimentos e o progresso em relação às metas semanais.
    1. 5 vezes [Faço stand-up meetings faça sol ou faça chuva. Cumpro religiosamente as minhas metas diárias e reporto impedimentos imediamente quando os mesmos surgem]
    2. 4 vezes [Ainda não tenho tanta disciplina e às vezes falho em cumprir minhas metas diárias e em me comunicar com o meu time.]
    3. 1 ou 2 vezes [Então. Tenho dores de barriga com frequência, estudo à noite e minha namorada fica me ligando toda hora. Não tenho tranquilidade para produzir código e portanto falho as minhas metas com frequência]
    4. 0 vezes [Já não te disse que não gosto de conversar com outros seres humanos!! *$*##&@)# ]
Se você fez 15 ou mais pontos, parabéns, você é realmente ágil. Continue assim.
Se você fez entre 10 e 14 pontos, você já compreendeu os princípios ágeis, mas ainda precisa se disciplinar e disciplinar o seu time.
Se você fez entre 5 e 9 pontos, sinto lhe informar que você é tão ágil quanto uma sucuri que acabou de comer uma paca de 40 kilos. É hora de acabar com a nhem-nhem-nhem e aplicar técnicas ágeis para valer.
Se você fez até 4 pontos, você é definitivamente frágil e precisa estudar seriamente os princípios e técnicas ágeis antes de sair por aí fazendo propaganda de métodos ágeis.

Simplicidade na Integração de Aplicações

Integrar aplicações em diferentes tecnologias, plataformas ou sistemas operacionais pode ser um formidável desafio a desenvolvedores e arquitetos. Observo nas empresas códigos muito desorganizados e muita confusão quando o assunto é integrar aplicações. Compilo neste post um pequeno padrão arquitetural para ajudar a resolver problemas de integração.

Conheça o padrão VETRO

Vamos aprender a usar este padrão em um exemplo fictício onde precisamos buscar os dados de um determinado cidadão do sistema da receita federal e gravar estes dados em um banco de dados local em formato SQL.

1. VALIDAR. 

O primeiro passo recomendado de toda integracão é realizar a validação dos dados recebidos. A validação pode verificar se o objeto de dados (um esquema XML ou texto JSON) está bem formado.

Como os dados são gerados por aplicações externas, é sempre boa prática “desconfiar” dos dados que estão sendo recebidos, pois eles podem ter sido modificados na estrutura de negócio ou no formato técnico sem aviso prévio.

No exemplo dado, poderíamos checar se a mensagem XML com os dados de um cidadão estão em conformidade com o esquema XSD esperado.

2. ENRIQUECER

O termo enriquecer tem por objetivo adicionar dados adicionais ao pacote de dados recebido. Muitas vezes isso é necessário para que o pacote de dados esteja compatível com o formato esperado pelo destinatário.

No exemplo dado, poderíamos enriquecer a mensagem XML com os dados do cidadão com a informação do login do usuário que esteja usando a aplicação. Estamos considerando que esta informação nova poderia ser usada para auditoria

3. TRANSFORMAR

O próximo passo é realizar a transformação dos dados (seja no formato dos dados ou protocolo técnico). No nosso caso, queremos extrair da estrutura XSD e colocar em um formato universal da plataforma que estamos usando.

Por exemplo, se estivéssemos escrevendo estes códigos em Java ou C#, poderíamos criar um objeto POJO ou POCO com os dados do cidadão enriquecidos com o login do usuário.

4. ROTEAR

Agora estamos próximo do fim e neste passo estamos fazendo o roteamento da informação para o seu destino. No nosso caso, iremos abrir a conexão (IP e porto) com o banco de dados onde iremos salvar o nosso POJO ou POCO com os dados do cidadão.

Em cenários mais elaborados, o roteamento pode envolver rotas complexas.

5. OPERAR

Finalmente, iremos gravar os dados no banco de dados. O passo operar implica em entregar a informação para o destinatário final e terminar a rotina de integração.

O padrão VETRO pode ser implementado através do padrão de desenho cadeia de responsabilidades em Java ou C# e curiosamente forma a base de vários produtos de ESB do mercado. Em projetos SOA, chamamos estas lógicas de serviços de mediação, que também possuem a mesma estrutura básica.

Independente da tecnologia ou plataforma, entretanto, organizar um código desta forma nos fornece limpeza semântica e boa organização em lógicas de integração.

Boas integrações!

Desenvolvedor, dê banho no seu código diariamente

Na idade média, a noção do banho diário era considerada uma blasfemia e foi até mesmo reprimida pela igreja. Nos dias atuais, felizmente,  a maior parte das pessoas toma pelo menos um banho por dia. No Brasil, vemos até cachorros tomando banho frequentemente, o que é muito bom pois cães que não se banham tem um cheiro péssimo. (humanos também, aliás).

Quando olhamos códigos Java, C# ou PHP nas empresas, entretanto, parece que voltamos à idade média. Vemos funções com 500 linhas de código, o uso indiscriminado de colar e copiar ou o uso abusivo de switch-cases . Imundíceis de toda sorte, documentadas na literatura especializada como  bad smells. Livros clássicos como Code Complete – Steve McConnell; Refactoring – Martin Fowler ou Clean Code – Robert Martin apresentam e documentam práticas para banhar e deixar o seu código limpinho e sexy.

Apesar disso, ainda parece difícil adotar uma boa prática como a refatoração de código e internalizá-la no seu dia a dia de programação.

Como criar o hábito da refatoração no seu código?

A prática de refatoração já é documentada há muito tempo na literatura, mas muitos desenvolvedores ainda não aderiram ao hábito por motivos diversos. Se você é um deles, recomendo quatro práticas simples para formar o hábito da refatoração diária.

  1. Comece muito leve.
    Que tal se você se dedicar a refatorar o seu código 1 minuto por dia? Você consegue fazer isso amanhã? Não parece muito, certo?Em verdade o ponto mais importante para o desenvolvimento de um hábito é a repetição de uma prática. Em um minuto, talvez você somente consiga aplicar o padrão Extract Method com o Eclipse ou o Visual Studio, mas isso já é ótimo. É um pequeno banho. Repetir o processo todo o dia irá gerar formar um senso de repetição, que é para mais importante para formar um hábito.
  2. Vigie as suas conversas internas.
    A nossa mente, inconscientemente, pode criar conversas internas sobre o quão difícil a refatoração pode ser. Vigie seus pensamentos e os interrompa o mais rápido possível. Se você deixar as conversas internas ganharem corpo, elas irão racionalizar o mal hábito de não refatorar o seu código em base diária.
  3. Em caso de falha, implemente um plano de ataque
    Talvez você se esqueça de refatorar o seu código em algum dia. Neste caso, você deve ter um plano de ataque para refatorá-lo no dia seguinte custe o que custar. Se você ficar três dias sem dar banho no seu código, o hábito pode ir embora e o seu código voltará à idade das trevas.
  4. Se orgulhe do seu código limpinho
    Um código refatorado tem métricas de qualidade superiores, tem melhor legibilidade e irá gerar menos defeitos que um código porquinho. Se orgulhe disso e saboreie o momento da refatoração. Afinal, o código é a sua criação e você não quer que o seu filhinho seja porquinho, quer?

Para os mais curiosos, recomendo a leitura do livro The Clean Coder, do Robert Martin, que apresenta e discute a atitude do desenvolvedor moderno, que considera o banho diário uma prática bacana (para si mesmo e para o seu código).