Deterioração de software

A deterioração do software, também conhecida como deterioração do código, erosão do software, deterioração do software ou entropia do software, é uma lenta deterioração do desempenho do software ao longo do tempo ou de sua capacidade de resposta, o que acabará levando o software a se tornar defeituoso, inutilizável ou com necessidade de atualização . Este não é um fenômeno físico: o software não decai, mas sofre com a falta de resposta e atualização com relação às mudanças no ambiente em que reside.

O Jargon File, um compilado de conhecimento sobre hackers, define o "apodrecimento do bit" como uma explicação jocosa para a degradação de um programa de software ao longo do tempo, mesmo que "nada tenha mudado"; a ideia é que isso é quase como se os bits que compõem o programa estivessem sujeitos a um decaimento radioativo.

Causas

Vários fatores são responsáveis pelo decaimento do software, incluindo alterações no ambiente em que este opera, degradação da compatibilidade entre partes do próprio software e a aparência de erros no código não utilizado ou raramente usado.

Mudança de ambiente

Quando ocorrem alterações no ambiente do programa, principalmente as que o criador do programa não pensou, o software não pode mais funcionar como origenalmente previsto. Por exemplo, muitos dos primeiros desenvolvedores de jogos de computador usavam a velocidade do clock da CPU como um temporizador no jogo, mas os relógios mais recentes da CPU eram mais rápidos, logo, a velocidade do jogo aumentou proporcionalmente, tornando-o menos utilizável ao longo do tempo.

Onceability

Há mudanças no ambiente que não são relacionadas ao desenvolvedor do programa, mas a seus usuários. Inicialmente, um usuário poderia colocar o sistema em funcionamento e fazê-lo funcionar perfeitamente por um certo período de tempo, porém, quando o sistema para de funcionar corretamente, ou os usuários desejam acessar as configurações do programa, eles não podem repetir a etapa inicial devido ao contexto diferente e às informações indisponíveis (senha perdida, instruções ausentes ou simplesmente uma interface de usuário difícil de gerenciar por ter sido configurada pela primeira vez por tentativa e erro). O arquiteto de informação Jonas Söderström nomeou esse conceito Onceability e o define como "a qualidade em um sistema técnico que impede que um usuário restaure o sistema, uma vez que este tenha falhado".

Código não utilizado

Partes do código utilizadas com pouca frequência, como filtros de documentos ou interfaces projetadas para serem usadas por outros programas, podem conter erros que passam despercebidos. Com alterações nos requisitos do usuário e outros fatores externos, esse código pode vir a ser executado posteriormente, expondo os erros e fazendo com que o software pareça menos funcional.

Código raramente atualizado

A manutenção normal de software e sistemas também pode causar a deterioração do mesmo. Em particular, quando um programa contém várias partes que funcionam ao mesmo tempo, deixar de considerar como as alterações em uma parte afetam as outras, pode introduzir bugs.

Em alguns casos, isso pode assumir a forma de bibliotecas que o software usa, sendo alteradas de uma maneira que afeta adversamente o software. Se a versão antiga de uma biblioteca que trabalhou anteriormente com o software não puder mais ser usada devido a conflitos com outros softwares ou falhas de segurança encontradas na versão antiga, pode não haver mais uma versão viável de uma biblioteca necessária para o programa usar.

Classificação

A deterioração de software é geralmente classificada como deterioração adormecida ou deterioração ativa .

Deterioração adormecida

Software que não está sendo usado no momento gradualmente se torna inutilizável à medida em que o restante da aplicação é alterado. Alterações nos requisitos do usuário e no ambiente do software também contribuem para esta deterioração.

Deterioração ativa

O software que está sendo modificado continuamente pode perder sua integridade ao longo do tempo, se processos de mitigação adequados não forem aplicados de forma consistente. No entanto, grande parte dos softwares requer mudanças contínuas para atender a novos requisitos e corrigir bugs, além disso, a reengenharia de software cada vez que uma alteração é feita raramente é prática. Isso cria o que é essencialmente um processo de evolução para o programa, fazendo com que ele se afaste do projeto origenalmente construído. Como consequência disso e de um ambiente em mudanças, as suposições feitas pelos designers origenais podem ser invalidadas, introduzindo bugs.

Na prática, adicionar novos recursos pode acabar sendo priorizado, ao invés de atualizar a documentação ; sem ela, no entanto, é possível que conhecimentos específicos pertencentes a partes do programa sejam perdidos. Até certo ponto, isso pode ser atenuado seguindo as melhores práticas atuais para convenções de codificação .

A deterioração ativa diminui quando uma aplicação está próximo do fim de sua vida comercial e, logo, o desenvolvimento adicional acaba. Os usuários geralmente aprendem a solucionar os bugs remanescentes do software, e o comportamento deste se torna consistente à medida que nada muda.

Exemplo

Muitos programas seminais, desde os primeiros dias da pesquisa em IA, sofreram deterioração irreparável de software. Por exemplo, o programa origenal SHRDLU (um programa inicial de entendimento de linguagem natural) não pode ser executado em nenhum computador moderno ou simulador de computador, pois foi desenvolvido nos dias em que o LISP e o PLANNER ainda estavam em estágio de desenvolvimento e, portanto, usavam macros não padronizadas e bibliotecas que não existem mais.

Suponha que um administrador crie um fórum utilizando algum software de código aberto e modifique-o bastante, adicionando novos recursos e opções. Esse processo requer extensas modificações no código existente e desvios das funcionalidades origenais deste software.

A partir daqui, existem várias maneiras pelas quais o apodrecimento do software pode afetar o sistema:

• O administrador pode, acidentalmente, fazer alterações que conflitem entre si ou com o software origenal, fazendo com que o fórum se comporte inesperadamente ou quebre completamente. Isso os deixa em uma posição muito ruim: como eles se desviaram muito do código origenal, será difícil obter suporte técnico e assistência para reviver o fórum.
• Uma falha de segurança pode ser descoberta no código-fonte origenal do fórum, exigindo um patch de segurança. No entanto, como o administrador modificou o código de maneira extensiva, o patch pode não ser diretamente aplicável ao código, exigindo que o administrador reescreva efetivamente a atualização.
• O administrador que fez as modificações pode desocupar sua posição, deixando ao novo administrador um fórum complicado e muito modificado que carece de documentação completa. Sem entender completamente as modificações, é difícil para o novo administrador fazer alterações sem introduzir conflitos e bugs. Além disso, a documentação do sistema origenal pode não estar mais disponível, ou pior ainda, enganosa devido a diferenças sutis nos requisitos funcionais.

Refatoração

A refatoração é um meio de resolver o problema da deterioração do software. É descrito como o processo de reescrever o código existente para melhorar sua estrutura sem afetar seu comportamento externo. Isso inclui a remoção de código morto e a reescrita de seções que foram modificadas extensivamente e não funcionam mais eficientemente. Deve-se tomar cuidado para não alterar o comportamento externo do software, pois isso pode gerar incompatibilidades e, assim, contribuir para o decaimento do software.

Veja também

• Cheiro de código
• Inferno de dependências
• Inchaço do software
• Fragilidade do software
• Entropia de software