Como você programa em AS3?

Nas duas últimas semanas, estive executando um trabalho em cima de um projeto terceirizado, e quando eu vi o código… eu quase caí pra trás. O que eu via na minha frente era, ao menos pelo que as configurações do arquivo diziam, um projeto AS3. Mas o código, nem de longe parecia com AS3…  aquilo, meus amigos, era um projeto AS3 “programado” em AS1.

O resultado é que eu estou tendo que reescrever tudo. E isso me levou a pensar no seguinte: como programamos a nível nacional? Bem? Mal? Eu nunca tinha parado para notar, nem para pensar nisso, mas a conclusão que eu chego é que a coisa tá mais pra ruim do que pra bom. Basta você dar umas voltas por aí, em algumas comunidades e ver como é o código da maioria dos programadores. E quando tu trabalha com código de diversas pessoas, você vai sentindo que a coisa tá braba.

A conclusão que eu chego é que o pessoal não se preocupa em aperfeiçoar o código, ou ao menos tentar entender o que está escrevendo. “O que eu faço funciona, e tá bom assim”. Na época do AS2 muita gente usava loadMovie(), mesmo existindo a classe MovieClipLoader, e quando chegou o AS3 então… caramba! Mudou praticamente tudo, desde a VM até a estrutura de classes do AS. E eu acredito que isso só piorou as coisa, pois o carinha que programava AS2 como se fosse AS1, e mal conhece OOP, continua na parada, e programando do mesmo jeito.

A princípio o problema é pequeno se você trabalha sozinho (afinal, você que vai fazer manutenção na sua bagunça), mas quando você trabalha com mais de uma pessoa a coisa complica, pois a probabilidade de não compreenderem o seu código (como foi o meu caso, que não entendi nada do que escreveram) é grande.

Uma das coisas que eu sempre fiz enquanto programava era me perguntar se aquilo que eu estava criando estava da maneira mais correta possível, e se eu ficava em dúvida, tirava um tempo para pesquisar como o “mundo” fazia aquilo que eu estava criando, qual a sintaxe, a nomenclatura das classes, dos métodos, propriedades, qual a estrutura de pastas, enfim, tudo. Não é a toa que hoje grande parte das linguagens são orientadas a objeto, e que existam diversos padrões de projeto (design patterns).
A coisa toda tem que estar o mais organizada possível, pois amanhã alguém vai usar o seu código, ou você vai usar o código de alguém, e se o código não for entendido por ambas as partes, vai existir perda de tempo para o programador e consequentemente para a empresa.

Então não adianta de absolutamente nada você criar um projeto AS3, se o teu código não seguir a lógica da linguagem. Um exemplo comum é que hoje não existe mais como você agregar código diretamente a objetos como se fazia no Flash 8. Porque isso ocorre? Simples, porque esse costume só atrapalhava, imagine que você tem 100 objetos no palco, e em cada um deles você tem um código atrelado. Como vai atualizar tudo isso se for necessário?

Hoje o Flash nos fornece o campo Document Class onde tu pode definir uma classe para aquele FLA. Isso quer dizer que você não precisa escrever 1 linha de AS no FLA. O resultado disso é que quem precisa mexer no código, não precisa cavocar em meio a MovieClips para achar o código.

Outra coisa que é comum de se ver é a inexistencia de pacotes de classe. Não é apenas as classes nativas do Flash que precisam de pacotes, as suas também precisam. Os pacotes permitem que você possa organizar as classes, separá-las uma das outras para que você, ou outra pessoa, possam encontrá-las com mais facilidade no futuro. Imagine uma pasta com 100 classes, como saber quais classes são responsáveis por elementos visuais ou quais são responsáveis por carregamento de dados, por exemplo?
Se as classes estiverem em pacotes como os nomes display, ui, net, etc, fica muito mais fácil encontrá-las, pois estão organizadas de acordo com a sua função. Se você tem dúvidas em qual nome deve dar ao seu pacote, dê uma olhada nos pacotes nativos do AS3 mesmo, mas a principio você pode dar o nome que quiser, desde que tenha coerência.

E por falar em organizar as classes, aqui vai a terceira dica: uma classe deve ter apenas um objetivo. Se a sua classe cuida dos elementos visuais de um formulário, ela só faz isso, ela não carrega ou envia dados. Para carregar e enviar dados devemos definir uma outra classe.

Procurar entender os conceitos que envolvem a OOP é quase que um dever para quem quer utilizar uma linguagem como o AS3, e vai além disso. Procure sempre saber que tipo de modificador (private, public, protect ou internal) usar em seus métodos e propriedades. Procure estudar sobre design patterns, eles ajudam bastante em muitas coisas, e estudando eles você praticamente vai dar uma volta sobre todos os conceitos e regras da OOP.

E agora o item mais primordial de todos, que sem ele, de nada vale o esforço: o comentário. Comente o seu código, são uns minutos que você perde hoje, mas algumas horas que você economiza amanhã, só pelo fato de não ter de ficar com aquela cara de bobo pensando “o que esse maldito método faz mesmo?”.

São coisas simples como essas que facilitam o nosso trabalho, e o dos outros também. Eu pretendo apresentar aqui no blog algumas dicas de boas práticas, e também alguma coisa sobre design patterns, aguardem.

2 Comments

  1. opa, seria legal colocar exemplos reais pro pessoal, mostrando porque fica mais fácil… se possível até um ‘o que não fazer’.

  2. Mozart Petter

    Leandro,
    Pretendo fazer um post com dicas e exemplos. Só não o fiz neste, pois o post ia ficar enorme.

Leave a Comment