Think First, Code Later!

Quem nunca fez uma burrada no código simplesmente porque não pensou no que ia fazer antes de começar a fazer?

Temos uma tendência enorme a simplesmente começar a fazer a coisa sem pensar exatamente em como que aquilo vai ser feito. Não é incomum você sentar na frente do computador e sair digitando código e ir tentando, e descobrindo o que fazer (descobrir detalhes on-the-fly é normal, o anormal é não ter nem direção certa).

Sabemos que isso é verdade, mas como evitar? No meu ponto de vista, individualmente, a única solução é primeiro pensar e depois codificar, não tem para onde correr! Porém, acredito que algumas técnicas que trazem outros benefícios, também ajudam a resolver esse problema específico de cuspir código sem pensar. Queria falar especificamente de duas técnicas, que sairam do eXtreme Programming. A primeira delas é Pair Programming, e a segunda delas é o TDD. Irei em breve escrever um post mais detalhado sobre as duas técnicas, mas por hora gostaria somente de apontar o que são, e como ajudam nessa questão de primeiro raciocinar pra depois codificar.

Pair programming é a prática de programar a 4 mãos… ou melhor, a 2 cabeças pensantes, mas somente 2 mãos. A idéia é sentar em pares em um único computador, e os dois codificarem juntos. Obviamente os benefícios disso são muitos: a atenção sobre o que está sendo feito é dobrada, um precisa estar dizendo ao outro o que está fazendo, ou pensando em fazer (e com isso já pensamos antes de fazer), funciona como uma revisão de código instantânea (pois ainda não está nem terminado e o seu par já identifica pontos que podem ser diferentes ou melhores), etc, etc….

TDD ( test driven development) por sua vez, trata de sempre testar o que você quer fazer antes mesmo de ter feito. A idéia mais uma vez é pensar no que vai fazer, antes de fazer. Nesse caso é necessário pensar em como você vai testar o código que ainda vai ser construído (por você) e nesse processo de pensar em como vai testar, você provavelmente vai descrobrir como vai codificar. É claro que além desse benefício, você tem outros ainda mais importantes que é a questão de todo o seu código desenvolvido ter teste (automatizado/unitário) que testa aquele código, garantindo ainda mais sua qualidade. E, tendo essa suíte de testes que garantem que meu código está realmente fazendo o que tem que ser feito, eu posso mudar meu código mais tranquilamente meu código pois sei que meus testes unitários (criados utilizando a técnica do TDD) vão atestar minha mudança. Isso dá subsídio para outras práticas (MUITO)importantes como Design Evolutivo e Refactoring.

Maven + Flex

Quem está acostumado com integração contínua, e tem o build do sistema automatizado rodando de tempos em tempos não precisa se desesperar porque já existem soluções para automatizar o build de uma aplicação Flex (actionscript) utilizando Maven.

As opções que eu encontrei são as seguintes: Flex-Mojos e Maven Flex Plugin.

Até onde eu pude perceber o flex-mojos foi o que melhor funcionou para gerar o build da aplicação. Os dois oferecem archetypes para criação de novos projetos, com opções de um projeto flex application (SWF), um library simples (SWC) ou uma library com acesso a API flex (SWC também).

Para demonstrar, vou mostrar a criação do projeto a partir do Maven Flex Plugin:

mvn archetype:generate -DarchetypeCatalog="http://maven.servebox.org"

Essa linha de comando irá lhe perguntar qual o archetype que você quer criar, groupID  e artifactID (que vai ser o nome do projeto). Após isso será gerado um POM.xml dentro de uma pasta com o nome do artefactID que você passou.

O POM deve ter +- essa cara:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>my.group.id</groupId>
    <artifactId>my-artifact</artifactId>
    <version>1.0-SNAPSHOT</version>
    <name>My Simple Project</name>

    <packaging>swf</packaging>

    <pluginRepositories>
        <pluginRepository>
            <id>servebox</id>
            <name>ServeBox Plugin Repository</name>
            <url>http://maven.servebox.org/repository</url>
        </pluginRepository>
    </pluginRepositories>
    <repositories>
        <repository>
            <id>servebox</id>
            <name>ServeBox Plugin Repository</name>
            <url>http://maven.servebox.org/repository</url>
        </repository>
    </repositories>

    <build>
        ...
        <plugins>
            <plugin>
                <groupId>org.servebox.flex</groupId>
                <artifactId>flex-plugin</artifactId>
                <version>2.3.2</version>
                <extensions>true</extensions>
            </plugin>
        </plugins>
    </build>
</project>

Existe ainda a possibilidade de utilizar para o build o Flex-Mojos (caso misteriosamente não funcione com o maven lex plugin), bastando para isso modificar a linhas selecionadas acima por:

<plugin>
     <groupId>org.sonatype.flexmojos</groupId>
     <artifactId>flexmojos-maven-plugin</artifactId>
     <version>3.2.0</version>
     <extensions>true</extensions>
</plugin>

Além disso, você pode inserir configurações no seu build como a licença do flex (muito útil para quem utiliza a biblioteca de charts do flex, que só compila com a licença professional, então tem que incluir a licença nessas configurações), source paths, etc, etc:

<plugin>
  <groupId>org.sonatype.flexmojos</groupId>
  <artifactId>flexmojos-maven-plugin</artifactId>
  <version>3.2.0</version>
  <extensions>true</extensions>
  <configuration>
     <licenses>
         <flexbuilder3>SUA LICENÇA</flexbuilder3>
     </licenses>
     <sourcePaths>
         <path>${basedir}/src/main/flex</path>
     </sourcePaths>
     <mergeResourceBundle>true</mergeResourceBundle>
  </configuration>
  <dependencies>
     <dependency>
         <groupId>com.adobe.flex</groupId>
         <artifactId>license</artifactId>
         <version>3.2.0.3958</version>
         <type>jar</type>
    </dependency>
  </dependencies>
</plugin>

Uma vez gerado o POM, podemos gerar o projeto o projeto do eclipse através do goal:

mvn flex:eclipse

Voilá! Pronto, feito isso basta importar o projeto criado no eclipse. O seu projeto agora pode ser compilado pelo maven, e suporta os goals convencionais do lifecycle do Maven 😉

Primeiro Post

Bom, deixa eu primeiro me apresentar 😛 Meu nome é Thiago Burgos e trabalho no C.E.S.A.R a cerca de 6 anos com desenvolvimento de software. Desses 6 anos, aproximadamente 4 e meio foram como engenheiro de configuração e o resto como engenheiro de software (desenvolvedor).

A idéia desse blog é compartilhar algumas coisas que estou aprendendo e convencer que TI não é algo do outro mundo. No meio disso tudo posso falar sobre outras coisas interessantes tb 😉

É isso, chega de bla bla bla, a partir dos próximos posts já vou escrevendo coisas mais interessantes 😛

PS. Aqui vai um agradecimento especial a @jinmilee do blog Brebotes.com pela sugestão do nome desse blog 😀