
Usando palavras certas para um code review mais efetivo — Parte 2
Melhore a comunicação do seu time com anti padrões e potencialize códigos versionados com qualidade
Na minha última postagem, estive compartilhando um pouco do meu conhecimento sobre anti padrões de programação e como você pode usar palavras chaves para ter um code review mais efetivo.
Para retomarmos o assunto vamos relembrar a definição de anti padrão:
Anti padrão (ou anti-pattern) é uma ação comumente usada, mas sendo ineficiente e/ou contra-produtivo na prática
Nesta postagem, vou detalhar como identificar o anti padrão e pequenas ações para corrigi-los. Meu desejo é que você consiga identificar estes novos anti padrões em seu trabalho e na sua equipe e que planos de ações possam ser gerados para que estes venham ser mitigados. Isto irá resultar em produção efetiva de software.
Então vamos a mais uma listagem de anti padrões:
Reinventar a roda
Quando usar: quando você perceber que um desenvolvedor está criando algo que já existe no sistema ou em algum framework já utilizado no projeto.
Como detectar: num code review ou reunião diária ou quando o desenvolvedor está utilizando um tempo demasiado para um problema de solução considerada rápida.
Como resolver: alertar o desenvolvedor sobre a existência da funcionalidade pronta no sistema ou de um framework que possa ser utilizado para aquele fim.
Reinventar a roda quadrada

Quando usar: quando o desenvolvedor insiste na solução de um problema a qual já foi informado que é para seguir por outro caminho
Como detectar: da mesma forma que o anti padrão reinventar a roda, mas com agravante de horas consumidas de forma desnecessária
Como resolver: alinhar de forma clara com o desenvolvedor o não prosseguimento da demanda e se possível realizar pareamento (pair programming) evitando a produção de solução inválida.
Magic Pushbutton
Quando usar: quando a coesão do código estiver sendo violada devido a existência de código fonte de lógica de negócio em telas do sistema.
Como detectar: num code review, ao encontrar programação em telas.
Como resolver: realizar refatoração do código, encapsulando a lógica de negócio em classes. Com isto aumentando a coesão do código fonte.
Overengineering

Quando usar: quando uma alteração está além do que o esperado.
Como detectar: num code review, ao encontrar código fonte implementado de forma desnecessária. Ou quando uma funcionalidade é apresentada ao usuário-chave e ela está muito além do solicitado, inviabilizando o uso da mesma.
Como resolver: realizar pequenos ciclos de apresentação com o usuário (ou product owner ou analista de negócios) para validação da geração de valor no que está sendo desenvolvido. E realizar programação em par para garantir a consistência do que está sendo desenvolvido.
Software inchado

Quando usar: quando perceber que existem versões sucessivas do mesmo código fonte e que estão exigindo mais recursos de processamento.
Como detectar: num code review (analisando a complexidade do código fonte ou adição de testes unitários com validações que violam o desempenho) ou quando se percebe demora no build da aplicação.
Como resolver: refatoração do código fonte, para que o desempenho retorne ao esperado.
Nas próximas postagens compartilharei outros anti padrões referente a práticas ágeis e comportamento de times.
Caso você tenha alguma experiência ou relato, compartilhe a sua história para que possamos aprimorar o conhecimento do tema.
Referências de imagens:
http://cfile25.uf.tistory.com/image/2546494157B7A6F01E7384
http://besawa.com/wp-content/uploads/2014/01/overengineered-header-333x250.jpg
https://www.pagerduty.com/wp-content/uploads/2017/04/bettercodereview-1024x485.png
http://www.escolaedti.com.br/wp-content/uploads/2013/06/roda-quadrad.jpg
