Salve, pessoal!

Já
vi e ouvi muitos desenvolvedores falarem
“Por que seguir padrões boas práticas?”. A resposta é realmente
simples. Durante toda a sua carreira profissional você irá se deparar
com muitos projetos, uns com tecnologias mais recentes, outros com
tecnologias novas, outros nos quais trabalharam diferentes
colaboradores de diferentes lugares (Países). Neste caso, se não houver
um padrão, seu projeto tem grande probabilidade de erros com tendências
de pico e vir até mesmo a fracassar. Visando estes problemas, foram
criados padrões de desenvolvimento tanto para se obter códigos claros e
limpos para qualquer desenvolvedor, como também para se obter um melhor
desempenho nos projetos.

Visando
estas questões, vamos ver algumas formas de melhores práticas adotadas
pela comunidade. Também falaremos de alguns mitos relacionados ao
desempenho do Flex.

Requisitos básicos para o artigo

• Flex/Flash Builder
• Conhecimento básico em ActionScript 3.
• Atenção na leitura.

Veremos abaixo algumas dicas de boas práticas para seu projeto e seus códigos.

Utilizando Workspace Comum

Apesar
de ser uma questão simples, não é algo banal. Ainda assim, muitos
desenvolvedores não dão a devida atenção ao assunto. O workspace é
realmente muito flexível, já que cada desenvolvedor pode definir o seu
próprio, porém já tive pessoas no time de trabalho que passaram por
alguns problemas em seu ambiente de desenvolvimento, justamente por não
utilizarem um diretório padrão definido pelo arquiteto. Um exemplo
simples e corriqueiro é: temos um build.xml no qual se tem que buscar
algumas libs ou salvar libs em um diretório X, que será utilizado por
outro build.xml. O build inicial faz uso de uma referência para uma
pasta do worksapace, contudo, como o desenvolvedor não seguiu a
estrutura de diretórios definida pelo arquiteto, estão ocorrendo erros
de gravação de arquivo, já que a pasta X não existe no workspace.

Este é um típico erro relacionado à workspace. Assim, é de suma importância seguir todos os padrões definido pelo arquiteto.

Convenções de Nomenclaturas

Este,
sim, é algo que realmente deve ser levado ao “pé da letra”. Este foi um
problema que já tive a infelicidade de passar. No início do projeto
foram definidas todas as convenções que seriam utilizadas, como:

• Hierarquia de pacotes
• Nomenclaturas de métodos
• Nomenclaturas de variáveis
• Nomenclaturas de Classe
• Nomenclaturas de Interfaces

No início a equipe era pequena, assim tudo estava fluindo muito
bem. Contudo, no andamento do projeto, foi necessário contratar
desenvolvedores externos – aí foi o problema. Como eles não tinham
contato direto com a equipe, resolveram esquecer as Convenções
definidas no início do projeto. Resultado: a equipe interna estava
criando novas Interfaces já existentes, pelo fato de que a galera
externa não estava obedecendo à hierarquia de pastas e nomenclatura de
Interfaces.

Uma convenção legal para utilizar em projetos Flex
Library é aglomerar classes em pacotes. Ex: se em sua lib você tem
vários tipos de Formulários base customizados, seria interessante
colocar todos em com.imaster.formulariosBase.

Compartilhar Flex Library Project

Esta
é uma tarefa realmente simples. Quando em seus projetos vocês tiverem
necessidade de criar e utilizar Flex Library, uma boa pratica é
referenciá-las em seus projetos através da opção Add Project. É muito
comum os desenvolvedores utilizarem a opção Add SWC Folder ou Add SWC,
mas para o desenvolvimento não é a melhor opção.

Comentários

Comentários
deixados no código é a melhor forma de você verificar se a sua lógica
está compatível com regra de negócio, fazer com que qualquer
desenvolvedor que irá dar manutenção em seu código consiga
compreendê-lo e corrigi-lo rapidamente e informar a todos o porquê de
aquele código existir. Muitos desenvolvedores sempre têm a mesma
desculpa: “Eu sempre deixo para colocar comentários no final, quando eu
comitar, pois senão eu perco muito tempo comentando e acabo não
entregando as minhas tarefas”. Este é a verdadeira resposta cretina de
um desenvolvedor preguiçoso, pois no final da tarefa ele se esquece de
comentar ou, pior, faz um comentário “meia boca” que nem ele mesmo
entende, pois já não tem mais cabeça para olhar o código.

O AsDoc tem total suporte a tags Html, assim é gerar API de referência bem formulada.

É
importante criar comentários em todas as classes, informando o porquê
da herança de uma classe, o porquê da implementação da Interface X, o
autor da classe etc.

/**
 * Classe container que permite inclusão de Filhos para a geração de  * formulários dinâmicos para envio de email.
 * 
 * @author Fabiel Prestes.
 * 
 * @includeExample exemplo/classes/ClasseXYZ.html







 * @see com.imaster.ClassABC
 */
public class ClasseXYZ extends ClassABC implements InterfaceJKM

Este
é um pequeno exemplo de como fazer uma documentação de classe. Segue
abaixo uma lista de anotações básicas para uma construção de API
Reference.

• @private: Utilizado quando você quer que um determinado método ou classe seja excluído da API.
• @author: Utilizado para indicar o criador da classe.
• @see: Indica que a classe possui um relacionamento com outra.
• @return: Indica que um método X retorna um determinado tipo de valor
• @includeExample: Indica que no bloco atual de comentário será incluído um arquivo que deverá ser exibido na API.

Assim, lembrem-se: códigos bons são aqueles que Humanos entendem.

Design Patterns

Este
é um assunto que vocês já devem estar cansados de ouvir, assim deixo
apenas o Título para ratificar a todos a importância do mesmo e também
Patterns é um assunto que merece um artigo próprio.

Utilização de Frameworks

O
uso de Framework em projetos irá lhe oferecer alguma garantia de que
sua APP terá sucesso com poucos pontos de erros por uma má
implementação de um algoritmo, pois frameworks abordam comportamentos
padrões que são utilizados em quase toda aplicação. Ex: Swiz,
Carnigorn, Mate. Todos estes são frameworks MVC.

Manipulando Assets

É muito comum que sua aplicação possua arquivos assets como:

• Css

• Vídeos

• Skins
• Fontes

Dessa maneira, para se ter uma hierarquia mais clara e padrão,
é recomendado que estes arquivos sejam armazenados em seu SRC/ASSETS.

O
importante é que apenas criar o diretório assets irá resolver seus
problemas, pois se você colocar nestes muitos arquivos diferentes, vai
ficar totalmente bagunçado e de difícil acesso. É
recomendável que cada tipo de arquivo seja mantido em subdiretórios
diferentes, como:

• /css: Para armazenar os .css que irão definir a cara de sua App.

• /XML: para seus XML.
• /swf: caso você tenha módulos. “Este é questionado por alguns desenvolvedores”.
• /fonts: Para suas fontes
• /imgs: Para suas imagens
• /media: Para vídeos e áudios

Desta maneira seu projeto ficará mais bem organizado e de fácil utilização.

Quando
houver necessidade de utilizar CSS em sua App, evite criar css in-line
ou em blocos script de sua classe. Pois desta forma será muito difícil
alterar a aparência de seus componentes, já que você terá de olhar cada
classe e rastreá-los.

Certo, pessoal, creio que com as técnicas
acima seus projetos terão grande probabilidade de ter sucesso. Sendo
assim, sempre busquem novas leituras para obter novas técnicas para
boas práticas.

Técnicas de desempenho

Agora irei demonstrar algumas técnicas de otimização para obter um melhor desempenho em suas APP.

Técnicas
para se obter um bom desempenho em aplicações são leituras que sempre
busco para me manter atualizado. Abaixo vou listar algumas técnicas que
vocês podem utilizar.

Arrays

Arrays são
muito importantes e muito úteis. Mas, para se obter o máximo deles, é
interessante aplicar algumas técnica. Para o compilador é muito custoso
instanciar um Array com o operador NEW, desta maneira,

Evite:

public var array1:Array = new Array();

Opte por:

          public var array1:Array = [];

    public var array2:Array = ['valor a', 'valor b'];

For

Se
precisar fazer um looping baseado em contadores, evitem utilizar Number.
Utilizem inteiros para fazer a iteração dos valores, é bem mais rápido.

Evite:

         for(var cont:Number = 0; cont < 9; cont++){

Opte por:

        for(var cont:int = 0; cont < 9; cont++){

Outro
caso que pode-se melhorar o desempenho a utilização do FOR com Arrays,
evitem utilizar o length do Array para fazer a comparação.

Evite:

for(var cont:int = 0; cont < array.length; cont++){

Opte por:

    var tamanhoArray:int = array.length;
    for(var cont:int = 0; cont < tamanhoArray; cont++)

Containers        

Algo
muito comum entre os novatos em desenvolvimento Flex é a má utilização
dos componentes, por exemplo aglomerando VBox e HBox para fazer a
orientação de componentes na tela, veja abaixo:

<mx:Panel>
    <mx:VBox>
        <mx:Label text="Label 1"/>
        <mx:Label text="Label 2"/>
    </mx:VBox>







    <mx:HRule/>
    <mx:VBox>
        <mx:Label text="Label 3"/>
        <mx:Label text="Label 4"/>
    </mx:VBox>
</mx:Panel>

Para evitar este tipo de situação é muito mais simples e performático definir o layout do Panel para Vertical.

Uma
outra situação comum é com relação ao tempo de criação de filhos em
containers do tipo TabNavigator, o comum neste container é criar os
filhos a medida que o usuário seleciona a Tab na tela, contudo já
muitos casos assim:

<mx:TabNavigator creationPolicy="all">
<mx:Panel/>
    <mx:Panel/>
</mx:TabNavigator>

Evitem utilizar creationPolicy ALL, pois geralmente há casos em que o usuário nunca irá acessar todas as tabs.