Maus cheiros de software

Os sintomas ruins (ou maus cheiros) de um projeto de software frequentemente permeiam a estrutura global do software. Um software está apodrecendo quando ele começa a exalar (apresentar) um dos seguintes odores (problemas):

• Rigidez
• Fragilidade
• Imobilidade
• Viscosidade
• Complexidade desnecessária
• Repetição desnecessária
• Opacidade

RIGIDEZ

Rigidez é a tendência do software de ser difícil de alterar, mesmo de maneira simples. Um projeto é rígido quando uma única modificação provoca uma sucessão de alterações subsequentes em módulos dependentes. Quanto mais módulos precisam ser alterados, mais rígido é o projeto. A equipe de desenvolvimento é solicitada a fazer o que parece ser uma alteração simples. Examinam a modificação e fazem uma estimativa razoável do trabalho necessário. Depois, no entanto, à medida que trabalham nas alterações, descobrem que existem consequências imprevistas. A equipe se descobre perseguindo a alteração em partes enormes do código, modificando bem mais módulos do que tinham estimado inicialmente e descobrindo diversas outras alterações que precisam fazer. No final, as mudanças demoram muito mais tempo do que a estimativa inicial.

FRAGILIDADE

A fragilidade é a tendência de um programa estagnar em muitos lugares quando uma única alteração é feita. Frequentemente, os novos problemas estão em áreas que não tem uma relação conceitual com a área alterada. Corrigir esses problemas leva a ainda mais problemas e a equipe de desenvolvimento começa a parecer um cachorro correndo atrás do rabo.

IMOBILIDADE

Um projeto é imóvel quando partes que poderiam ser úteis em outros sistemas, mas o trabalho e o risco envolvidos na separação dessas partes do sistema original são grandes demais. Essa é uma ocorrência infeliz, porém muito comum.

VISCOSIDADE

A viscosidade aparece em duas formas: viscosidade de software e viscosidade do ambiente. Quando se deparam com uma alteração, os desenvolvedores normalmente encontram mais de uma maneira de fazê-la. Alguns deles preservam o projeto; outros, não (isto é, produzem soluções malfeitas). Quando os métodos que preservam o projeto são mais difíceis de usar do que as soluções malfeitas, a viscosidade do projeto é alta. A viscosidade do ambiente ocorre quando o ambiente de desenvolvimento é lento e ineficiente. Por exemplo, se os tempos de compilação forem muito longos, os desenvolvedores ficarão tentados a fazer alterações que não obriguem grandes recompilações, mesmo que essas alterações não preservem o projeto. Se o sistema de controle de código-fonte exigir horas para a verificação apenas de alguns arquivos, os desenvolvedores ficarão tentados a fazer alterações que exijam o mínimo de check-ins possíveis, independentemente de o projeto ser preservado.

COMPLEXIDADE DESNECESSÁRIA

Um projeto tem o mau cheiro de complexidade desnecessária quando contém elementos que não são úteis no momento. Isso acontece com muita frequência, quando os desenvolvedores antecipam mudanças nos requisitos e colocam recursos no software para lidar com essas mudanças em potencial. Isso pode parecer bom em um primeiro momento. Afinal a preparação para futuras mudanças deve manter o nosso código flexível e evitar alterações apavorantes mais adiante. Infelizmente, muitas vezes o efeito é justamente o oposto. Preparando-se para muitas possibilidades, o projeto se torna sujo, contendo construções que nunca são utilizadas.

REPETIÇÃO DESNECESSÁRIA

Recortar e colar podem ser operações de edição de texto úteis, mas podem ser desastrosas na edição do código. Com frequência, os sistemas de software são baseados em dezenas ou centenas de elementos de código repetidos. Quando o mesmo código aparece inúmeras vezes, de formas ligeiramente diferentes, está faltando uma abstração para os desenvolvedores. Encontrar todas as repetições e eliminá-las com uma abstração adequada pode não estar na lista de prioridades, mas tornaria o sistema mais fácil de entender e manter. Quando existe código redundante no sistema, o trabalho de alterar o sistema pode se tornar árduo. Os erros encontrados em tal unidade repetida precisam ser corrigidos em cada repetição. Contudo, como cada repetição é ligeiramente diferente das outras, a correção nem sempre é a mesma.

OPACIDADE

Opacidade refere-se à dificuldade de compreensão de um módulo. O código pode ser escrito de maneira clara e inteligível ou de maneira opaca e enrolada. Ainda, o código tende a se tornar cada vez mais opaco com o tempo. É necessário um esforço constante a fim de manter o código claro e a opacidade diminuir.