Salve pessoal,

hoje irei falar sobre boas práticas que deixarão sua aplicação com um bom desempenho. Já vi e ouvi muitos desenvolvedores falarem “Porque 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 vier 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 e também para se obter um melhor desempenho nos projetos.

Visando estas questões hoje irei demonstrar algumas formas de melhores práticas adotas pela comunidade e também irei falar 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.

Boas Práticas

Vou descrever abaixo algumas dicas de boas praticas para seu projeto e seus códigos.

Utilizando Workspace Comum

Até pode parecer algo banal e simples, mas não é, contudo é uma questão realmente simples que desenvolvedores não dão muita atenção. O workspace é realmente muito flexível já que cada desenvolvedor pode definir o seu próprio, porém já pessoas no time passar 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 tem buscar algumas lib`s ou salvar libs em um diretório X, este será utilizado por outro build.xml. O build inicial faz uso de uma referencia para uma pasta do worksapace, contudo como o desenvolvedor não seguiu a estrutura de diretórios definido pelo arquiteto está 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 o desprivilegio de passar. No inicio do projeto foram definidos todas as convenções que seriam utilizadas no projeto como:

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

No inicio a equipe era pequena assim tudo estava fluindo muito bem, contudo no andamento do projeto foi necessário contratar desenvolvedores externos ai foi o problema. Como estes eram externos e não tinham contato direto com a equipe eles resolveram esquecer as Convenções definidos no inicio do projeto.

Resultado a equipe interna estava criando novas Interfaces já existentes, devido 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 Formularios base customizado, neste caso 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, contudo 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 esta compatível com regra de negocio, fazer com que qualquer desenvolvedor que irá dar manutenção em seu código compreende-la e corrigi-la rapidamente e informar a todos o porquê daquele código existir. Muitos desenvolvedores sempre indagam o mesmo questionamento “Comentário eu sempre deixo para colocar 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 o mesmo esquece-se 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 referencia bem formulada.
É importante criar comentários em todas as classes que criar informando o porque da herança de uma classe, o porque 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</br>

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 exlcuir que um determinado método ou classe seja exlcuido 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á incluso 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 Titulo para que 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 uma porcentagem de garantia que sua APP terá sucesso com poucos pontos de erros por uma má implementação de um algoritmo. Devido que 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
• Videos
• Skins
• Fontes

Desta 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 irá acabar ficar totalmente bagunçado e de difícil acesso aos mesmos. Desta maneira é recomendável que cada tipo de arquivo seja mantido em subdiretórios diferentes sendo. Ex:

• /css: Para armazenar os .css que irá 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 audios

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 dem 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 grade probabilidade de ter sucesso, sendo assim sempre busquem novas leituras para obter novas técnicas para boas praticas.

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 sao muito importantes e muito úteis também, contudo para se obter o Maximo deles é interessante aplicar algumas técnicas como:

É para o compilador é muito custoso instanciar um Array com o operador NEW, desta maneira procure fazer da seguinte forma:

Ex: Evitem:

public var array1:Array = new Array();

Optem por:

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

For

Ao necessitar fazer um looping baseado em contadores evitem utilizar Number utilize inteiros para fazer a iteração dos valores é bem mais rápido.

Ex: Evitem:

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

Optem 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.

Ex: Evitem:

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

Optem 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: aglomerar 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 a casos que o usuario nunca irá acessar todas as tabs.

É isso ai pessoal qualquer coisa é só comentar.