Débito técnico é um desafio para muitas pessoas desenvolvedoras. Para compreender o porquê, vamos revisitar a literatura científica na área para entender, certamente, qual o impacto negativo na qualidade de código de devs. Confira!
O que é débito técnico?
Em primeiro lugar, é importante dizer que o termo refere-se ao uso de soluções subótimas como forma de alcançar um objetivo de curto prazo, porém com o impacto de comprometer a manutenção e evolução do software por um longo período.
O termo, cunhado por Ward Cunningham em 1992, é uma analogia ao débito financeiro que, se não for pago, pode acumular “juros” que, no caso do código, pode ser visto como a dificuldade de implementar mudanças.
Assim, um débito técnico pode ser introduzido tanto conscientemente, por exemplo, para conseguir fazer uma entrega no prazo; quanto inconscientemente, como por conta da falta de domínio técnico ou de negócio.
Independente da forma como foi introduzido, estudos relatam que, na presença de débitos técnicos, pessoas desenvolvedoras tendem a colocar mais esforço nas suas tarefas de codificação para que elas sejam capazes de continuar entregando software na qualidade e velocidade esperadas.
Embora existam ferramentas, técnicas e processos que ajudam a identificar a ocorrência de débitos técnicos no código, como o SonarQube, linters, e até mesmo o design de código do CDD, o fato é que é incomum encontrar produtos de software livres de débito técnico.
Sabendo que existem diversos níveis de débitos técnicos, como na arquitetura, nos requisitos, no código, nos testes, etc., o acúmulo de débito técnico nos produtos de software pode ser crítico, por exemplo, para sua evolução.
Dados e impactos
Aliás, você sabia que em média 36% do tempo de pessoas desenvolvedoras é gasto por conta de débito técnico?
O estudo conduzido por Terese Besker e seus colegas propôs um questionário respondido por 258 pessoas desenvolvedoras de software, seguido por um conjunto de 32 entrevistas com outro grupo de pessoas desenvolvedoras de sete empresas, como forma de validar os resultados obtidos pelo questionário.
Dentre os achados deste trabalho, foi estimado que:
- cerca de 36% do tempo de pessoas desenvolvedoras é gasto lidando com débito técnico dos sistemas;
- aparentemente, o tempo gasto lidando com débito técnico é maior em produtos de software mais antigos (com mais de 20 anos, é estimado 40,5% do tempo) do que em produtos mais novos (com menos de dois anos, estimado em 33,8% do tempo);
- pessoas mais avançadas na carreira tendem a perceber bem mais o tempo gasto lidando com débito técnico. Por exemplo, pessoas que se caracterizavam como arquitetas ou especialistas, observam, na média, 41% do tempo gasto lidando com débito técnico, enquanto pessoas com o perfil mais júnior estimaram em cerca de 35%.
Débitos técnicos arquiteturais
Em um outro trabalho, também conduzido por Besker e colegas, um novo questionário foi administrado e respondido por profissionais de software.
Nesse questionário, foi solicitado que quem o respondeu pudesse priorizar quais dos débitos técnicos arquiteturais possuem o maior impacto negativo no processo de desenvolvimento de software.
A lista de débitos técnicos arquiteturais tinha 11 itens, variando de design de arquitetura complexo, código com débito técnico, documentação com débito técnico, dificuldade de reuso, dentre outros.
A tabela a seguir, retirada do artigo, retrata como participantes do questionário priorizaram o nível de impacto de cada um dos tipos de débito técnico arquiteturais.
| Débito técnico arquitetural | Média |
| Design de arquitetura complexo | 7.27 |
| Requisitos | 7.23 |
| Código de teste | 6.80 |
| Código de produção | 6.36 |
| Documentação | 5.98 |
| Muitos padrões e políticas | 5.76 |
| Violação de dependências | 5.71 |
| Infraestrutura | 5.59 |
| Dificuldade de reuso | 5.38 |
| Dependências externas | 5.19 |
| Débito técnico social | 4.73 |
Como é possível observar, débitos técnicos arquiteturais que estão relacionados à complexidade da arquitetura, dos requisitos e de código de teste foram percebidos como aqueles que têm o maior impacto negativo.
Além disso, foi questionado o tempo que as pessoas desenvolvedoras perdem por conta dos débitos técnicos arquiteturais, a resposta foi que o tempo máximo gasto por conta do débito técnico foi de 41%, enquanto que o tempo mínimo foi de 30%.
Propensão a bugs
Por fim, o estudo conduzido Sultan Wehaibi, Emad Shihab e Latifa Guerrouj investigou o código fonte de cinco projetos open-source da fundação Apache (Hadoop, Spark, Cassandra, Tomcat e Chromium) na tentativa de identificar débito técnico que foi autoadmitido pelos contribuidores do código.
Um débito técnico autoadmitido (do inglês “self-admitted technical debt” ou abreviado como SATD) ocorre quando pessoas desenvolvedoras deixam instruções no código que indicam que algo precisa ser melhorado (como comentários do tipo “TODO” ou “FIXME”).
Dentre os principais achados desse estudo é que uma vez que arquivos que contém instruções de SATD são mais propensos de receber commits com a intenção de resolver bugs.
Ainda no estudo, a equipe avaliou se arquivos com SATD são mais difíceis de modificar (em termos do tamanho da mudança, a nível de linhas de código e da quantidade, e de diretórios e arquivos modificados em conjunto) do que arquivos sem SATD.
Como resultado desta análise, constatou-se que arquivos com SATD tendem a ser mais difíceis de serem modificados, visto que estes arquivos requerem um grupo maior de mudanças.
Débito técnico na Zup
Sabendo que débito técnico não é algo que queremos no nosso projeto, o time de pesquisa da ZupEdu conduziu um estudo para tentar entender de que forma zuppers gerenciam e priorizam o débito técnico. O que será que descobrimos?
Quem participou desse estudo?
Para conduzir esse estudo, criamos um questionário on-line que foi compartilhado pelos canais de comunicação internos da Zup. No entanto, a resposta não era obrigatória e um total de 117 zuppers responderam.
Deste grupo que respondeu a pesquisa, cerca de 72% se identificou como pessoa desenvolvedora, enquanto 14% como tech lead. Por outro lado, outros perfis como DevOps, QA, Data Analytics, etc., também responderam o questionário, mas em menor proporção.
Cerca de 29% trabalha de um a três anos com desenvolvimento de software. Outros 25% tem até 10 anos de experiência e 46% tem mais de 11 anos de carreira.
Em termos dos projetos, cerca de 33% indicou que trabalha em bases de código entre 10 mil e 100 mil linhas de código. Por outro lado,14% trabalha em bases de 100 mil até 1 milhão de linhas de código – 27% não soube informar. 64% contou que a base de código dos seus produtos tem até 5 anos de idade.
Características e gerenciamento do débito técnico
Quando perguntamos se conheciam o termo, 88% indicou que sim; enquanto 5% revelou que conhece, mas por outro nome; e somente 7% não conhecia o termo.
Não obstante, para cerca de 70% das pessoas que responderam, a falta de consciência do débito técnico do projeto é um problema.
Em seguida perguntamos, na percepção de zuppers, quais são os impasses que poderiam estar associados ao débito técnico. Os cinco mais citados foram:
- Questões associadas à baixa qualidade interna, como manutenibilidade e reusabilidade (91 votos; 78%);
- Código mal escrito e que viole regras de código(80 votos; 68%);
- Problemas arquiteturais, como violação de modularidade (76 votos; 65%);
- Presença de defeitos conhecidos e não corrigidos (72 votos; 61.5%);
- “Atalhos” tomados durante o design (67 votos; 57.3%).
*Importante salientar que era possível escolher mais de uma opção.
Dentre as estratégias utilizadas para identificar débitos técnicos, destacaram-se:
- “[uso de] documentação de decisões e desenhos técnicos”;
- “[uso de] Code Review e Refinamento Técnico”;
- “[o débito técnico] É relatado durante os planejamentos das sprints”.
Causas que podem levar ao aumento débito técnico
Perguntamos para zuppers quais são as causas que podem levar ao aumento do débito técnico na base de código. As cinco principais razões foram (da mais votada para a menos votada):
- Fatores externos: pressão, cliente não escuta ou não sabe o que quer, dependência de serviços externos.
- Infraestrutura: escolha de tecnologias, ferramentas, ambientes e plataformas inadequadas. Uso inadequado do ambiente da plataforma. Ambiente instável.
- Metodologia/Processos: falta de processos bem definidos, documentações incompletas, falta de refatoração, falta de code review, problemas com etapas de teste, falta de governança, falta de pair programming, falta de validação e falta de controle de mudança.
- Organizacional: falta de pessoas qualificadas no time, falta de treinamento, falta de um time focado para o projeto, índices altos de saída de pessoas do time, falta de documentação e time sobrecarregado.
- Planejamento e Gerenciamento: cumprimento de deadline, planejamento incorreto, falhas no gerenciamento do projeto, falha na estimativa do tempo de entrega, falha na estimativa de riscos, foco na produção e não na qualidade.
Uma vez que entendem as causas, o próximo passo é gerenciar o débito técnico. Observamos que, para cerca de 48% do público, lidar com as consequências do débito técnico pode consumir boa parte dos recursos do projeto (como tempo e esforço).
Além disso, podemos observar que, para 71%, admitir débito técnico no projeto é estratégico para apoiar os objetivos de negócio. Curiosamente, quando perguntamos se o débito técnico é, em sua maioria, uma preocupação do negócio, apenas 30% confirmou. Para 72% das pessoas consultadas, o débito técnico é, em sua maioria, uma preocupação do desenvolvimento.
Existem processos?
Também perguntamos se, no time, existe algum processo para gerenciar o débito técnico, mesmo que parcialmente. Dentre algumas ações de gerenciamento, destacaram-se:
- “Os débitos técnicos são gerenciados através do Product Backlog, e só após as discussões macro do negócio que alguns deles passam para o Sprint Backlog, onde mais uma vez será discutido o que será priorizado, porém todos serão executados”.
- “O registro e mapeamento de débitos técnicos, reuniões para falar sobre eles e planejamento de história para atuar em cima deles”.
- “Sempre são criadas issues no próprio projeto/repositório no Github, as quais podem ser discutidas/solucionadas de acordo com a disponibilidade do time.”
Prioridade?
Por fim, questionamos zuppers se o débito técnico deveria ser priorizado como as demais atividades do processo de desenvolvimento de software.
Observamos que cerca de 30% concordou com a afirmativa, enquanto que 44% não concordou – 26% não soube informar. Daqueles que utilizaram estratégias de priorização, mencionaram:
- “Quando afeta entrega de valor”;
- “Quando o débito técnico impacta uma nova solução desenvolvida”;
- “O principal critério é o impacto em clientes. Quanto mais o débito técnico dificulta a usabilidade e experiência de clientes, maior será a prioridade em resolvê-lo”.
Conclusão
Para resumir, o Débito técnico é sabidamente uma vulnerabilidade da pessoa desenvolvedora de software. Neste artigo, resumimos três pesquisas científicas e a nossa experiência na Zup que descrevem o impacto do débito técnico em diferentes frentes do processo de desenvolvimento.
Existem ainda diversas abordagens para lidar e mitigar esses débitos técnicos, no entanto, essas ficarão para um futuro texto.
Por ora, conte pra gente nos comentários se você também precisa lidar com débito técnico regularmente! ?
