A teoria da Janela Quebrada

Como não tive a segunda aula nesta terça-feira, resolvi começar a ler o famoso "The Pragmatic Programmer", do Andrew Hunt e David Thomas. O que mais me chamou a atenção no momento de leitura foi a "teoria da janela quebrada".

Vocês já perceberam que certos bairros da sua cidade estão totalmente destruidos, com prédios pichados, com janelas quebradas e aquele odor claro de "não deveria estar aqui". Enquanto outros parecem ter saído de um daqueles filmes onde os mocinhos vivem em um local próximo ao paraíso?

Já pensou o que leva o "paraíso" se tornar aquele bairro destruído?

De acordo com o livro, o culpado disso seria uma janela quebrada. Uma janela quebrada passa a impressão de abandono e com isso logo logo surge uma outra janela quebrada. De repente um pichação aqui e outra ali e BUUM o prédio ou casa está abandonado.

Com software a história não é diferente. Um código sujo, faz com que o programador perca o interesse pelo software. Pois ele começa a ter a impressão que é o único que se importa com as boas práticas. Com isso ele fica desmotivado e passa a não se importar tanto se aquela é a melhor maneira de se resolver o problema e passa apenas a prestar atenção se "a coisa funciona".

Para evitar que um lindo software se torne aquele software que você odeia tocar por que sabe que o código dele é mais sujo que o banheiro da rodoviária que não é limpo desde o ano passado, temos que tomar uma atitude. Ao ver algo errado, que não deveria estar ali, que não faz sentido, se mova. Alerte a equipe, tente mudar aquele trecho para se adequar as boas práticas. Caso não haja tempo para isto, ao menos coloque um aviso alertando para que na próxima oportunidade você ou o desenvolvedor que pegará o software dar um "trato" naquele código.

Custará um poquinho de tempo, mas refatoração sempre agrega valor ao software. Pode ser em horas do suporte economizadas até tempo de processamento :).