Google Analytics

quinta-feira, 16 de junho de 2011

O conjunto básico

E que tal se a gente conversasse hoje sobre o que são as coisas fundamentais num projeto de software?

Todo projeto de software deve conter os itens listados abaixo. Quanto mais cedo eles forem criados, melhor. Recomendo até que eles sejam criados / adicionados na ordem em que os listo.

  • Sistema de bug tracking. Exemplos: Bugzilla, Mantis, etc.
    Por que deve ser o primeiro item? Porque bugs ocorrem desde o primeiro dia de trabalho no projeto. Pode ser um erro em algum diagrama, algum problema que um programador encontra no código de outro como resultado de uma revisão, etc. Se ganha muito se isto for registrado de modo centralizado e CONCISO.
    Deve ser um sistema orientado para desenvolvedores, de modo a ajudar não só no controle, mas no processo de correção, ou seja:
    • Deve ter, no mínimo, os estados New (não corrigido ainda), Fixed (bug corrigido, correção comitada no source control) e Verified (um release-build que contém a correção foi criado, testado para o bug e não se viu o dito cujo ocorrer novamente). Outros estados, embora não sejam fundamentais, ajudam muito. Exemplos: Assigned (tem alguém corrigindo o bug - isto evita que, em grupos grandes, dois desenvolvedores trabalhem na mesma coisa sem saber), Closed (confirmado pelo usuário que reportou o bug que ele não acontece mais).
    •  Os desenvolvedores precisam poder criar entradas neste sistema. Parece mentira, mas tem muita equipe que acha que desenvolvedor não acha bug... Surpresa: Eles acham MUITOS. E normalmente os acham MUITO ANTES que o software entre em uma fase de testes.
    • Deve permitir que os desenvolvedores coloquem anotações acerca da investigação das causas do bug no próprio bug report. (As seguintes Regras de Ouro se aplicam: "Não separe o que deve estar junto.", "Guarde as coisas perto de onde elas são usadas."
  • Sistema de versionamento de fontes. Exemplos: subversion, git, cvs.
    Deve ser colocado no ar bem cedo, pois devemos ter o histórico desde o início. Muita gente mostra resistência em colocar material no sistema de versionamento antes de ter "algo que funcione". Não é uma boa idéia. Vença a resistência e comece a versionar no primeiro dia.
    Detalhes importantes: 
    • Não existe um sistema de versionamento que seja absoluto. Cada método de trabalho casa melhor com um sistema diferente. Não se renda a modismos na hora de escolher. Escolha com a cabeça.
    • Um bom versionamento implica em ter tudo no mesmo sistema e na mesma árvore de diretórios. Um comando de checkout único deve baixar todo o material necessário para trabalhar no projeto.
  • Build automatizado e integração contínua. Mesmo antes de ter um software funcional (antes de começar a programar), ponha no ar um sistema de integração contínua e automatize o processo de build. O que se quer é que se produza os deliverables do software com apenas um comando e, ao se commitar algo no sistema de versionamento, o sistema de integração contínua faça o build e testes sozinho. Importante: Considero parte dos deliverables a geração de tags no sistema de versionamento, de modo a permitir a recuperação dos fontes usados em cada build.
    Na fase inicial do projeto, ainda não temos código, mas já devemos fazer um sistema automático que gere o pacote de instaladores, documentos (manual do usuário, etc), mesmo que gere um instalador com um executável tipo "return 0", que não faz nada.
  • Unit tests. Automatizados, de preferência com possibilidade de rodá-los automaticamente durante o processo de build. Os unit tests devem ser aprimorados ao longo do projeto, por exemplo, quando se encontra um bug (ver O procedimento de correção de bug). Importante: Unit test é feito e rodado pelos desenvolvedores. Pode (e deve, sempre que possível) ser rodado automaticamente no build também; mas o fundamental é que os desenvolvedores possam rodar cada unit test de modo simples e na sua cópia de trabalho dos fontes.
  • Número de versão no software. Sem números de versão não tem como ter rastreabilidade do software. Não tem como saber o que foi testado; não tem como saber quando bugs foram corrigidos. Mais detalhes no artigo Identificadores de Versão.
  • Testes funcionais. Deve-se ter uma rotina de testes funcionais bem definida e executá-los seguidamente ao longo do projeto. Detalhes importantes: 
    • O ambiente de teste (máquinas, dispositivos, etc) deve ser diferente do usado no desenvolvimento. Testes na máquina do desenvolvedor sempre funcionam (a não ser que seja um desenvolvedor muito relapso)...
    • Usar sempre o material gerado nos builds automatizados para os testes. Nunca rode testes funcionais oficiais usando material gerado nas máquinas de desenvolvedores.