O que é dívida técnica e você pode evitá-la?

Se você estiver no desenvolvimento de software, terá que lidar com dívidas técnicas em algum momento. Então, para responder à pergunta do título ... não, você não pode evitar. No entanto, existem etapas que você pode seguir para minimizar seus efeitos e garantir que não saia do controle. Pelo menos muito mal.

O que é dívida técnica?

A dívida de tecnologia, como às vezes é chamada, é essencialmente o custo em que você incorre ao longo do tempo por ter um código imperfeito. Mudanças e atualizações no código-fonte têm um custo, assim como adicionar um novo membro à equipe de desenvolvimento, adicionar um novo recurso ou corrigir bugs e corrigir exploits.

Conforme seu projeto fica maior, a base de código se expande e mais pessoas trabalham nesse código, suas vozes e estilos irão se chocar aqui e ali. Talvez você tenha um prazo e uma solução menos do que ideal seja corrigida no código-fonte para terminar no prazo. Talvez você inclua um componente de código aberto que não compreende totalmente para lidar com um recurso, em vez de codificá-lo você mesmo. Ou você pode alternar as bibliotecas entre as versões (de Backbone para React, por exemplo), mas ainda precisa oferecer suporte às pessoas que usam a base de código legada para seus projetos.

Absolutamente nenhuma dessas coisas é ruim . Não por conta própria. Talvez nem um pouco. Mas quando somadas, a dívida técnica em que incorrem terá de ser paga em algum momento no futuro.

Em algum ponto, esse componente de código aberto pode precisar ser substituído (ou bifurcado). Isso vai custar tempo e dinheiro. Em um futuro distante, você precisará remover todo o código do Backbone de seu projeto e parar de oferecer suporte a usuários legados. Novamente, tempo e dinheiro. Aquele patch que você fez para cumprir um prazo? Bem, eventualmente ele será desfeito e precisará de uma correção mais permanente. Tempo e dinheiro. E você terá novos membros em sua equipe que voltarão ao código antigo para fazer tudo isso, precisando entender o código e a lógica dos desenvolvedores anteriores. Tempo. Dinheiro.

Você entendeu.

Embora dívida técnica seja um termo abstrato, muitas vezes metafórico, o custo da dívida técnica é muito real. O reembolso tem um valor monetário e você pode rastrear os juros que paga em horas de trabalho e contracheques. Você pode ver isso na linha de fundo de todo o desenvolvimento de software.

Você pode evitar dívidas com tecnologia?

Como eu disse antes ... não realmente, não. Você acumulará dívidas técnicas em cada projeto que escrever se voltar ao código após seu lançamento. Porém, se você decompor os tipos de dívida técnica, pode minimizar e até contabilizá-la em seus projetos. Se você considerar a dívida de antemão, não é diferente de pegar um empréstimo para um carro ou uma hipoteca. Você analisa o custo, os juros e os benefícios e, então, decide se pode / deseja pagá-los.

Vamos dar uma olhada em alguns dos exemplos que discutimos acima e ver se há uma maneira de evitar, minimizar ou absorver o custo.

Considerando a dívida técnica proposital

Quando dizemos dívida técnica proposital, o que queremos dizer é que sua equipe tomou decisões que você sabe que não estão dentro das chamadas melhores práticas para o idioma ou tipo de projeto em que você está trabalhando. Mencionamos anteriormente que você pode ter um prazo a cumprir. E talvez esse prazo seja difícil e rápido. Talvez haja 0% de chance de ser alterado ou alterado.

É nesse momento que você precisa considerar a possibilidade de contrair um empréstimo e contrair dívidas técnicas.

Você realmente tem três opções aqui:

• Lance software inacabado e com bugs, mas você não faz concessões quanto à clareza e lógica do código
• Extraia recursos que você não consegue aperfeiçoar, mas libere o que você tem que está tão bem escrito quanto possível
• Tome decisões de desenvolvimento que disponibilizem um código "bom o suficiente" para fazer tudo funcionar, mas provavelmente precisarão ser tratadas novamente mais tarde

A terceira opção aqui geralmente é aquela que as pessoas escolhem. Isso está entrando em dívida técnica. E não há nada de errado com isso. Porque você tomou a decisão de fazê-lo .

Pagamento de empréstimo de dívida proposital

Certifique-se de documentar as decisões por trás da escolha de seguir esse caminho em seu código. Anote o que você fez e qual seria a solução ideal. E certifique-se de incluir pelo menos algum tipo de comentário no código-fonte para indicar onde essa solução de tomada de dívidas foi implementada (e se você sabe, sistemas afetados em outras áreas do projeto). Se você não seguir esta etapa, adicionar ao projeto (mesmo em correções de bugs e patches, sem mencionar novos recursos ou uma base de código expandida) pode ser terrivelmente atrasado ao encontrar uma solução de patchwork quando você espera uma completa.

Novamente, essa solução de patchwork pode ser perfeitamente adequada e nunca causar problemas reais. Mas a dívida técnica ainda existe e precisa ser contabilizada.

Considerando a dívida técnica do código legado

Outro tipo comum de dívida técnica é aquela que o WordPress está acumulando agora. WordPress pode ser executado em PHP 5.x. A atualização mais recente, no entanto, dirá aos usuários que deve ser pelo menos o PHP 5.6. Até o final de 2019, o WP Core exigirá PHP 7.x. No entanto, ao aumentar os requisitos, muito código antigo precisa ser atualizado. Porque ainda há código PHP 5.x em plug-ins, temas e no próprio Core.

Sem mencionar o novo Editor de Bloco. Está escrito em JavaScript. Reaja, especificamente. Isso não é nada perto de PHP. Na verdade, muito do WordPress Core está sendo reescrito em JavaScript, aos poucos. Mas todo esse JS tem que complementar e conviver com o PHP também. Aceitar novas tecnologias é ótimo, e é necessário adotar novos requisitos de controle de versão. Mas, ao fazer isso, você está pagando juros sobre a dívida técnica inevitável que você incorre pelo fato de o software já existir há um certo tempo.

Pagando a Dívida do Código Legado

Este é meio difícil porque não há uma ótima maneira de fazer isso. Você poderia pegar a opção nuclear e fazer uma reescrita completa do zero na nova linguagem / estrutura / versão (veja o que fizemos entre Divi 2 e Divi 3.0, indo de Backbone.js para React). Isso ainda não resolve inteiramente o problema da dívida, no entanto, como você ainda tem pessoas usando a biblioteca antiga. Em algum ponto, você terá que descartar o suporte para a base de código legada. O que é como pagar o empréstimo. Até que você tenha que tirar o próximo.

Se essa não for uma opção (ou a melhor ideia para você), certifique-se de não confiar em recursos específicos de idioma ou versão. Os desenvolvedores front-end têm que lidar com isso o tempo todo, já que alguns navegadores oferecem suporte a novos recursos rapidamente, enquanto outros (Microsoft Edge / IE, tosse, tosse) podem nunca adotá-lo. Você pode preparar seus projetos para o futuro aderindo ao básico, o que, por sua vez, fará com que o número de alterações que precisam ser tratadas durante a atualização ou refatoração seja menor do que seria de outra forma.

Considerando vários desenvolvedores ao longo do tempo

Esse é um tipo de dívida de tecnologia que as grandes equipes tendem a acumular com o tempo, pior do que as pequenas equipes de desenvolvimento. Embora até os mais pequenos também precisem se preocupar com isso. Veja, cada engenheiro de software escreve código de maneira diferente. Muito raramente você terá dois desenvolvedores que resolvem o mesmo problema com o mesmo código. Eles podem executar a mesma função e o resultado final pode ser o mesmo, mas o código será escrito na voz do autor (assim como você pode dizer quem escreveu as postagens aqui, por exemplo, como Jason, Nathan, Donjete e Todos tenho estilos distintos). O código não é diferente.

Tendo isso em mente, às vezes a lógica também pode ter vozes diferentes. O que um desenvolvedor pensa está perfeitamente claro, outro desenvolvedor olhará e não terá ideia de por que o código faz o que faz. Esse problema se torna verdadeiramente problemático quando o autor original não está mais disponível para consulta. A dívida técnica acumulada por isso pode ser catastrófica. Mas existem maneiras de lidar com isso.

Pagando a Dívida Técnica de Old Devs

A maneira mais fácil é contratar os melhores desenvolvedores possíveis e nunca deixá-los sair da empresa. Sempre.

Como isso não vai acontecer em torno de 100% das vezes, pagar essa dívida pode ser mitigado um pouco mais fácil do que você imagina. Em primeiro lugar, certifique-se de treinar sua equipe de desenvolvimento para comentar o código. E para comentar bem. Sempre que eles tomarem uma decisão que possa, mesmo remotamente, ser considerada ambígua por outra pessoa, peça que observem por que a fizeram e como a função funciona.

Além disso, certifique-se de que cada desenvolvedor de sua equipe siga um guia de estilo ou conjunto de padrões. O WordPress Core tem um conjunto de padrões de codificação que manterá plug-ins, temas e contribuições do Core embutidos para que qualquer pessoa que vier depois não tenha problemas com isso. O Airbnb tem um guia de estilo para React que foi adotado como um padrão não oficial em todo o setor. Até mesmo guias de estilo e padrões internos evitam que seus desenvolvedores vão longe demais por conta própria, porque esses tipos de commits não serão mesclados a menos que estejam preparados.

Empacotando

A dívida técnica é um problema muito real. Também é um recurso muito real se você souber como gerenciá-lo. Ao ser capaz de decidir quando você assume uma dívida com a tecnologia e como você a paga, seu desenvolvimento pode ser mais rápido e suave do que seria possível. E naqueles momentos em que assumir esse fardo é inevitável, esperamos ter dado a você algumas idéias de estratégias que você pode implementar para torná-lo menos impactante do que poderia ser de outra forma.

Como você lida com a dívida técnica em seus projetos e equipes de desenvolvimento?

Imagem de destaque do artigo por Andrey Suslov / shutterstock.com