9 março, 2013 0 Comentários AUTOR: elemarjr CATEGORIAS: Sem categoria Tags:,

Sobre dívidas técnicas

Tempo de leitura: 1 minuto

Olá. Tudo certo?

Fazer da melhor forma, da primeira vez, é muito caro. Não melhorar aquilo que já foi feito costuma custar ainda mais.

Pelo dito acima, a atividade de desenvolvimento, para mim, pode ser descrita como a rotina eterna de contrair e pagar dívidas técnicas.

O TDD, em seu ciclo "escrever teste que falha -> fazer teste passar -> refatorar" é o indicativo ágil da necessidade de contrair e pagar dívidas em ciclos extremamente curtos.

Assumir uma dívida técnica é reconhecer, conscientemente, a necessidade de implementar algo, considerando código e design, abrindo mão de aspectos importantes de qualidade. Não é o ideal, mas, com frequência, é necessário.

Acoplamento alto, testes não escritos, classes/métodos/variáveis mal nomeadas - Todos esses são apenas alguns exemplos de dívida técnica.

Dívidas técnicas são uma analogia feliz para dívidas financeiras. As vezes, você precisa contrair algumas - seja por necessidade, seja por oportunidade. Entretanto, se não pagar em breve, sofrerá com os juros.

Parte da senioridade, para mim, pode ser entendida como a capacidade de contrair e pagar dívidas técnicas.

Contrair dívidas técnicas, muitas vezes, viabiliza o desenvolvimento acelerado de soluções. Impede que sejamos paralisados por análise. Outras vezes, em virtude da "pressão do tempo", é a única opção viável. Afinal, há sempre "um caminhão parado esperando por uma nota" em algum lugar. O problema é esquecer dessa dívida.

Não pagar dívidas técnicas - acertando o que for necessário - costuma ter impactos graves sobre a manutenabilidade. O acúmulo de dívidas técnicas é o que nos leva ao "brownfield".

Pagar dívidas técnicas é um tipo de atividade importante que, como usual, quando não realizada, se torna urgente. Quando não há tempo para fazer o que é importante, acabamos consumidos fazendo o que é urgente.

Assumir uma dívida técnica é uma decisão, obviamente, do time técnico. Pagar essa dívida também é!

Pagar dívidas técnicas é uma atividade muito mais simples quando temos testes que indicam se estamos, ou não, quebrando algo.

Pagar dívidas técnicas é um indicativo de que você se importa com aquilo que está fazendo.

0 Comentários

  1. gustavobergamim 4 anos ago says:

    Excelente post.

    La na empresa, adotamos a prática de sempre criar tasks no TFS para atividades de débito técnico. As tasks são registradas em uma área específica do Team Project e devem ser atendidas sempre que as atividades planejadas para a Sprint forem concluídas.

    E um projeto recente em que trabalhei, as tasks tratavam de trechos complexos de código que poderiam ser melhorados/otimizados com um trabalho de análise, ou então de partes do código que poderiam ser extraídos para uma biblioteca de componentes.

    Acredito que adotar tal prática não é apenas uma necessidade, mas algo que permite a evolução do time, pois a atividade de análise e "pagamento" dessas dívidas cria um ambiente muito legal de compartilhamento de conhecimento entre os integrantes. Não que esse ambiente não exista no dia a dia, mas em um "cenário ideal", essa atividade seria realizada em um momento com menor "pressão" (não seria a palavra correta, mas foi a que me veio a cabeça) no ciclo do projeto.

    Responder

Trackbacks para este post

  1. Você é o ÚNICO responsável pela qualidade do código que produz! | Elemar DEV
  2. Você não deve acumular dívida técnica! | Blog Lambda3
  3. » Você não deve acumular dívida técnica! :Programaticamente falando