Dívida técnica - Technical debt

Dívida técnica (também conhecida como dívida de design ou dívida de código , mas também pode estar relacionada a outros esforços técnicos) é um conceito no desenvolvimento de software que reflete o custo implícito de retrabalho adicional causado pela escolha de uma solução fácil (limitada) agora em vez de usar um abordagem melhor que levaria mais tempo.

Tal como acontece com a dívida monetária , se a dívida técnica não for paga, pode acumular "juros", dificultando a implementação de mudanças. O débito técnico não resolvido aumenta a entropia do software . Da mesma forma que a dívida monetária, a dívida técnica não é necessariamente uma coisa ruim e, às vezes (por exemplo, como uma prova de conceito), é necessária para fazer os projetos avançarem. Por outro lado, alguns especialistas afirmam que a metáfora da "dívida técnica" tende a minimizar as ramificações, o que resulta em priorização insuficiente do trabalho necessário para corrigi-la.

Como uma mudança é iniciada em uma base de código, geralmente há a necessidade de fazer outras mudanças coordenadas em outras partes da base de código ou documentação. As alterações necessárias que não foram concluídas são consideradas dívidas e, até que sejam pagas, incorrerão em juros além dos juros, tornando complicado construir um projeto. Embora o termo seja usado principalmente no desenvolvimento de software, também pode ser aplicado a outras profissões.

Causas

As causas comuns de dívida técnica incluem:

  • O desenvolvimento contínuo, uma longa série de melhorias no projeto ao longo do tempo tornam as soluções antigas abaixo do ideal.
  • Definição inicial insuficiente, onde os requisitos ainda estão sendo definidos durante o desenvolvimento, o desenvolvimento começa antes que qualquer design ocorra. Isso é feito para economizar tempo, mas geralmente precisa ser refeito mais tarde.
  • As pressões de negócios, em que a empresa considera a possibilidade de lançar algo mais cedo, antes que as mudanças necessárias sejam concluídas, acumulam dívidas técnicas envolvendo essas mudanças incompletas.
  • Falta de processo ou compreensão, onde as empresas são cegas para o conceito de dívida técnica e tomam decisões sem considerar as implicações.
  • Componentes fortemente acoplados , onde as funções não são modulares , o software não é flexível o suficiente para se adaptar às mudanças nas necessidades do negócio.
  • Carecem de um conjunto de testes , que incentiva rápidas e arriscadas band-aid correções de bugs.
  • Falta de documentação de software , onde o código é criado sem documentação de suporte. O trabalho de criação de documentação representa dívida.
  • Falta de colaboração, em que o conhecimento não é compartilhado pela organização e a eficiência dos negócios é prejudicada, ou os desenvolvedores juniores não são devidamente orientados.
  • O desenvolvimento paralelo em várias filiais acumula dívida técnica devido ao trabalho necessário para fundir as mudanças em uma única base de origem. Quanto mais mudanças forem feitas isoladamente, maior será o endividamento.
  • Refatoração atrasada ; Conforme os requisitos de um projeto evoluem, pode ficar claro que partes do código se tornaram ineficientes ou difíceis de editar e devem ser refatoradas para oferecer suporte a requisitos futuros. Quanto mais a refatoração for atrasada e quanto mais código for adicionado, maior será o débito.
  • Falta de alinhamento com os padrões, onde os recursos, estruturas e tecnologias padrão da indústria são ignorados. Eventualmente, a integração com os padrões virá, e fazer isso mais cedo custará menos (semelhante à "refatoração atrasada").
  • Falta de conhecimento, quando o desenvolvedor não sabe escrever um código elegante.
  • Falta de propriedade, quando os esforços de software terceirizado resultam na necessidade de engenharia interna para refatorar ou reescrever o código terceirizado.
  • Fraca liderança tecnológica, onde comandos mal elaborados são transmitidos pela cadeia de comando.
  • Alterações de especificação de última hora. Eles têm potencial para se infiltrar em todo o projeto, mas não há tempo ou orçamento suficiente para documentar e testar as mudanças.

Serviço ou quitação da dívida técnica

Kenny Rubin usa as seguintes categorias de status:

  • Dívida técnica acumulada - dívida que a equipe de desenvolvimento não sabia que existia até ser exposta durante o curso normal de execução do trabalho no produto. Por exemplo, a equipe está adicionando um novo recurso ao produto e, ao fazer isso, percebe que uma solução alternativa foi construída no código anos antes por alguém que já havia partido há muito tempo.
  • Dívida técnica conhecida - dívida que é conhecida pela equipe de desenvolvimento e tornou-se visível usando uma das abordagens discutidas anteriormente.
  • Dívida técnica direcionada - dívida que é conhecida e destinada para atendimento pela equipe de desenvolvimento.

Consequências

Os "pagamentos de juros" são causados ​​tanto pela manutenção local necessária quanto pela ausência de manutenção por outros usuários do projeto. O desenvolvimento contínuo do projeto upstream pode aumentar o custo de "pagar a dívida" no futuro. A pessoa paga a dívida simplesmente completando o trabalho incompleto.

O acúmulo de dívidas técnicas é uma das principais causas para os projetos não cumprirem os prazos. É difícil estimar exatamente quanto trabalho é necessário para saldar a dívida. Para cada mudança iniciada, uma quantidade incerta de trabalho incompleto é comprometida com o projeto. O prazo é perdido quando o projeto percebe que há mais trabalho incompleto (dívida) do que tempo para concluí-lo. Para ter cronogramas de lançamento previsíveis, uma equipe de desenvolvimento deve limitar a quantidade de trabalho em andamento para manter a quantidade de trabalho incompleto (ou dívida) sempre pequeno.

Se trabalho suficiente for concluído em um projeto para não apresentar uma barreira à apresentação, então um projeto será liberado que ainda carrega uma quantidade substancial de dívida técnica. Se este software chegar à produção, os riscos de implementação de quaisquer refatoradores futuros que possam resolver o problema técnico aumentam drasticamente. Modificar o código de produção acarreta o risco de interrupções, perdas financeiras reais e possivelmente repercussões legais se os contratos envolverem acordos de nível de serviço (SLA). Por esta razão, podemos ver o carregamento da dívida técnica para a produção quase como se fosse um aumento na taxa de juros e a única vez que isso diminui é quando as implantações são recusadas e retiradas.

"À medida que um programa em evolução é continuamente alterado, sua complexidade, refletindo a deterioração da estrutura, aumenta a menos que seja feito um trabalho para mantê-la ou reduzi-la."

-  Meir Manny Lehman , 1980

Embora a Lei de Manny Lehman já indicasse que programas em evolução continuamente aumentam sua complexidade e deterioram a estrutura, a menos que seja feito um trabalho para mantê-los, Ward Cunningham primeiro traçou a comparação entre complexidade técnica e dívida em um relatório de experiência de 1992:

"Enviar código pela primeira vez é como se endividar. Um pequeno débito acelera o desenvolvimento, desde que seja pago prontamente com uma reescrita ... O perigo ocorre quando a dívida não é paga. Cada minuto gasto em um código incorreto conta como juros sobre essa dívida. Organizações inteiras de engenharia podem ser paralisadas sob o peso da dívida de uma implementação não consolidada, orientada a objetos ou não. "

-  Ward Cunningham , 1992

Em seu texto de 2004, Refatorando para Padrões , Joshua Kerievsky apresenta um argumento comparável sobre os custos associados à negligência arquitetônica, que ele descreve como "dívida de design".

As atividades que podem ser adiadas incluem documentação , escrever testes , atender aos comentários TODO e lidar com os avisos do compilador e da análise estática de código . Outras instâncias de dívida técnica incluem conhecimento que não é compartilhado pela organização e código que é muito confuso para ser modificado facilmente.

Escrevendo sobre o desenvolvimento de PHP em 2014, Junade Ali disse:

O custo de nunca pagar essa dívida técnica é claro; eventualmente, o custo para entregar funcionalidade se tornará tão lento que é fácil para um produto de software competitivo bem projetado superar o software mal projetado em termos de recursos. Na minha experiência, um software mal projetado também pode levar a uma força de trabalho de engenharia mais estressada, o que, por sua vez, aumenta a rotatividade de pessoal (o que, por sua vez, afeta os custos e a produtividade ao fornecer recursos). Além disso, devido à complexidade em uma determinada base de código, a capacidade de estimar o trabalho com precisão também desaparecerá. Nos casos em que as agências de desenvolvimento cobram em uma base de recurso a recurso, a margem de lucro para entrega de código acabará se deteriorando.

-  Junade Ali escreve em Mastering PHP Design Patterns

Grady Booch compara como as cidades em evolução são semelhantes aos sistemas de software intensivo em evolução e como a falta de refatoração pode levar a dívidas técnicas.

"O conceito de dívida técnica é central para entender as forças que pesam sobre os sistemas, pois muitas vezes explica onde, como e por que um sistema é estressado. Nas cidades, os reparos na infraestrutura costumam ser atrasados ​​e mudanças incrementais são feitas em vez de ousadas . O mesmo ocorre em sistemas com uso intensivo de software. Os usuários sofrem as consequências da complexidade caprichosa, melhorias atrasadas e mudanças incrementais insuficientes; os desenvolvedores que desenvolvem esses sistemas sofrem as consequências de nunca serem capazes de escrever código de qualidade porque estão sempre tentando recuperar o atraso. "

-  Grady Booch , 2014

Em software de código aberto , adiar o envio de alterações locais para o projeto upstream é uma forma de dívida técnica.

Veja também

Referências

  1. ^ a b Suryanarayana, Girish (novembro de 2014). Refatoração para Software Design Smells (1ª ed.). Morgan Kaufmann. p. 258. ISBN 978-0128013977.
  2. ^ "Definição do termo" Dívida Técnica "(mais algumas informações básicas e uma" explicação ")" . Techopedia . Recuperado em 11 de agosto de 2016 .
  3. ^ Allman, Eric (maio de 2012). “Gerenciando Dívidas Técnicas”. Comunicações da ACM . 55 (5): 50–55. doi : 10.1145 / 2160718.2160733 .
  4. ^ Jeffries, Ron. "Dívida técnica - metáfora ruim ou pior metáfora?" . Arquivado do original em 11 de novembro de 2015 . Recuperado em 10 de novembro de 2015 .
  5. ^ Knesek, Doug. "Evitando uma crise de 'dívida técnica'" . Recuperado em 7 de abril de 2016 .
  6. ^ a b c Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11 de novembro de 2014). Refatoração para cheiros de design de software: Gerenciando dívidas técnicas . Elsevier Science. p. 3. ISBN 978-0-12-801646-6.
  7. ^ a b c Chris Sterling (10 de dezembro de 2010). Gerenciando dívidas de software: Construindo para mudanças inevitáveis ​​(Adobe Reader) . Addison-Wesley Professional. p. 17. ISBN 978-0-321-70055-1.
  8. ^ Rubin, Kenneth (2013), Essential Scrum. Um Guia Prático para o Processo Ágil Mais Popular , Addison-Wesley, p. 155, ISBN 978-0-13-704329-3
  9. ^ Lehman, MM (1996). "Revisão das Leis da Evolução do Software" . EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology : 108–124 . Retirado em 19 de novembro de 2014 .
  10. ^ Ward Cunningham (1992-03-26). "O Sistema de Gerenciamento de Portfólio WyCash" . Página visitada em 2008-09-26 .
  11. ^ Kerievsky, Joshua (2004). Refatorando para padrões . ISBN 978-0-321-21335-8.
  12. ^ Ali, Junade (setembro de 2016). Dominando os padrões de design do PHP | PACKT Books (1 ed.). Birmingham, Inglaterra, Reino Unido: Packt Publishing Limited. p. 11. ISBN 978-1-78588-713-0. Retirado em 11 de dezembro de 2017 .

links externos