Se você trabalha com desenvolvimento de software há algum tempo, já deve ter esbarrado em processos ineficientes ou no temido acúmulo de dívida técnica. Esses dois fatores, quando não bem gerenciados, impactam diretamente na qualidade do produto, na velocidade das entregas e até na motivação do time. No artigo de hoje vamos entender como lidar melhor com esses desafios.

O que caracteriza um processo ruim no desenvolvimento de software?

Um processo ruim não é necessariamente aquele que toma tempo ou parece burocrático demais. Para Bruno Rocha, Principal Engineer na Red Hat, “Um processo ruim é aquele que não melhorou a qualidade ou a velocidade de entrega e é adotado por motivos arbitrários, como opiniões pessoais ou conveniência”. 

Muitas vezes, o time pode considerar um processo como "chato", mas ele pode ser essencial. Um exemplo é a triagem de bugs ou o refinamento de critérios de acessibilidade. São etapas que podem parecer tediosas, mas que, na prática, são importantes para a entrega do software com qualidade. O que devemos considerar é: se ele não gera valor para o time ou para o cliente, está na hora de repensá-lo.

Para Rodrigo Miguel, VP de Engenharia do Asaas, um processo ruim pode acontecer de diversas maneiras, destacam-se três:

1. Um processo sem revisão de código, sem revisão de pares, sem que uma segunda pessoa olhe e troque ideias sobre a maneira como foi implementado;

2. Quando o dev não tem responsabilidade pela qualidade daquilo que ele está entregando. Tendo QA ou não, a responsabilidade última tem que ser do dev;

3. Quando o processo não permite que as dívidas técnicas sejam sanadas. Quando a gente precisa ficar brigando prioridade em relação a funcionalidade. Isso é um problema porque a resolução de dívida técnica sempre vai perder na disputa de prioridade com uma nova feature. A nova feature é tangível, tem dinheiro na mesa. Quando entregar, vai ter mais cliente, vai vender mais… mas a dívida técnica é intangível.

Afinal, o que é dívida técnica?

Muita gente já ouviu falar no termo, mas é importante entender exatamente o que ele significa. Segundo Martin Fowler, dívida técnica é uma metáfora criada por Ward Cunningham que descreve o custo futuro que você incorre ao escolher uma solução técnica mais simples ou rápida no presente, em vez de uma abordagem melhor, mais robusta e sustentável. Fowler explica que, assim como uma dívida financeira, a dívida técnica pode ser uma escolha consciente ou inconsciente, e ela gera “juros” que precisam ser pagos na forma de manutenção mais difícil, bugs e menor capacidade de evolução do sistema.

Fowler propôs uma matriz de classificação que divide a dívida técnica em quatro quadrantes, com base em duas informações principais:

Deliberado vs. Inadvertido

• Deliberado: quando você tem consciência de que está adquirindo uma dívida técnica.

• Inadvertido: quando você não tem consciência de que está criando uma dívida técnica.

Prudente vs. Imprudente 

• Prudente: quando há uma análise cuidadosa e você assume uma dívida por razões estratégicas, é conveniente lidar com ela no futuro.

• Imprudente: quando uma dívida é contraída sem preocupação com as consequências, geralmente pela falta de conhecimento ou pressa.

"A dívida técnica pode surgir inesperadamente como resquício de uma decisão equivocada, mas também pode ser um trade-off planejado. Identificar e administrar dívidas técnicas é uma habilidade desenvolvida com experiência, e geralmente essa responsabilidade recai sobre um arquiteto de software", complementa Bruno.

Sinais de que a dívida técnica está saindo do controle

Nem sempre é fácil perceber quando uma dívida técnica começou a pesar. Mas, de acordo com Rodrigo, existem dois sinais claros: 

“A primeira é quando o dev torce o nariz pra mexer na feature. É como se a gente tivesse um livro e tivesse um capítulo que ninguém entende nada. O código todo deveria ser muito fácil de ler, quando ele não está, significa que é preciso agir; o outro sinal é aquela porção do código que sempre que alguém mexe dá bug. É preciso refatorar pois está levando as pessoas ao erro. A falta de simplicidade do código faz o dev tomar decisões erradas.”

Nem toda dívida técnica tem urgência de ser resolvida, mas quando há dificuldade de fazer manutenção no código e a equipe começa a encontrar barreiras para desenvolver novas funcionalidades, é preciso sanar as dívidas técnicas.

O impacto dos processos ruins e da dívida técnica na motivação do time

Não é difícil imaginar o quanto processos ineficientes e dívidas técnicas impactam a produtividade, mas existe outro ponto fundamental: a motivação. Pode ser frustrante preparar-se para desenvolver software com qualidade e ser solicitado a comprometer seus princípios em nome de prazos apertados.

Bruno compartilha uma experiência pessoal em que trabalhou em uma equipe com uma pilha técnica mal arquitetada. “A pilha se tornou uma bola de neve de problemas insolúveis, levando-me a sair da equipe”. Situações assim corroem a moral, não apenas dos desenvolvedores, mas da liderança como um todo”.

Como lidar com a dívida técnica?

Para lidar com a dívida técnica o segredo está na simplicidade e em fazer um pouco de cada vez. Pensar em soluções simples, seja na arquitetura, seja na implementação, é fundamental. As pessoas agregam muitas complexidades desnecessárias no sistema. Escolher o simples é a melhor arma contra dívidas técnicas.

Rodrigo chama a atenção para a prática da micro refatoração: “Toda vez que eu vou mexer no código, eu faço uma refatoração… isso deve fazer parte do trabalho do dev. Aí o código vai melhorando organicamente. Talvez não resolva um código que tem dívida há anos, mas a gente para de sujar o rio… No Asaas a gente tem a cultura de arrumar o código enquanto mexe nele, é a lei do escoteiro ‘deixe o lugar um pouco melhor do que quando você chegou’.” 

Uma prática bastante comum é reservar um tempo do time para trabalhar em cima de melhorias no código. Bruno destaca a importância de documentar as decisões que envolvem as necessidades técnicas. “Documente a dívida técnica em um ADR (Architectural Decision Record), registrando detalhes sobre a dívida, os times responsáveis ​​pela solução e, se possível, uma estimativa de tempo para resolvê-la”, recomenda.

O papel da cultura da empresa na gestão da dívida técnica

A cultura organizacional tem um papel fundamental na forma como a dívida técnica é enfrentada. Empresas que têm uma visão de longo prazo entendem que a melhoria contínua faz parte do serviço de pós-venda. A dívida técnica impacta diretamente o time-to-market e pode influenciar vendas, contratações e manutenção do produto. Ou seja, é essencial que a gestão esteja atualizada com o tempo de desenvolvimento e reconheça a importância de tratar a técnica como algo estratégico, e não apenas como um problema técnico.

A cultura da empresa é o que vai permitir que a pessoa desenvolvedora se comporte não acumulando dívidas técnicas, refatorando o tempo todo, ou ao contrário: tem que entregar o mais rápido possível e a gente vai lidar com a consequência depois e nunca lida. Não é a pessoa desenvolvedora que escolhe não fazer.

“Eu nunca conheci um dev que não queria resolver dívidas técnicas… na maioria dos casos o dev curte mexer num código limpo e claro. Então, a culpa geralmente é da cultura, não do indivíduo”, fala Rodrigo

IA e dívida técnica: um novo desafio?

Com a popularização das ferramentas de inteligência artificial na geração de código, surge uma preocupação: será que a IA vai agravar o problema da dívida técnica? Bruno acredita que isso depende muito das práticas usadas pelas equipes:

"Vejo a IA como uma ferramenta de desenvolvimento, semelhante ao autocomplete de um IDE. Mesmo utilizando IA para gerar código, ainda é necessário manter scanners de qualidade, testes automatizados e revisões feitas por desenvolvedores experientes", explica. Ou seja, a responsabilidade continua sendo humana. O uso de boas práticas de CI/CD e de processos de revisão de código é essencial, independentemente de quem — ou o que — escreveu o código.

Conselhos para quem está enfrentando esses desafios no dia a dia

Para quem sente que está imerso em processos ruins ou atolado em dívidas técnicas, Bruno deixa dois conselhos práticos:

1. Analisar o problema sob a ótica do negócio: às vezes, a decisão técnica ruim faz sentido no curto prazo para atender a uma necessidade comercial. O importante é ter consciência dessa decisão e planejar a resolução da dívida no futuro.

2. Documente tudo: além dos ADRs, é importante ter uma comunicação clara sobre o que foi decidido, por que foi decidido e quem é responsável pela resolução. Isso evita que o problema fique invisível ou seja esquecido.

Rodrigo complementa:

“Um princípio que todo dev deveria ter é: qualidade não se negocia. Isso não significa que eu tenho que alterar toda parte do sistema que tá ruim, mas nas minhas entregas eu não negocio qualidade. Por mais que se exija velocidade na entrega, a qualidade não é um atributo que você pode diminuir ou aumentar. Negocie outras coisas: prazo, o entregável… pense sempre na clareza de ser lido, na capacidade de ser alterado facilmente e nunca negocie qualidade.”

Lidar com processos ruins e dívidas técnicas não é uma tarefa fácil, mas é possível. O segredo está em equilíbrio, planejamento e melhoria contínua. O alinhamento com a gestão e uma cultura organizacional que valoriza a qualidade são fatores determinantes para o sucesso de qualquer estratégia.