Este artigo sobre dívida técnica tem alguns pontos positivos, incluindo:

Trabalhar nas "questões técnicas" funciona melhor quando conduzido por histórias. Provavelmente, a base de código precisa de trabalho em todos os lugares, mas a recompensa será recebida apenas onde o código for trabalhado por motivos voltados para o usuário. Se nenhuma história vai passar por alguma área contaminada, trabalhar nela é amplamente desperdiçado.

Portanto, prefiro abordar histórias como de costume (mas provavelmente poucas) e seguir a "regra dos escoteiros" de deixar o acampamento melhor do que você a encontrou. Em outras palavras, onde quer que as histórias nos levem, vamos escrever mais testes, refatorar de forma mais agressiva.

Essa abordagem tem pelo menos as seguintes vantagens:

• mantém o fluxo de histórias "mais sensato";
• fornece ajuda de todo o talento da equipe;
• fornece para toda a equipe aprender como manter o código limpo;
• concentra a melhoria exatamente onde é necessária;
• não desperdiça melhorias que "possam" ser necessárias;

Vi a qualidade do código ter um efeito muito grande na produtividade a longo prazo, por isso acredito que a dívida técnica deve ser resolvida. Acho que o post acima faz sentido, mas não tenho tanta certeza dos dois últimos pontos. Estou interessado em descobrir experiências reais de benefícios da limpeza de dívidas técnicas, mesmo que não estejam relacionadas às histórias de usuários.

Que benefícios positivos você viu ao limpar sua base de códigos e se livrar de dívidas técnicas? Quais métodos você usou para realizar o trabalho?

Eu posso lhe dar um exemplo da minha experiência.

Há cerca de 10 ou 12 anos, herdei um aplicativo de uma equipe de desenvolvedores que acabou saindo da empresa (tempo demais para entrar aqui ...). O sistema era um grande sistema de geração de relatórios de middleware desenvolvido em casa. Ele era executado toda semana à noite e gerava cerca de duas dúzias de relatórios Excel para executivos seniores de uma empresa da Fortune 500. Quando a herdei, levava cerca de 5 a 6 horas para ser executada e, durante uma semana, falhava pelo menos 2 noites.

Eu não era um campista feliz por receber essa bagunça.

Inicialmente, meu plano era apenas parar o sangramento e corrigir a principal causa das falhas. Depois de me sentir mais confortável com a base de código, comecei a procurar lugares onde pudesse refatorar e adicionar estabilidade e desempenho. Ao longo de mais ou menos dois anos, fiz muitas e muitas alterações no sistema. Aposentamos esse sistema há alguns anos e, nesse ponto, todo o processo levou 45 minutos para ser executado e não gerava nenhum problema há anos.

Muito trabalho foi feito para pagar a dívida técnica, mas valeu a pena. Foi bom não receber chamadas telefônicas no meio da noite em que o sistema falhou. Foi bom entrar no escritório e não ver nada além de boas notícias nos registros.

(Além disso ... Depois de alguns anos, encontrei um dos principais desenvolvedores deste sistema. Ele me perguntou como estava indo e eu lhe disse o quão ruim era o sistema. Ele realmente se desculpou e me disse que sabia que seria um punhado de apoio depois que ele saiu e desejou ter feito um trabalho melhor nisso).

Foi minha experiência que os benefícios da limpeza de código são mais visíveis quando eu tenho que manter o código onde a limpeza não foi feita. Onde a limpeza foi feita, minhas alterações consistem em ler o código, localizar um ou dois lugares que precisam ser alterados e partir daí. Se a limpeza não tiver sido feita, adicione uma etapa inicial de leitura do código algumas vezes e tente descobrir o que o autor (às vezes eu) estava pensando quando o escreveu.

eliminar a dívida técnica gera menos suporte técnico e uma base melhor para aprimoramentos

sempre

Uma experiência que tive foi quando estava gerenciando uma equipe de Desempenho do site no meu empregador anterior. Todas as noites, por um período de uma hora a duas horas, o site que minha equipe estava monitorando afundava abaixo dos limites de desempenho aceitáveis ​​devido a informações de captura de bots do site rapidamente. As medidas que a equipe adotou para resolver isso consistiram em fazer login em um sistema de administração manual e bloquear os endereços IP que estavam causando os problemas. Escusado será dizer que isso custou a um membro da equipe horas de sono quase todas as noites. Percebi o que estava acontecendo e levei o BlackBerry de plantão por vários dias para ver o quão ruim era e dar um descanso à minha equipe.

Depois de alguns dias, eu simplesmente fui ao proprietário da empresa e informei que, se não implementássemos um sistema de bloqueio automatizado, para que os robôs tivessem muito mais dificuldade em afetar o desempenho do site, provavelmente perderíamos alguns, se não todos os membros da equipe, devido a fadiga e desgaste. Eles concordaram e implementamos um sistema que nos permitia dormir à noite. O proprietário da empresa entendeu que o custo de alguns dias ou uma semana de desenvolvimento era mínimo comparado ao custo de contratar / treinar novos engenheiros.

Em relação aos dois últimos pontos: entendo de onde vem, conforme explicado em seu post original :

Ou é possível reatribuir alguns desenvolvedores para resolver esses problemas técnicos, enquanto o restante da equipe continua com as orientações do usuário? Isso pode afetar a velocidade da equipe, mas e daí?

"Então, o que" é igual: o proprietário do produto e outras pessoas do lado da empresa ficam infelizes. E quando mamãe está infeliz, todo mundo está infeliz.

No entanto, a linha entre o que deve ser feito e o que pode ser feito é bastante vaga. A aparência do usuário é muito ampla e inclui desempenho e ocorrência de erros. Mas, em alguns casos, o problema subjacente ao baixo desempenho e à alta ocorrência de erros está mais profundo no código. Para dizer isso em suas palavras: uma história pode não passar por uma área imunda, mas ela pode esconder algumas coisas desagradáveis ​​que atacam a história no caminho limpo ao lado dela.

Coisas que não influenciam o desempenho geral são menos interessantes para limpar, mas deve-se avaliar com muito cuidado a influência desses pontos. Mais frequentemente, eles têm uma influência indireta que pode ser bastante substancial.

O maior benefício que uma organização receberá como resultado do pagamento de dívidas técnicas é evitar os juros compostos. Há um exemplo na entrada do blog abaixo que mostra como o valor do principal devido a uma dívida técnica passou de US $ 160 mil para US $ 430 mil em apenas cinco anos. Seria necessário um programador em tempo integral dedicado exclusivamente a atender esse montante de dívida. Isso ajudará a colocá-lo em perspectiva para os tomadores de decisão!

Do blog.acrowire.com .