O desafio do “código limpo”

Como determinar que “dívidas técnicas” pagar primeiro?

Dívidas técnicas de naturezas similares podem ter impactos muito diferentes na produtividade dos times de desenvolvimento. Por isso, iniciativas ingênuas para “pagar” a maior quantidade de dívidas técnicas, sem critério claro de priorização, embora bem intencionadas, acabam não produzindo, muitas vezes, resultados perceptíveis na redução da complexidade.

As dívidas técnicas e a complexidade tem muito mais impacto nas partes do código que são alteradas com maior frequência. Trechos de código, mesmo mal escritos,  que não sofrem alterações frequentes ao longo do tempo estão “estáveis”. Refactoring nesses trechos de código acabam tendo pouco impacto para a redução dos custos e dos prazos. Além disso, aumentam consideravelmente as chances de novos bugs.

No gráfico acima, podemos ver que há clara concentração de commits em uma parcela muito pequena de arquivos no projeto do servidor do RavenDB, por exemplo. Um arquivo, apenas, recebeu 3% de todos os commits. Mais de 50% dos commits envolveu menos de 10% de toda a base de código. Parece evidente que as dívidas técnicas presentes nesses arquivos acabariam tendo impactos muito mais altos para a produtividade do time. Também parece lógico que o código desses arquivos fosse aquele com maior cobertura por testes automatizados.

A distribuição de commits encontrada na base de código do servidor do RavenDB é comum a quase comum a quase todas as bases de código, segundo Adam Tornhill (que tem influenciado muitas das nossas ideias sobre como tratar dívidas técnicas). Logo, os mesmos insights são aplicáveis a quase todos os projetos.

Os “juros” das dívidas técnicas e da complexidade ficam ainda mais evidentes nas partes do código mantidas por muitas pessoas. Afinal, código ruim, alterado frequentemente por muita gente fica ainda mais difícil de entender e, consequentemente, impacta muito a produtividade.

Mais uma vez, é fácil verificar que poucos arquivos são alterados por muitas pessoas. Geralmente, inclusive, há uma correlação de proporcionalidade entre número de commits que um arquivo recebe e o número de programadores trabalhando nesse arquivo.

Dívidas técnicas são ruins. Porém, algumas são piores do que outras. Nesses tempos em que temos prazos cada vez mais curtos e pressão cada vez maior para entregar mais features, temos que ser inteligentes na seleção de que trabalho gera mais resultado.

Em Resumo
  • O problema

    Dívidas técnicas e complexidade aumentam, com o tempo, o lead time das entregas para os times de negócio. Por isso, são comum as iniciativas para combate-las. Infelizmente, entretanto, muitas vezes os benefícios esperados acabam não aparecendo.
  • O insight

    Dívidas técnicas de naturezas similares podem causar impactos muito diferentes. Na prática, deveríamos priorizar as dívidas técnicas em trechos de código alterados com mais frequência e mantidos por mais pessoas. Afinal, essas são as dívidas técnicas com mais potencial de gerar mais impacto no lead time.
  • Os benefícios

    O critério de priorização proposto direciona esforços e investimentos para iniciativas de melhoras de código entregando benefício real para o negócio.

Elemar Júnior

Microsoft Regional Director e Microsoft MVP. Atua, há mais de duas décadas, desenvolvendo software e negócios digitais de classe mundial. Teve o privilégio de ajudar a mudar a forma como o Brasil vende, projeta e produz móveis através de software. Hoje, seus interesses técnicos são arquiteturas escaláveis. bancos de dados e ferramentas de integração. Além disso, é fascinado por estratégia e organizações exponenciais.

Talvez você goste também

Carregando posts…

Mais posts da série O desafio do “código limpo”

2 Comentários
  1. Jeferson Viana Perito

    eu fiz uma relação code churn (alterações no arquivo) e complexidade cognitiva (https://www.sonarsource.com/resources/white-papers/cognitive-complexity.html) para acharmos um note em qual arquivos devemos priorizar a refatoração:

    1. Elemar Júnior

      Excelente abordagem. 🙂

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *