Dívida técnica: todo mundo tem, e todo desenvolvedor digno de seu título quer pagá-la, mas como você organiza esse processo?

Implementamos rotação de culturas

No meu artigo anterior, comparei o pagamento da dívida técnica à importância da rotação de culturas na agricultura. Se você continuar a processar um campo (base de código) temporada após temporada para obter uma grande colheita (projetos completos, adicionar recursos, etc.), e não dar a este campo uma temporada para recuperar (pagamento de dívida técnica), então gradativamente começa a perder sua qualidade e produtividade.



Essa metáfora continua apropriada para o desenvolvimento de software; além disso, contém dicas de possíveis estratégias que podem ser utilizadas para saldar dívidas técnicas.



Há uma variedade surpreendentemente ampla de maneiras de saldar dívidas. E isso é muito útil, pois nos dá muitas opções de planejamento.



Para os fins deste artigo, presumiremos que você está trabalhando em uma metodologia de desenvolvimento ágil, mas muitos dos princípios, se refinados de forma criativa, se aplicam a outras metodologias.

Sprints dedicados para pagar dívidas técnicas

Em completa analogia com a rotação de culturas, podemos parar de trabalhar nos recursos a cada quatro sprints ou mais, alocando-os apenas para pagar a dívida técnica.



Prós:

• Os desenvolvedores compartilham um desejo comum de se concentrar exclusivamente em pagar dívidas técnicas
• Os desenvolvedores podem se coordenar para saldar grandes pedaços de dívida técnica trabalhando em conjunto
• As empresas são motivadas a estudar os resultados da dívida técnica que demonstrem a importância do trabalho e o volume restante.

Desvantagens:

• Conflitos de mesclagem começam a surgir à medida que os funcionários fazem grandes volumes de alterações arquitetônicas.
• Com esse caos e instabilidade, pode ser difícil dizer se algo está quebrado se não houver uma boa cobertura de teste.
• Só porque você está trabalhando com dívidas técnicas, os incidentes de suporte nunca desaparecem. Sem uma equipe para ajudar com o aumento das solicitações de suporte, a dívida técnica certamente será prejudicada pelo suporte.

Capacidade dedicada para reembolso técnico da dívida

Nesse modelo, a equipe ágil reserva um determinado número de pontos ou uma porcentagem da capacidade total do sprint para pagar a dívida técnica de forma contínua. Por exemplo, em cada sprint, uma equipe pode realizar 5 storypoins de vários trabalhos de pagamento de dívidas.



Prós:

• Isso garante que o pagamento da dívida técnica seja parte da cultura contínua da organização.
• O trabalho contínuo de dívida técnica pode evitar a necessidade de mais trabalho no futuro.

Desvantagens:

• Se mudanças precisarem ser feitas no sprint, trabalhar no débito técnico será o candidato mais provável para remoção do sprint.
• Ao limitar seu trabalho com dívidas técnicas a pequenas quantias, você torna mais difícil eliminar os pedaços às vezes grandes de dívidas técnicas.

Dedicando funcionários para saldar dívidas técnicas

Este é um híbrido das duas últimas opções. Cada sprint seleciona um desenvolvedor para trabalhar na dívida técnica, enquanto todos os outros continuam com seu trabalho normal.



Prós:

• , , .
• , ,

:

• ,
• , , capacity

Nesse modelo, quando os desenvolvedores planejam seu trabalho, eles agregam ao plano a limpeza do código vizinho e o pagamento da dívida técnica detectável que já está na área de trabalho. Isso está de acordo com o princípio dos escoteiros : sempre deixe o estacionamento (base de código) mais limpo do que estava antes de você.



Em outras palavras, isso significa que, quando você toca no código, ele deve ficar melhor. No código que é tocado com mais frequência, você precisa pagar a maior porcentagem da dívida técnica, portanto, faz sentido pagar a dívida nas áreas do código nas quais você está trabalhando.



Um conceito semelhante é encontrado no livro de Malcolm Gladwell, The Tipping Point.para ver um exemplo do metrô de Nova York. A City Transportation Authority descobriu que desacoplando vagões do metrô, limpando-os de graffiti e garantindo que não haja graffiti em todos os momentos, você pode economizar no efeito de vidros quebrados , nos quais as pessoas acreditam que o estado dos carros não incomoda qualquer um e a taxa de criminalidade pode aumentar. Ao reduzir o número de coelhos e pichações, a agência também poderia reduzir o número de crimes violentos no metrô.



Se transferirmos o mesmo princípio para nossa base de código, precisamos fazer com que, quando você tocar em áreas do código, elas sejam limpas e a dívida técnica seja paga.



Você provavelmente adivinhou pelo que leu acima que sou fã dessa abordagem, mas ainda vamos considerar seus prós e contras.



Prós:

• Dívidas de tecnologia são pagas em áreas que os desenvolvedores naturalmente tocam com mais frequência
• Você não precisa mais "alocar espaço" para pagar dívidas técnicas, é apenas parte do fluxo de trabalho
• Os conflitos de mesclagem são minimizados porque as alterações são feitas apenas em áreas isoladas.

Desvantagens:

• Não há oportunidade especial para fazer grandes mudanças que afetem todo o sistema
• Isso causa "inflação" de storypoints devido ao fato de que um trabalho adicional precisa ser feito com cada ticket. Isso reduz a quantidade de trabalho que pode ser feito em cada sprint.

Principais revisões de código

Acima, falei sobre a estratégia de pagar dívidas técnicas substituindo gradualmente partes do sistema, como no experimento mental com o navio de Teseu , mas e se isso não for suficiente? E se você não tiver tempo para substituir todo o software peça por peça e precisar fazer mudanças mais radicais?



Aqui estão algumas idéias para ajudá-lo:

Dividir um aplicativo em aplicativos menores

Com essa metodologia, dividimos o aplicativo monolítico em aplicativos menores. Freqüentemente, essa abordagem é complementada por Domain Driven Design e / ou microsserviços, mas seu ponto principal é que, se o aplicativo for muito grande para ser substituído, ele pode ser dividido em partes menores, cuja substituição é realista, após o que você pode substituir cada uma parte uma após a outra.



Você também pode implementar esse esquema usando o padrão Strangler Application de Martin Fowler, que cria um novo aplicativo que recebe as mesmas solicitações do antigo e faz chamadas para sistemas legados até que um substituto moderno esteja pronto para cada um deles.



Prós:

:

• ,

capacity

Nesse modelo, os desenvolvedores podem usar o tempo ocioso ou o tempo alocado para débitos técnicos para trabalhar em projetos de longo prazo, como substituir parte ou todo um aplicativo. Uma vez que o progresso suficiente foi feito e o trabalho pode ser iniciado a sério, essas tarefas começam a ser implementadas em um sprint ou série de sprints para implementação e entrega formal.



Seguindo esse padrão, tive muito sucesso em portar aplicativos JavaScript para TypeScript , incluindo passar tempo fora do trabalho (não necessariamente, mas decidi fazê-lo) e aguardar que os ambientes de teste de regressão fiquem online.



Prós:

• Protótipos potencialmente defeituosos que não estão vinculados a ciclos formais de controle de qualidade / fornecimento podem ser identificados e tratados
• Quando o trabalho está pronto para ser incluído no sprint, normalmente já é um trabalho muito concentrado no qual a maioria das variáveis ​​desconhecidas são resolvidas.

Desvantagens:

• Pode ser difícil encontrar uma quantidade significativa de tempo de prototipagem fora do cronograma, a menos que sua organização queira reduzir a alocação de recursos para outros projetos.

Transição completa para o novo aplicativo

Nesse modelo, todo o trabalho no aplicativo antigo é interrompido, exceto a correção de bugs críticos, e começa o trabalho no aplicativo, que se tornará seu substituto completo. Isso é o que as pessoas geralmente querem dizer quando falam sobre reescrever um aplicativo.



Prós:

• Os funcionários podem se concentrar no novo sistema sem realmente considerar o existente.
• O tempo total de execução pode ser menor

Desvantagens:

• Com prazos de entrega muito curtos, a empresa pode sentir que está desperdiçando dinheiro no projeto.
• Atrasos nos prazos podem interferir na entrega do trabalho necessário
• Na verdade, essa abordagem se transforma em um princípio de tudo ou nada.
• Pode não considerar totalmente todos os riscos antes de investir em um projeto de nova plataforma

descobertas

Considere essas opções para atualizar aplicativos continuamente, bem como opções mais radicais. Na minha opinião, não existe uma única melhor opção, você precisa procurar aquela que é mais adequada para sua equipe, produto e organização. Avalie essas abordagens e determine quais opções funcionam melhor para você ao preparar uma “rotação de cultura” para manter sua base de código saudável a longo prazo.