O que é dívida técnica?
Deixe-me começar com a definição original e, em seguida, explicarei como as pessoas estão usando o termo hoje.
Ward Cunningham, o coautor do Manifesto Ágil que concebeu o termo "débito técnico”, explicou com uma metáfora financeira: “Avançar para desenvolver um novo aplicativo de software é como obter um empréstimo (dívida).”
Imagine construir um produto usando uma tecnologia totalmente nova. Você está enfrentando muitas incógnitas. Você faz o melhor que pode com o que sabe agora. À medida que você descobre o que está funcionando bem e o que não está, você usa esse conhecimento para melhorar o código. Tornar o código melhor à medida que você aprende com a experiência é semelhante a pagar o empréstimo.
Nos últimos anos, no entanto, a definição de débito técnico se transformou. Hoje, a maioria das equipes pensa no débito técnico como um código com deficiências e ineficiências conhecidas, mas se não estiver parando processo tudo bem deixar ele lá.
A busca por entregas mais rápidas está causando mais débito técnico?
Concentrar-se em entregas rápidas pode resultar em cortes com qualidade do código. A ideia que: “Se não for perfeito, podemos corrigi-lo na próxima versão.”
O débito técnico pode ser construído dessa maneira. Como os desenvolvedores precisam concluir novos recursos e aprimoramentos, eles podem não ter tempo em suas agendas para corrigir o código de versões anteriores.
Se uma equipe não tem tempo para escrever um código limpo em primeiro lugar, por que eles teriam tempo para fazê-lo mais tarde? Se você nunca voltar para melhorar o código, você permite que o debito persista e cresça. Você está pagando juros sobre isso.
Como a dívida técnica afeta a segurança?
Para atingir as metas de entrega, as equipes podem lançar códigos com vulnerabilidades de segurança gritantes. Uma vulnerabilidade é qualquer fraqueza que possa levar ao comprometimento de dados, sistemas, reputação da marca e assim por diante. Um risco de segurança de TI refere-se às possíveis consequências que uma empresa pode enfrentar se um invasor explorar com sucesso essas vulnerabilidades.
As equipes devem equilibrar a busca por velocidade com os fatores de funcionalidade, usabilidade e segurança. Infelizmente, muitas vezes essas prioridades entram em conflito.
E se uma equipe não prioriza a segurança desde o início, o que acontece quando há uma cultura de “precisar agir rápido, então vamos colocar isso depois”? Assim como nos carros, a velocidade mata.
Quem é responsável pela segurança do software?
A segurança ainda é uma reflexão tardia para muitas equipes de desenvolvimento de software. Eles podem ver isso como responsabilidade de outra pessoa e/ou algo que acontece mais tarde no ciclo de vida de desenvolvimento de software. O trabalho de um programador "normalmente" seria programar. Essa pessoa muitas vezes não é um especialista em segurança. Para escrever código com segurança em mente, os desenvolvedores de software precisam de treinamento em princípios de codificação segura.
Muitas equipes não têm material de treinamento para seus programadores com conhecimento ou definem requisitos de segurança abrangentes no início do projeto, mesmo que uma falha precoce na segurança possa causar um risco significativo para os negócios.
Quais problemas de segurança a dívida técnica pode causar?
Os problemas mais comuns envolvem vazamento de dados, exclusão de dados, e dependendo do tipo de sistema pode causar grandes danos financeiros ou para vida de pessoas.
Se o código tiver vulnerabilidades, a maneira de torná-lo seguro é refatorar para corrigir as vulnerabilidades. Caso contrário, os problemas de segurança vão ficar lá. Colocar algo em débito técnico é semelhante a aplicar um curativo em uma ferida. O curativo pode lhe dar tempo para ir ao médico, mas não corrige a lesão.
Foco na velocidade pode acabar custando mais do que qualquer vantagem que você pensou que ganhou.
Deixo uma analogia: "Considere o débito técnico como a dívida com um agiota, é sempre melhor pagar antes que ele venha cobrar".
Top comments (0)