Depois eu leio

Código legado e débito técnico

Trabalhar num código legado, é como fazer uma viagem no tempo ou atravessar um dos portais Stargate. É ali que está a verdadeira história de uma empresa de tecnologia: a pressa em lançar antes do concorrente, a atenção (ou falta de) que se dá para um capacity planning, a qualidade da comunicação interna, o perfil das equipes de desenvolvimento, a clareza das regras de negócio, etc. Está tudo ali, pra quem souber traduzir os hieróglifos também conhecidos como débito técnico.

Ward Cunningham foi o primeiro a utilizar o termo “débito técnico”, para explicar que sempre que uma empresa de software opta por um design que visa resultados rápidos - abrindo mão da qualidade - ela insere no sistema uma complexidade que tornará seu custo maior no longo prazo. Para mais detalhes sobre a parte teórica, recomendo ir direto ao site do Mestre dos Magos.

No primeiro parágrafo eu misturei propositalmente os termos “legado” e “débito técnico”, mas será que são realmente a mesma coisa? Segundo este outro cara, legado é simplesmente qualquer código sem testes. Seguindo esta linha, sou levado a crer que débito técnico e legado são dois bichos diferentes.

Legado é aquele código caixa-preta, que ninguém sabe o que será afetado se mudar uma linha e ninguém se atreve nem a indentar (ou endentar, pro dicionário ficar feliz) o código. Normalmente, o sistema foi feito por pessoas que nunca ouviram falar do termo “débito técnico”, pois se soubessem o conceito, também saberiam como fazer um design que favorecesse sua manutenção futura.

Este é o resultado da mistura entre cowboys e gerentes caricatos. Eles acreditam estar fazendo um bom trabalho sendo pragmáticos ao extremo, mas, sem bons alicerces teóricos e um mínimo de estratégia é quase impossível fazer um sistema que não seja uma bomba-relógio - a chance de acerto é pura sorte.

Já em relação ao débito técnico legítimo, a equipe têm consciência de que para aproveitar uma oportunidade de mercado ou algo parecido em tempo hábil, não será capaz de implementar a arquitetura mais desejável a tempo. Porém, é perfeitamente capaz de trabalhar com foco no mínimo necessário e ao mesmo tempo se manter aderente a princípios de design que favoreçam a refatoração no momento adequado. E claro, o sistema obrigatoriamente terá alguma cobertura de testes, e ser testável é sinal de mais boas práticas no pacote.

Minha dica aos desenvolvedores que precisam dar manutenção a algum sistema legado: vistam o chapéu de Indiana Jones e divirtam-se. Arqueologia de sistemas é um ótimo exercício para refatoração e desenvolvimento da programação como arte. Afinal, como na arte, o sistema perfeito é o que atingiu a simplicidade onde não há mais nada a ser removido.

No comments

No comments yet. Be the first.

Leave a reply