Uma palestra bem bacana na RubyConf foi dada pelo Bryan Helmkamp, daCode Climate. Sendo da CodeClimate, é obvio que falou de qualidade de código, assunto que tem tanta propriedade quanto o Bruno Cartolari da Vizir (hehe).

Um breve ponto sobre a CodeClimate: eles fazem análise estática de código para mais de 80000 repositórios e 1500 empresas.

E vamos as 6 questões apontadas como importante para a qualidade de código.

1. O que é qualidade de código?

Para definir o que é qualidade, vamos para o oposto do que é qualidade, vamos falar do famoso código legado. E o que é legado? Uma definição válida é o código de outra pessoa ou seu próprio código com mais de duas semanas.

Mas falando sério, o que é um bom código? Ele deve ser:
– Simples;
– Bem testado;
– Sem bugs;
– Claro para outro programador;
– Refatorado;
– Documentado, para alguns times isto é muito importante;
– Extensivel;
– Rápido, boa performance. Em determinados negócios não adianta ter testes, ser refatorado e ser lento!

É importante alinhar com seu time qual sua meta, o que você valoriza de qualidade. Afinal não vamos fugir do axioma do programador:

Qualquer código menos decomposto que o meu é uma bagunça… mais decomposto é over-engineer!

2. Qual a melhor maneira de medir complexidade?

Melhor forma de medir a qualidade do código, é o número de “What a Fuck” emitidos por minuto durante uma code review.

Mas falando sério, algumas formas de medir qualidade são:

Complexidade ciclomática;
Métrica ABC: medindo número assignments, branchs and conditions;
– Linhas de código;

E mais importante do que usar uma métrica, é usar uma métrica que faça sentido para seu time. E se não conseguir se decidir por uma, comece com as linhas de código. Sim, use linhas de código! Não para medir quanto você vai pagar para o programador, mas para analisar em nível micro o quão complexa está sua função ou sua classe.

3. Por que projetos antigos são mais difíceis de manter?

Todo mundo quer projeto novo, greenfield, sem código legado, com testes rodando em 3 segundos. Quando você pensa em um projeto novo, um termo usado em inglês para estes projetos é greenfield. Ao falar em green field você já pensa no fundo de tela do Windows, cenário de Teletubbies.

Mas o ruim de um “campo verde”, atrai vacas! E estas vacas somos nós. Deixando este campo marrom após algum tempo. E sempre com o sentimento, desta vez será diferente.

Mas o principal sentimento para causar merdas em código, é PRESSÃO! E pressão causa merdas. E estas merdas, atraso. Criando um círculo vicioso.

Por isso, é preciso aumentar a visibilidade do andamento do projeto, para que este ciclo vicioso seja identificado e interrompido. Mas, lembre-se, mais PRESSÃO, só produz código pior.

Outro fator importante é que a qualidade de código é um alvo em movimento, afinal o domínio de negócio evolui, se distanciando de seu código. Temos que escolher se vamos endereçar esta diferença entre domínio de negócio e código em grandes releases e de forma incremental.

Mas o importante é fazer o básico, como os escoteiros, deixe seu código em melhor condição melhor do que deixou.

4. Qual o tamanho ideal de um pull request?

Menos issues são achados em um pull request gigante. Isso será porque os PR grandes são melhores? Não, é porque quem está analisando acaba prestando menos atenção nos detalhes de PR gigantes.

Em alguns estudos, viram que os pull requests ideais tem menos de 400 linhas de código.

5. Que tipo de código você está fazendo?

Você está provando uma hipótese? Tenha em mente qual o objetivo do código, do negócio. Porque tem dois tipos de código: com testes de integração e os que dão lucro. Então, foco!

Fazer a primeira versão para jogar fora.
Quando você está descobrindo, é normal fazer algo sem saber direito para onde vai. Aproveite, aprenda sobre o negócio, sobre o problema. Mas cuidado! Porque muito deste código acaba indo para produção!

6. Qual o maior inimigo do código limpo?

Apatia dos programadores? Não.
Falta de Habilidade? Não, mesmo projetos com desenvolvedores capazes… e não tinham ideia de como mudar.
Requisitos mudando? é um fator, mas não necessariamente a causa.

Mas por que os projetos falham então? David Petersen identificou um pouco as causas.

E no fim ele identificou que MEDO é o maior inimigo da qualidade de código. Então é preciso reduzir o medo, e como podemos fazer isso:
– Testes automatizados.
– Métricas operacionais de desempenho do sistema.
– Revisão de código.
– Análise estática (vai lá CodeClimate).
– Pair programming.

E esperança de que vai dar certo não é um plano! Se quer diferentes resultados, precisa de um plano concreto de como vai reduzir o medo.

Foi muito boa a palestra. E que coisa né? Um cara que faz análise estática de código, nos fala que as causas principais de problema de qualidade de código são MEDO e PRESSÃO! Mas claro que programar direitinho também ajuda!

Post feito na RubyConf pelo time da Vizir no evento: Karen, André, Thiago, Sakuma, Saraiva, Iuji e Leonardo.