Existe um padrão anti-nomeado para software cultivado historicamente? [fechadas]

Existe um antipadrão que descreve um sistema de software cultivado historicamente em que vários desenvolvedores acabaram de adicionar novos recursos ao sistema, mas ninguém realmente ficou de olho na arquitetura geral nem foram feitas refatorações?

Eu acho que isso acontece quando a gerência / cliente solicita constantemente novos recursos e ninguém refatora nada, apenas acrescenta o que outros desenvolvedores já haviam feito antes.

Um motivo também pode ser que o desenvolvedor está sobrecarregado com o sistema de software e realmente não entende como ele funciona atualmente e apenas adiciona / cola seu código no final (em vez de refatorar o código e alterá-lo).

Com o tempo, fica cada vez mais difícil manter o sistema.

(Gostaria de saber se existem fotos para esse tipo de anti-padrão para deixar isso mais claro para nenhum pessoal de programação - como um carro que foi construído apenas adicionando mais e mais recursos sem pensar no design geral. Como se alguém tivesse a necessidade de rebocar reboques enquanto andava para trás e, em seguida, um engenheiro solda uma barra de reboque na frente do carro. Trabalho feito. Mas agora o capô não abre mais.)

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.

Sua descrição se encaixa na grande bola de lama de Foote e Yoder :

Nos últimos anos, vários autores ... apresentaram padrões que caracterizam arquiteturas de software de alto nível ... Em um mundo ideal, todo sistema seria um exemplo de um ou mais desses padrões de alto nível. No entanto, isso não é verdade. A arquitetura que realmente predomina na prática ainda não foi discutida: a GRANDE BOLA DE LAMA .

Uma GRANDE BOLA DE LAMA é estruturada ao acaso, de forma esparsa, desleixada, com fita adesiva e arame de salvamento, selva de código de espaguete. Todos nós já os vimos. Esses sistemas mostram sinais inconfundíveis de crescimento não regulamentado e reparo repetido e conveniente. As informações são compartilhadas promiscuamente entre elementos distantes do sistema, geralmente até o ponto em que quase todas as informações importantes se tornam globais ou duplicadas. A estrutura geral do sistema pode nunca ter sido bem definida. Se foi, pode ter sido erodido além do reconhecimento. Programadores com um pingo de sensibilidade arquitetônica evitam esses pântanos. Somente aqueles que não se preocupam com a arquitetura e, talvez, se sintam confortáveis ​​com a inércia da tarefa cotidiana de consertar os buracos nesses diques em falha, estão satisfeitos em trabalhar nesses sistemas ...

Por que um sistema se torna uma GRANDE BOLA DE LAMA? Às vezes, sistemas grandes e feios emergem do CÓDIGO DE ATUALIZAÇÃO . O THROWAWAY CODE é um código rápido e sujo, destinado a ser usado apenas uma vez e depois descartado. No entanto, esse código geralmente ganha vida própria, apesar da estrutura casual e da documentação insuficiente ou inexistente. Funciona, então por que consertar? Quando surge um problema relacionado, a maneira mais rápida de resolvê-lo é modificar rapidamente esse código de trabalho, em vez de criar um programa geral apropriado desde o início. Com o tempo, um simples programa descartável gera uma GRANDE BOLA DE LAMA.

Mesmo sistemas com arquiteturas bem definidas são propensos a erosão estrutural. O ataque incansável de requisitos em mudança que qualquer sistema bem-sucedido atrai pode prejudicar gradualmente sua estrutura. Os sistemas que antes eram arrumados ficam crescidos à medida que o PIECEMEAL GROWTH gradualmente permite que elementos do sistema se expandam de maneira descontrolada.

Se essa expansão continuar inabalável, a estrutura do sistema pode ficar tão comprometida que deve ser abandonada. Como em uma vizinhança decadente, segue-se uma espiral descendente. Como o sistema se torna cada vez mais difícil de entender, a manutenção se torna mais cara e mais difícil. Bons programadores se recusam a trabalhar lá. Os investidores retiram seu capital. E, no entanto, como nos bairros, existem maneiras de evitar e até reverter esse tipo de declínio. Como qualquer outra coisa no universo, combater as forças entrópicas requer um investimento de energia. A gentrificação do software não é exceção. A maneira de interromper a entropia no software é refatorá-la. Um compromisso sustentado com a refatoração pode impedir que um sistema afunde em uma GRANDE BOLA DE LAMA ...

• ... Um dos inimigos mais eficazes da lama é o sol. Submeter código complicado à seta de exame pode preparar o terreno para sua refatoração, reparo e reabilitação. As revisões de código são um mecanismo que se pode usar para expor o código à luz do dia.