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 iTunes, Spotify e Deezer! 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.
-
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
