- Conceito de dívida técnica
- o custo implícito de retrabalho futuro necessário quando se escolhe uma solução fácil, porém limitada, em vez de adotar uma abordagem melhor que pode levar mais tempo
- o custo de trabalho adicional gerado ao escolher a solução mais rápida, e não a mais eficaz
- Tipos de dívida técnica distinguidos pelo engenheiro de software Martin Fowler
- Dívida técnica prudente e deliberada (Prudent & Deliberate)
- a equipe sabe que está assumindo uma dívida, mas considera se “a recompensa de lançar mais rápido é maior do que o custo de pagar essa dívida”
- Dívida técnica imprudente e deliberada (Reckless & Deliberate)
- resultado de decidir seguir “rápido e sujo” porque, embora se conheçam boas práticas de design e seja possível aplicá-las, não há tempo para escrever código limpo
- Dívida técnica prudente, porém não intencional (Prudent & Inadvertent)
- resultado de perceber apenas com o tempo “como o design deveria ter sido”, mesmo tendo desenvolvido um bom software e mantido o código limpo
- Dívida técnica imprudente e não intencional (Reckless & Inadvertent)
- resultado de não saber o suficiente
- Como resolver a dívida técnica
- Gerenciar uma lista de dívidas técnicas
- fazer retrospectivas do projeto, organizar a dívida técnica em uma lista e compartilhá-la
- sempre que surgir uma dívida técnica, registrar o trabalho necessário para resolvê-la junto com o esforço estimado e o cronograma
- discutir em equipe se a dívida técnica deve ser resolvida e quando, e estabelecer um plano de resolução
- Diferenciar dívida técnica boa e ruim
- essa classificação ajuda a definir a prioridade dos maiores problemas
- Refatoração
- organizar as partes necessárias durante o trabalho e refatorar aos poucos
- ao fazer uma refatoração em grande escala, compartilhar a situação com a equipe e informar os riscos e custos da dívida técnica
- Escrever testes
- quanto mais complexo o código e maior a escala da refatoração, mais difícil é modificar o código de uma vez sem bugs
- para evitar efeitos colaterais, é preciso escrever testes
- Definir e cumprir padrões de qualidade
- estabelecer padrões de qualidade para impedir que os programadores publiquem código malfeito
- Nada de mudanças repentinas em regras ou cronogramas
- se as regras relacionadas aos desenvolvedores mudarem continuamente e os prazos forem alterados, fica difícil evitar a dívida técnica
- fornecer cronogramas, metodologias e carga de trabalho realistas para gerenciar a dívida técnica
- A dívida técnica é sempre ruim?
- no livro de Chris Riccomini e Dmitriy Ryaboy, 『Leitura obrigatória! Guia de onboarding para desenvolvedores: o nascimento do desenvolvedor profissional que entende software sustentável e uma cultura de colaboração fluida』, afirma-se: “se for uma dívida treinada para que a equipe consiga resolvê-la mais tarde, isso pode ser chamado de ‘boa dívida’”
- But a dívida técnica pode ter impacto negativo no negócio, portanto deve ser resolvida
- isso aparece na forma de bugs e reduz a experiência do usuário
- quando a dívida técnica piora, fica mais difícil para os desenvolvedores trabalhar dentro da base de código existente
- como o tempo é dividido entre desenvolver novos recursos e corrigir recursos existentes, o ciclo de vida de desenvolvimento de software desacelera e o lançamento no mercado é adiado
Ainda não há comentários.