Diogo Santos

Outro dia destes eu estava assistindo um episódio de The Big Bang Theory no qual um dos personagens menciona o experimento de Schrödinger. Isso me fez lembrar do livro The Pragmatic Programmer (PragProg) que eu li recentemente.

O experimento é mais ou menos o seguinte: imagine um gato dentro de uma caixa fechada com alguma substancia radioativa, onde há 50% de chances desta substancia infectar o gato. Se isso acontecer o gato morrerá, se não ele ficará bem. Então, neste momento o gato está vivo ou morto? Segundo Schrödinger, a resposta correta é ambos. As duas possibilidades acontecem em universos paralelos, em um universo o gato morre e no outro ele vive. Apenas precisamos abrir a caixa para descobrirmos em qual universo nós estamos.

No seriado, o personagem mencionou o experimento para persuadir uma garota que estava na duvida ser deveria sair com ele ou não. Bom, ela só saberá se vale a pena se ela abrir a caixa.

No PragProg, os autores mencionam o experimento fazendo um comparativo com evolução do código em desenvolvimento de softwares:

Think of code evolution along the same lines as a box full of Schrödinger’s cats: every decision results in a different version of the future. How many possible futures can your code support? Which ones are more likely? How hard will it be to support them when the time comes?

O livro questiona o quão flexível à mudanças é o seu software e ressalta a importância de ser ter arquiteturas que suportem mudanças sem grandes custos.

Certa vez, eu vi um projeto ter que ser praticamente todo reescrito quando chegou a hora de criar o módulo que seria usado no Palm. Muitas decisões que foram tomadas no início do projeto não levaram em conta este futuro. Em conseqüência disso, houve um re-trabalho enorme, gerou um estresse gigantesco e exigiu bastante esforço da equipe que virou noites e finais de semana para que tudo fosse entregue no prazo.

O quão flexivel à mudanças é o seu software?

Nesta semana eu terminei de ler o The Pragamatic Programmer: From Journeyman to Master e afirmo com todas as palavras que este livro é essencial para qualquer um que programe profissionalmente.

O livro traz questões importantes como testes, ortogonalidade, desacoplamento, até a forma como se deve fazer a previsão de horas gastas para implementar funcionalidades.

Não me lembro onde li (ou ouvi) um comentário sobre este livro uma vez, mas foi mais ou menos algo do tipo:

“Se todos lessem este livro não haveriam programadores Jr. no mercado, somente Pleno e Senior”

Isso é bem verdade, os autores do livro tentam passar da melhor maneira possível os seus conhecimentos de anos de carreira e acertaram em cheio nessa compilação.

Sem dúvida essa não será a única vez que eu terminarei de lê-lo, pretendo lê-lo outras vezes. Vale muito a pena. Fica aí a dica pra quem ainda não leu o livro.

Foi na apresentação do Guilherme Silveira no Falando em Java 2008 que eu ouvi falar a primeira vez sobre Janelas Quebradas. Depois disso, percebi que este assunto não é nada novo na engenharia de softwares e que ele é abordado num livro que eu acabei de comprar e está na fila pra ser lido: The Pragmatic Programmer: From Journeyman to Master. Trata-se de uma teoria baseada num experimento que criminologistas americanos fizeram:

Um automóvel foi deixado em um bairro de classe alta na Califórnia. Na primeira semana, o carro não foi danificado. Os pesquisadores então quebraram uma das janelas. Poucas horas depois, o carro foi completamente destroçado e roubado por grupos vândalos.

Eu já pude acompanhar este fenômeno duas vezes. Na primeira vez foi um ciclo bem parecido com o experimento original, mas não foi proposital: Eu era criança e morava num prédio onde o irmão de um morador deixou seu carro estacionado. O carro estava bem sujo e meio amassado em algumas partes. Em pouco tempo, este carro virou o assento padrão de todas as crianças do prédio, depois já estava sem as janelas e então mais tarde, dois indivíduos – que não eram crianças – roubaram a bateria do carro. O caso foi sério, no final deu uma grande confusão e os caras que roubaram a bateria acabaram levando a culpa de tudo. Posso apostar que se o carro estivesse em, não vou nem dizer perfeitas, mas em condições normais, assim como todos os carros que estavam na garagem do prédio, isso não teria acontecido.

Na segunda vez que eu vi este fenômeno, ele não chegou a causar muitos estragos. E o que nos poupou de estragos maiores foi o fato das pessoas terem enxergado que tínhamos uma “Janela Quebrada”. Eu falei aqui no blog sobre o Mau Copiador, o cara que senta pra desenvolver o sistema sem saber o que está fazendo e vai copiando o código dos sites, dos outros sistemas da empresa, de todo mundo e de qualquer maneira. Pois é, ele era uma janela quebrada e estava lá na empresa para fazer com que todo um sistema, ou até a empresa inteira fosse por água abaixo, ou melhor, por janela abaixo (com trocadilho).

Acontece que esse cara não era mau em se auto promover para as pessoas que não viam o código que ele gerava e com isso ele acabou ganhando a tarefa de treinar os estagiários que entraram no projeto. E aí não foram só janelas quebradas, foram portas, mesas, cadeiras e tudo mais que viam pela frente até que os gerentes foram alertados e medidas foram tomadas.

Não posso dizer que não houve estragos, eu perdi algumas boas horas corrigindo “cópias mal feitas em larga escala” no sistema, mas nada que um bom Refactoring – e eu gosto de refactoring – não resolvesse.

O Guilherme Silveira apontou o cuidado para não deixar janelas quebradas no sistema como um dos hábitos que os arquitetos de softwares altamente eficazes devem ter.

É impressionante a capacidade que algumas pessoas têm de não pensar no código que está copiando, seja de um exemplo na internet, de um sistema existente da empresa ou até do desenvolvedor da baia ao lado.

Se você for copiar um código, pelo menos, veja se o que você está copiando se aplica ao problema que você quer resolver e, é claro, adéqüe tudo que está copiando ao seu contexto. Caso contrário você estará sendo um… eh… mau copiador, não podendo nem se dar ao luxo de ser chamado de desenvolvedor.

É claro que erros todo nós cometemos, mas também tem aquela velha história:

Errar é humano, persistir no erro é burrice.

Concluindo, prestar muita atenção antes de copiar um padrão, um trecho de código ou qualquer outra coisa. Porque você poderá passar por situações delicadas e até ser considerado uma piada dentro da empresa, se copiar coisas sem saber o que está fazendo.