Você se refere à dívida técnica .
Todos nós acumulamos dívidas técnicas nos produtos que desenvolvemos ao longo do tempo; a refatoração é uma das maneiras mais comuns e eficazes de reduzir essa dívida técnica, embora muitas empresas nunca paguem sua dívida técnica. Essas empresas tendem a encontrar seus softwares anos extremamente instáveis no futuro, e a dívida técnica se torna tão horrível que você não pode pagá-lo gradualmente, porque levaria muito tempo para pagá-lo dessa maneira.
Dívida técnica tem o prazo, porque segue os mesmos comportamentos de dívida. Você recebe a dívida e, enquanto continuar gastando (criando recursos) e não pagando essa dívida, ela só aumentará. Muito parecido com a dívida, quando ela é muito grande, você chega a pontos em que pode querer eliminá-la totalmente com tarefas perigosas, como reescritas completas. Também como a dívida real, à medida que se acumula até um certo ponto, dificulta totalmente sua capacidade de gastar (criando recursos).
Apenas para lançar outro termo na mistura, coesão se refere à forma como um sistema, micro ao nível da linha ou macro ao nível do sistema, se encaixa. Um sistema altamente coeso fará com que todas as suas peças se encaixem muito bem e pareça que um engenheiro escreveu tudo. Sua referência acima a alguém apenas colando seu código até o fim estaria violando a coesão desse sistema.
Gerenciamento da dívida técnica
Existem várias maneiras de gerenciar dívidas técnicas, embora, como a dívida real, a melhor abordagem seja pagá-la com frequência. Infelizmente, como a dívida real, ocasionalmente é uma idéia melhor acumular mais por um curto período, onde, por exemplo, o tempo de comercialização de um recurso pode dobrar ou triplicar sua receita. A parte complicada é pesar essas prioridades concorrentes, bem como identificar quando o retorno do investimento da dívida não vale a pena para o recurso fornecido versus quando vale.
Portanto, às vezes vale a pena acumular a dívida por um curto período, mas esse raramente é o caso e, como em todas as dívidas, quanto menor o período, melhor. Portanto, eventualmente (de preferência rapidamente ), depois que você acumula dívida técnica, é necessário pagá-la; estas são abordagens comuns:
- Refatoração
- Isso permite que você pegue bits de código que foram percebidos apenas como extraviados parcialmente ou após a conclusão da implementação e os coloque no lugar correto (ou mais correto de qualquer maneira).
- Reescrever
- Isto é como uma falência. Ele limpa a lousa, mas você começa com nada e tem todas as oportunidades de cometer os mesmos erros, ou ainda maiores. Abordagem de alto risco e alta recompensa à dívida técnica, mas às vezes é sua única opção. Embora esse seja o caso mais raramente do que muitos dirão.
- Visão geral da arquitetura
- Essa é mais uma abordagem ativa de pagamento de dívida técnica. Isso é feito com alguém com autoridade sobre os detalhes técnicos para interromper uma implementação, independentemente dos planos e cronogramas do projeto, para garantir que ela acumule menos dívida técnica.
- Code Freeze
- Congelar o código de alterações pode permitir que você respire espaço onde sua dívida não aumenta ou diminui. Isso permite que você planeje sua abordagem para reduzir a dívida técnica, na esperança de ter o maior ROI da sua abordagem.
- Modularização
- É como uma abordagem de camada 2 disponível apenas quando você emprega a Visão geral da arquitetura para já ter um sistema modular ou a Refatoração para avançar em direção a um. Quando você possui um sistema modular, pode pagar dívidas em partes inteiras do sistema de maneira isolada. Isso permite que você faça parciais re-escreve, parcial refatoração, bem como minimizar a taxa acumula dívida técnicos, porque o isolamento mantém a dívida somente naquelas áreas onde as características entrou, em oposição a se espalhar pelo sistema.
- Testes automatizados
- Os testes automatizados podem ajudar no gerenciamento de sua dívida técnica, porque podem ajudá-lo a identificar pontos de problemas no sistema, antes que a dívida nessas áreas tenha aumentado muito, mas mesmo depois que eles ainda podem conscientizar os engenheiros sobre as áreas perigosas que eles pode não ter percebido. Além disso, depois de fazer testes automatizados, você pode refatorar mais livremente as coisas, sem se preocupar em quebrar demais. Não porque os desenvolvedores não quebrem as coisas, mas porque descobrirão quando quebram as coisas , depender de testadores manuais em sistemas altamente endividados tende a ter um histórico ruim para encontrar problemas.
