Build do Eclipse não vale!

Um anti-pattern que já vi muito por aí nos projetos Java em que participei é o Build do Eclipse.

Ao invés de usar um script de build automatizado para criar um pacote entregável (JAR, WAR, EAR), o sistema é colocado em produção simplesmente copiando os .class criados pelo Eclipse. Também são copiados o .project, .classpath e .settings e, às vezes, até as pastas de controle versão (.svn).

O Eclipse é ótimo para ajudar no desenvolvimento com seu code-completion, recompilação a cada arquivo salvo, sugestões, code snippets, atalhos de teclado e o montão de plugins. Também é excelente para refatorar de maneira eficiente e segura. E até para disparar um script de build.

Mas o Eclipse não deve ser usado como ferramenta de build.

Por que não?

  1. Porque builds tem que ser automatizados
  2. Usar builds do Eclipse, é um forte indicador de que você não automatiza seus builds.

    OK, você pode automatizar o build criando um sistema que abre o Eclipse, dispara os cliques necessários e copia os arquivos. Mas ninguém faz isso. E, convenhamos, essa ideia é estúpida. Usar uma ferramenta de build especializada como Ant ou Maven é muito, mas muito, mais simples.

    E por que automatizar seus builds é bom?

    Builds são receitas de bolo. São trabalhos repetitivos e tediosos. Não são processos criativos. Humanos são bons em criar e não em repetir.

    Com menos intervenção humana, seus builds terão menos erros. E você liberará tempo para trabalho criativo, que é o que os seus programadores deveriam estar fazendo.

  3. Porque você precisa usar sempre a mesma IDE
  4. Bons programadores Java tem opinião forte sobre qual IDE é melhor. Se você forçá-lo a usar uma IDE diferente, você fará um programador menos feliz e programadores bons precisam estar felizes para produzir código de qualidade.

    Pode parecer besteira, e talvez seja. Mas restrições de IDE são desnecessárias. Com um bom script de build, você se liberta de qualquer acoplamento com uma IDE específica e permite flexibilidade na hora de desenvolver.

  5. Porque você não está integrando continuamente
  6. Integração Contínua é uma das práticas mais interessantes (e usadas) do XP. Integrar continuamente é bom em qualquer contexto e em qualquer metodologia. E ajuda bastante na diminuição de vários riscos de projetos de software como descoberta tardia de problema de integração e defeitos, falta de código entregável e baixa qualidade interna.

    Mas para integrar continuamente você precisa ter, no mínimo, builds automatizados. Se o seu servidor de Integração Contínua precisa do Eclipse instalado, isso é um mal sinal.

    Para aproveitar todo o valor da Integração Contínua, além de builds automatizados, é importante que você tenha testes automatizados e análise estática de código. Assim, você testará seu código constantemente e evitará que código sem testes, duplicado e complexo entre em seu repositório.

Generalizando
Na verdade, um nome melhor para esse anti-pattern seria Build da IDE, porque o mesmo vale para Netbeans, IDEA ou qualquer outra IDE.

Mas, enfim, build do Eclipse não vale!

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s