Sergio Vilar

writes about dev stuff

Todo Software é um carro: uma reflexão sobre débito técnico

18 Jul 2016

Alguns meses depois de comprar o meu primeiro carro, um Fusca 79, não pude deixar de notar a semelhança entre a manutenção de um carro e a manutenção de um projeto de software.

O meu fusca possui um enorme débito técnico: as portas só fecham se forem batidas com muita força, vaza muito óleo, o banco do motorista não é regulável, o pisca traseiro direito não acende, entre outros.

Semana passada meu pai comprou um Corcel l Luxo 76, um carro encantador. Assim como todo carro antigo, há uma série de pequenas manutenções a se fazer e meu pai todo animado as listava já dizendo onde iria comprar tal peça e como se consertava isso e aquilo. Achei engraçado e disse pra ele que com o tempo ele iria se acostumar, ia aceitar o carro como era e não iria consertar metade da lista dele.

Infelizmente é o que acontece com vários projetos de software, a gente se acostuma com os defeitos.

Débito o quê?

Débito técnico é definitivamente um dos problemas mais presentes no dia-a-dia de desenvolvedores. Seja na pausa pro café, no #HoraExtra, ou quando estamos xingando muito no Twitter. Além disso, há uma outra coisa sobre Débito Técnico. Temos o estranho costume de aceitá-lo como feature, como algo comum: “é assim mesmo”.

Todo o débito técnico de um projeto de software é fruto das decisões tomadas durante sua vida útil, um projeto de software enveleche da mesma forma que um carro.

Ao longo de sua vida útil um carro passa por inúmeras manutenções feitas por inúmeras pessoas, em alguns momentos más decisões são tomadas e algo não é feito da melhor forma, ou apenas algo precisava ser feito naquele momento, como um conserto para tirar o carro do prego que acaba perpetuando por toda sua vida útil. O motorista se acostuma com uma folga na maçaneta mas isso não impede o carro de andar, isso é o débito técnico.

Débito técnico é responsabilidade do time

Uma palavra que constantemente uso quando entro em um projeto em andamento é “motivação”. É muito fácil reclamar de uma arquitetura, de uma infinidade de débitos técnicos e dizer “isso deveria ter sido feito de outra forma” sem conhecer a motivação daqueles que o fizeram. É preciso respeitar, mesmo que com certa crítica, o que foi feito no passado sob circunstâncias desconhecidas, determinada classe pode ter sido escrita “nas coxas” simplesmente por pressão para entrega, e por isso todos nós já passamos ao menos uma vez.

“Tu te tornas eternamente responsavel pelo código que commitas”

Quando entramos em um projeto, assumimos com ele a responsabilidade do débito técnico. Não é algo ao qual possamos culpar os desenvolvedores do passado, o problema está bem ali pronto para ser resolvido.

Evitando a criação de novos débitos técnicos

O primeiro passo que pode ser tomado nesse caso é evitar que novos débitos técnicos sejam criados. Uma forma muito útil de fazer isso é criar um processo bastante estrito de revisão de código, com uma base de testes sólida e de preferência um code style. Isso vai ao menos incentivar a equipe a discutir as soluções propostas antes de entrarem no codebase do projeto.

Resolvendo débitos técnicos existentes

Você provavelmente já sabe que não há fórmula mágica pra se livrar do problema. É mais fácil trabalhar em débito técnico quando o incentivo vem da própria empresa, mas não necessariamente obrigatório. Está fora da nossa realidade gastar-se dois meses de todo o time de desenvolvimento de uma empresa para resolução de débito técnico. Tenha em mente que é um processo gradual e que muito provavelmente será feito fora das suas horas de trabalho eventuais.

O maior problema de aceitarmos o débito técnico como parte do projeto é que o quanto mais nos acostumamos com ele, menos estaremos dispostos a resolvê-lo e mais vai-se acumular.