O que é dívida tecnológica?

Dívidas técnicas são pontos de implementação de engenharia conhecidos que alguém pode ter escolhido conscientemente não implementar agora. Dívidas de tecnologia são comuns, mas devem ser ponderadas criteriosamente. Apresentaremos algumas orientações sobre quando/como avaliá-los.

Idealmente, qualquer parte do código — durante sua primeira implementação deve lidar com todos os casos conhecidos. No entanto, pode haver bloqueadores para ele:

1. Em alguns casos, esperançosamente incomuns — a funcionalidade do produto ou a lógica de engenharia pode não ser clara. Isso também pode ser requisitos de escala ou tráfego pouco claros, levando ao risco de preparação insuficiente ou excessiva para tráfego e escala.
2. Mesmo que a implementação seja clara para os casos de uso incomuns, ela pode ser complexa ou demorada.

Idealmente, todos queremos minimizar as dívidas de tecnologia, mas há momentos em que faz sentido assumi-las.

A necessidade de seguir em frente

Embora não ter todos os detalhes ou a implementação completa possa ser prejudicial, muitas vezes é preciso seguir em frente por alguma combinação dos seguintes motivos:

1. Freqüentemente, é preciso construir ou implementar algo para responder a outras perguntas, aproveitando o feedback parcial do uso ou do cliente. Dithering pode levar a atrasos que são caros, e é prudente arriscar uma implementação não perfeita do que nenhuma.
2. A falta de clareza específica pode ser relativamente insignificante no esquema mais amplo da funcionalidade a ser construída, pode ser adicionada ou corrigida facilmente e não implementar a funcionalidade pode ser mais caro.

qualidades

Quando assumimos uma dívida de tecnologia, decidimos conscientemente trocar talvez uma implementação mais correta por uma implementação parcial. Uma boa dívida de tecnologia:

1. Quando a dívida de tecnologia é abordada, causa menos rotatividade de código para o código da implementação atualmente escolhida e
2. Leva a uma falha normal de alguma parte incomum da funcionalidade. Por outro lado, quando corrigido, é uma melhoria incremental do recurso.

Deve-se aceitar apenas as boas dívidas de tecnologia que atendam às qualidades acima. As perguntas a seguir nos ajudam a avaliar.

Custo

Algumas perguntas a serem feitas ao avaliar o custo da dívida técnica ou caso perdido:

1. Onde está a funcionalidade perdida — por exemplo, na visualização/apresentação de dados ou na geração de dados? Mais especificamente, a funcionalidade perdida leva a dados permanentemente incorretos?
2. Qual é a desvantagem da experiência do usuário? É um caso de uso comum em que os usuários provavelmente tropeçam e ficam insatisfeitos ou um caso incomum à margem de nossa proposta de valor principal?
3. Temos certeza dos detalhes do design e implementação da funcionalidade ausente ou ignorada? Ou preferimos ter feedback sobre a implementação parcial para defini-la?

Assumimos dívidas de tecnologia para certos benefícios:

1. Liberação mais rápida, levando potencialmente a um aumento nas vendas ou na satisfação do cliente.
2. Potencial para obter dados de adoção ou feedback, levando talvez a um melhor design da funcionalidade ausente. Para algumas funcionalidades obscuras, isso pode ser necessário.
3. O custo de oportunidade do esforço de engenharia economizado no curto prazo.

Seguir os princípios fundamentais básicos de design robusto minimiza o retrabalho que envolve o endereçamento da dívida de tecnologia.

Modularidade

Garanta que os serviços e objetos sejam bem pensados ​​com interfaces bem definidas. A modularidade permite que as alterações sejam localizadas sem minimizar a pegada de retrabalho do código.

Tente pensar além do imediato, por exemplo

1. Se atualmente tivermos uma implementação da funcionalidade, mas depois talvez possamos colocar a implementação como uma subclasse de uma interface. Isso facilita a adição de mais implementações posteriormente.
2. Se uma entidade atualmente tiver um valor possível para o campo, mas posteriormente pode ter mais, torne isso uma enumeração.

esquema limpo

Um bom esquema de banco de dados e modelo ORM que modela de perto o caso de uso da vida real geralmente é robusto para mudanças posteriores.

Boas práticas de codificação

1. Mantenha os valores que podem ser ajustados DRY e não profundamente no código. Eles podem ser variáveis ​​de configuração de entrada de tempo de execução ou constantes de código. Esta deve ser uma decisão consciente.
2. Algumas funcionalidades precisam da capacidade de iterar rapidamente ou personalizar por cliente. Use ferramentas de baixo / sem código, elas são fáceis de iterar - até mesmo por um não engenheiro. E há menos código e, portanto, menos rotatividade.
3. As práticas gerais de codificação e design mencionadas acima se aplicam - por exemplo, mantenha o código DRY (é fácil alterar o código em um só lugar), mantenha-o simples (portanto, mais fácil de entender para alterar), etc.
4. Algumas alterações serão aditivas — literalmente baseadas no status quo — por exemplo, adicionar conjuntos de réplicas a um servidor de banco de dados mongo de nó único existente ou fragmentar em um servidor de banco de dados mongo. Caso sejam caros para implementar, a necessidade de tais aprimoramentos pode ser adiada na linha do tempo até que sejam necessários sem nenhum esforço adicional.

Não lidar com todos os casos não é um motivo bom o suficiente para verificar o código. Em vez disso, abaixo está uma maneira de seguir em frente:

1. Continue confirmando o código em sua ramificação com muitos comentários TODOs sobre a funcionalidade pendente ou itens de esclarecimento.
2. Idealmente, resolva todos os TODOs antes de levantar a solicitação pull.
3. Qualquer problema não resolvido torna-se uma dívida de tecnologia - certifique-se de que o revisor de código e o gerente/líder de engenharia relevante sejam marcados / informações, dívida de tecnologia que Jira criou e ID de Jira mencionados no comentário. Espera-se que a revisão de relações públicas reconfirme que a dívida de tecnologia pode ser aceita.
4. Assegure-se de que o código lide até mesmo com os casos não tratados normalmente — por exemplo, o front-end obtém uma resposta de API apropriada para mostrar o erro de entrada de API ainda não-tratada em vez de travar o back-end.
5. Tenha em mente um cronograma para a dívida de tecnologia Jira, possivelmente mantendo-o no próximo sprint para que apareça na chamada de planejamento do sprint para revisão inicial.