Como acabar com seu débito técnico!
Simples, rápido e direto
O débito técnico é uma das dores de cabeça que boa parte dos times de desenvolvimento de software terão que enfrentar em algum momento.
Agora vou te contar como acabar com o débito técnico! Parece mágica, mas não é!
O que você tem no seu software é DÍVIDA TÉCNICA! Não existe débito técnico! (pronto… acabei com o seu débito técnico).
Pronto! Acabei com o seu débito técnico!!!
Ainda me assusto com a quantidade de pessoas que erram este conceito. Alguns pensarão que quem erra são pessoas não ligadas diretamente a codificação. Pois bem, confira o gráfico abaixo e tome sua conclusão.
Conclusão: quase a metade das pessoas que trabalham com software de forma profissional (não somente devs), não conhecem o termo dívida técnica e/ou chamam de pelo nome errado. (dados de 22/09/2018).
Mas afinal, por que é dívida e não débito?
Ward Cunningham, desenvolvedor da primeira wiki, criou esta metáfora chamada Debt Metaphor. Nesta metáfora é feita uma co-relação entre a produção de um software com o mundo financeiro. Na produção de um software o desalinhamento entre a parte técnica e a equipe de gestão gera tropeços e atrasos constantes e isto é semelhante a pagar juros sobre um empréstimo, o que não é nada legal. (confira o vídeo abaixo)
Posteriormente esta metáfora começou a ser Technical Debt.
Eu gosto de fazer a analogia com uma ida ao restaurante. Ao final do almoço, eu posso pagar de duas maneiras :
- cartão de débito (onde o dinheiro já sai da minha conta corrente, sem dores futuras)
- cartão de crédito (onde eu vou ter que pagar daqui a 45 dias, ou seja, a dor ver depois).
E algo muito dolorido pode ocorrer se eu não pagar a fatura completa. Os juros veem de forma abusiva e sem piedade. E em software não é diferente. Quando o desenvolvedor escolhe não seguir as melhores práticas de programação e design isto gera dívida técnica e um dia ela precisa ser paga.
E por que tem muitos brasileiros que chamam esta metáfora de débito técnico?
Imagino que este erro ocorra por uma rápida e errada tradução do conceito Technical Debt . A tradução de debt é dívida e não débito e também imagino que muitos não tem o conhecimento da metáfora original (Debt Metaphor).
Sintomas que meu projeto tem dívida técnica
Alexandre Freire elenca alguns sintomas em sua palestra Dívida técnica: precisando de crédito?
- Demora para entregar software
- Baixa cobertura de testes
- Suite de testes que demora para ser compilada
- Projetos engessados
- Atraso nas entregas
E você pode considerar outras dependendo da história do seu projeto. Se você passou por dois pontos dos cinco acima listados, seu software tem dívida técnica e você deve dar atenção caso queira ser ágil.
Como pagar sua dívida?
Para começar a pagar uma dívida, todo consultor financeiro irá falar que você deve mapear todos os compromissos/dívidas já assumidos para descobrir o montante da dívida. Em software não é diferente. Você precisa calcular o montante de más práticas que o seu código fonte. Mas como fazer isto?
É necessário realizarmos uma inspeção do nosso código fonte. Isto é chamado de análise estática do código fonte. Existem diversas ferramentas para isto e a mais conhecida é o SonarQube. A cada ciclo de construção de um software (build) é possível fazer uma inspeção do código e termos uma noção do que está ruim ou não.
O SonarQube serve para diversas linguagens de programação e ele mostra exatamente qual foi a má prática e sugere possíveis correções.
Dica: cuidado para não tomar tudo o que o SonarQube sugere como verdade soberana. Estude para entender e ter discernimento se o que o SonarQube informa realmente faz sentido. Se apoiar numa ferramenta cegamente é perigoso.
Certo. Agora já fiz a inspeção do código fonte e sei como está o meu projeto. E agora, qual o próximo passo?
Vamos voltar a nossa metáfora financeira. Um consultor financeiro, em posse dos dados que revelam o tamanho da dívida, irá refletir e sugerir algumas ações. Uma delas é solicitar o fim do uso de produtos (como o cartão de crédito) que trazem juros abusivos.
Para o software não é diferente. Você deve parar de cavar mais o buraco que você e seu time criaram no código fonte (metáfora do buraco).
Se o time parar de aumentar a dívida técnica é um ganho surpreendente. E com o passar do tempo, o time deve começar a pagar a dívida técnica.
A escolha do que começar a pagar, depende de cada projeto, mas nunca saia pagando dívida técnica sem ter um TESTE UNITÁRIO que garanta que tudo irá continuar funcionando.
nunca saia pagando dívida técnica sem ter um TESTE UNITÁRIO que garanta que tudo irá continuar funcionando.
Mas quem pode me ajudar a saber se eu to colocando mais dívida técnica ou não no software? O SonarQube só executa após eu “commitar” o código!
Além do SonarQube (que ficará num servidor específico e ligado a uma base de dados), o ideal é que você utilize de linters que são extensões de IDES (ou podem ser softwares externos) que irão analisar o código fonte em tempo real. Ou seja, o ciclo de feedback de uma possível má prática é dado em tempo real, ajudando a pessoa desenvolvedora a não acumular dívida técnica.
Existem diversos linters. Eu costumo sugerir utilizar o SonarLint.
Rafael Alburquerque Rasso, apresentou os benefícios de utilizar SonarQube e SonarLint em projetos de software na trilha XP, do evento The Developer Conference 2018, em São Paulo. Confira os slides abaixo.
É possível zerar a dívida?
Sim, é possível!!! Não é utopia!!! Já vi duas vezes!!!!
Em ambos os cenários, o software começou com os desenvolvedores usando TDD e ambos tinham ciência de buscar um software sem dívida técnica. Um dos projetos é do Walmyr Filho (https://sonarcloud.io/dashboard?id=age-discoverer) e o outro é do Tiago Henrique Bono.
Mas a grande maioria dos projetos de software já tem anos de vida e não começou por TDD e com pessoas que buscavam a qualidade do código fonte. Neste cenário é muito difícil zerar a dívida. O conselho que deixo é gradativamente reduzir a dívida técnica seguindo estes passos (de forma sequenciada ou não, avalie o seu cenário):
- aumento da quantidade de testes unitários em regras de negócios
- aumento da quantidade de testes unitários para cada correção abaixo mencionada.
- correção de bugs de código fonte (ver conceito do SonarQube em https://docs.sonarqube.org/display/SONAR/Concepts)
- correção das vulnerabilidades (ver conceito do SonarQube em https://docs.sonarqube.org/display/SONAR/Concepts)
- correção de code smells (ver conceito do SonarQube em https://docs.sonarqube.org/display/SONAR/Concepts)
- redução da complexidade ciclomática,
- redução de código duplicado
- redução de comentários desnecessários
E tome muito cuidado, saiba discernir tanto o tempo necessário como o risco de negócio para pagar dívidas técnicas em projetos legados.
Update (16/10/2021)
Em 2019 estive falando desse tema no Agile Brazil. Confira o vídeo da palestra em https://www.youtube.com/watch?v=IZhRHHcQGfc&t=6s
