Nem tudo que parece “dívida técnica”, efetivamente, é

Os “Drops da EximiaCo” estão disponíveis em algumas das principais plataformas de podcast, incluindo iTunesSpotifyDeezer! Caso seu player não tenha suporte a nenhuma dessas plataformas, poderá usar nosso feed.


Dívidas técnicas surgem quando desenvolvedores de software, de forma deliberada ou não, abrem mão de boas práticas de desenvolvimento para ganhar algum tempo. Entretanto, acabam sofrendo, mais tarde, com os custos e tempos de manutenção mais altos.

Os “juros” resultantes das dívidas técnicas costumam ficar evidentes em maior dificuldade para ler e entender o código, fragilidade decorrente de acoplamento (mexer em uma parte do sistema, estraga outra), dificuldade para adicionar features sem quebrar testes, etc. Entretanto, é importante ressaltar que, se não há “juro” percebido, provavelmente não há dívida. Ou seja, se nenhum prejuízo é sentido pelo time técnico, ou pelo negócio, por causa de uma decisão técnica que aparentava não ser boa, então, talvez não haja nada de errado com ela!

Em nossas consultorias, temos encontrado desenvolvedores implementando soluções mais “sofisticadas” justificando-as por pretensas boas práticas, mas que, na verdade, adicionam pouco ou nenhum valor ao negócio. Aliás, com frequência adicionam apenas complexidade e, consequentemente, custo.

Se um desenvolvedor adota uma “boa prática” sem saber justificar a razão para estar fazendo isso, então, há chances grandes do efeito ser exatamente o oposto do que planeja. Microsserviços implementados para viabilizar escalabilidade, mas que não escalam. Repositórios isolando acesso a dados para permitir uma hipotética “troca do banco”, que nunca ocorre.

Há algum tempo, ajudamos um time que estava enfrentando problemas de performance. Em função de uma pretensa “fidelidade ao domínio”, para aplicarem uma modificação rotineira em alguns milhares de registros, em lugar de executar um UPDATEcontra o banco, materializavam entidades individualmente, mudavam os valor de uma propriedade, e persistiam a modificação.

Outro time, para popular uma lista na interface com nomes e telefones de alguns clientes, materializavam ” instâncias inteiras dos clintes” a partir de chamadas ao repositório para, usando AutoMapper hidratarem ViewModels.

Quando todo embasamento que um desenvolvedor tem para adotar uma prática é a palavra de alguém, então, não tem embasamento algum.

Em Resumo
  • O problema

    Desenvolvedores, tentando fazer o melhor, acabam adotando práticas e padrões que não entendem. Em consequência disso, no lugar de aproveitarem os benefícios, amargam o desconforto de ter que manter uma solução que parece "complexa demais"
  • O insight

    Toda prática, antes de ser adotada, precisa ser justificada com base em argumentos que fazem sentido para o projeto em que se está trabalhando. Se o time não for capaz de fazer isso, então, provavelmente não está preparado para adotar a prática corretamente.
  • Os benefícios

    Se o time tiver domínio sobre as motivações de cada prática adotada no código, terá mais facilidade para fazer ajustes quando estes forem necessários. Além disso, terá, eventualmente, "cicatrizes" para explicar porque alguns conceitos fazem sentido e, por isso, desenvolverá soluções mais sólidas

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…

Deixe uma resposta

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