O Guilherme Chapiewski e eu vivemos hoje um diazinho de cão. Ao contrário do que muitos pensam, aqui no trabalho nós temos algumas dezenas de sistemas, todos necessários para o processo de criação, codificação, decodificação e oferta de vídeos na Internet. É coisa pra caramba. E um destes sistemas é um legado de três anos, em vias de se aposentar, que todas as pessoas da empresa já passaram por, mas ninguém é dono ou admite que tem código seu ali. Eis que após uma subida para produção o sistema apresenta lá seus problemas. Nada funciona.
Neste cenário caótico, após quase 10 horas de crise, alguém acaba achando um daqueles trechos de código que fazem você querer ter virado sacerdote em vez de desenvolvedor. Um arquivo de constantes Strings. E alguém resolve fazer algo como:
if(resultSet.getString("USUARIO_TXT").equals(Constantes.PARAMETRO_ADMINISTRADOR){
facaTudoDeMaisImportanteQueOSistemaFaz();
}
Que já é uma pérola por si só, mas não bastante isso o conteúdo da constante é ainda mais legal:
public static Constantes.PARAMETRO_ADMINISTRADOR = "Usuário Administrador Básico";
Percebeu algo errado? Acentos! Primeira regra de hoje:
- Se você precisa de acentos no código fonte, numa literal String ou algo do tipo, sempre escape os acentos.
Por quê? Porque a possibilidade de alguém corromper seus acentos com um encoding diferente é enorme. No nosso caso identificamos nos logs co CVS o momento exato em que um desenvolvedor fez checkout do arquivo, alterou outros arquivos e fez o commit dele no meio dos legitimamente alterados. O arquivo passou de ISO para UTF-8 (que aliás, é o padrão do departamento) nesta operação e todas as Strings com acentos viraram coisas aleatórias. Como as Strings do banco não foram alteradas a comparação acima falhava miseravelmente e o resultado foi um sistema dando problemas em produção e dez horas de trabalho para descobrir isso.
Ainda falta uma medida básica de segurança neste exemplo: testes unitários. Se você é do time que não acredita em testes unitários, um simples teste em JUnit poderia pegar o problema na hora da geração do build que foi para produção. A menos que déssemos o azar de que todas as classes que envolvem esta constante tenham sido alteradas o teste ia falhar e acusar o erro.
Ah, mas e se dermos este azar e o teste unitário não pegar? Teste de integração. Com um servidor de integração contínua você faz com que a cada commit seu código seja baixado, compilado, testado unitariamente e, no final, seja feito um teste que envolve outras partes. O Fit é ótimo para isso.
Não julguem o processo ou ambiente mal: existem responsáveis pela homologação do sistema e eles cumpriram seu papel. Infelizmente não é viável testar manualmente todo o sistema para saber que uma mudança na ponta de cá causou uma mudança acidental na ponta de lá, ainda mais com um sistema deste histórico.
O problema é que ao contrário do que é senso comum testes não são apenas parte da homologação. testes são parte de todo o ciclo de desenvolvimento, tanto na criação como na manutenção de produtos. Ou isso ou você faz como eu e perde sua quinta-feira.
Sempre, ’software’ nos mostra que testes (em todo ciclo) são “coisas” realmente importantes e que devem ser realmente usadas e entendidas.
Infelizmente, na maioria, os testes são realizados somente na “quase-entrega” do produto.