Refatorando Padrões

Faz pouco mais de 4 meses que comecei a utilizar Rails em alguns projetos, mas Java ainda é minha linguagem do coração, e algo que me surpreendeu muito foi a filosofia por trás do Rails, ele não é um framework matador de horda de dragões, e não é pra ser mesmo, seu próprio criador David Heinemeier Hansson não tem a intenção de adicionar um milhão de funcionalidades, e tem motivo pra isso, trabalha na 37signals, prercursora da metodologia Getting Real, uma verdadeira aula de como evitar a burocracia e extrair muita produtividade, considero o livro radical em alguns pontos, mas isso é questão de opinião, e é claro adequação à realidade do seu projeto.

E aqui cabe a pergunta, você não está fazendo coisas demais no seu projeto ?

Os frameworks hoje em dia parecem querer abraçar o mundo, querem estar em todos os tipos de projetos, seus criadores prometem funcionalidades novas e/ou extravagantes a cada dia, e nessa vontade de fazê-lo crescer, vai tornando-o apenas cada vez mais “gordo”, de difícil manutenção, e com isso nenhum projeto é ajudado. Sem contar a ausência de testes em muitos deles. Não quero dizer que Rails é o melhor de todos, estou citando apenas a filosofia por trás dele, há outros frameworks ótimos no mercado, tudo depende de pensar no que essencialmente o projeto precisa e com isso encontrar o framework correto.

Uma resposta para a enorme “gordura” de alguns frameworks é sempre: “Seu projeto tende a crescer, você vai precisar dos demais recursos oferecidos”. Sinceramente não gostaria de precisar usar tudo, não quero complexidade demais no projeto só para ganhar mais manutenção. Gosto da filosofia K.I.S.S. (Keep It Simple Stupid). O que o meu cliente vai ganhar com esta funcionalidade X ? Ela é realmente é necessária ? Quanto mais simples, menos manutenção, mais tempo você tem para funcionalidades novas e simples.

Vocês podem pensar que isso é preguiça mas não é, recentemente houve um caso interessante, eu precisava adicionar um editor de texto na aplicação, escolhi o excelente FckEditor, ele possui ótimas funcionalidades para um editor de texto em browser, a primeira coisa que fiz foi reduzir a quantidade de botões. Apresentei ao cliente, ele usou um pouco e disse “acho que o pessoal vai estranhar um pouco a princípio, tem como melhorar o layout ?”, mas o problema não era layout, observando como ele usou a ferramenta reduzi novamente a quantidade de botões para ter apenas o que ele realmente precisava e apresentei novamente. O resultado: “Puxa o layout melhorou mesmo, mais intuitivo”, ele nem reparou que a quantidade de botões foi diminuída, eu apenas apresentei o que ele precisava, e nem uma linha a mais. Se o seu cliente precisa de uma funcionalidade supérflua, que ele pediu por impulso, convença-o do contrário, ou ambos sofrerão com uma funcionalidade que talvez nem seja usada, está lá apenas para formentar a entropia.

É como o novato que lê um livro sobre padrões de projeto e acha que deve usar todos de uma vez, é necessário pensar no básico. Keep It Simple!

Frequentemente ouço outros programadores e até amigos falando mal de Javascript, a frase mais comum é: “Não dá pra debugar!”, será mesmo ? Javascript está aí há mais de uma década em grande parte dos websites e ninguém até hoje se importou em criar uma ferramenta direcionada ? Ou será preguiça/medo de encarar a linguagem ?

Javascript é uma linguaguem de programação, é interpretada, e orientada a objetos. Sim, isso mesmo que você leu, Orientada a Objetos, isso surpreende muita gente, normalmente os que tem mais preconceito e preguiça de pesquisar, inclusive ela obedece uma especificação, a ECMAScript, dá qual é baseada a ActionScript, conhecida pelo pessoal de Flash, ou seja há um padrão e versões desta linguagem.

Pode-se dizer que Yahoo e Google investem muito nela, o que seria de seus sites sem Javascript, as maravilhas do Gmail, Yahoo mail, Google Maps, entre vários outros… O que seria da técnica AJAX sem Javascript.

Querem debugar Javascript ? É só usar o Venkman e/ou o fenomenal Firebug, além de suporte a breakpoints ele vem com vários outros recursos como inspeção de código javascript e css, logging, profile, pode-se até mesmo alterar a árvore DOM e ver os resultados sem precisar atualizar a página.

Querem codificar Javascript ? A IDE Aptana (baseada no projeto Eclipse) resolve seus problemas, com suporte a code insight, auto complete, entre outros… não somente para Javascript, mas também para html e css. Para quem já utiliza o Eclipse basta instalar o plugin, ou mesmo utilizar o WTP. Para o pessoal de Rails uma ótima notícia, o RadRails será integrado ao Aptana em breve. Há ainda inúmeras e ótimas IDEs pagas para este tipo de serviço.

Javascript só serve para validar dados ? Bom, alguns exemplos do que o Javascript é capaz: Script.aculo.us, Dojo, Lightbox, ModalBox. Para o pessoal mais avançado, vale a pena dar uma olhada no excelente framework Prototype, base para vários desses projetos.

Desculpem-me se fui muito enérgico neste post, mas fazem 10 anos que utilizo Javascript e até hoje ouço das pessoas os mesmos motivos para preconceito. Muita coisa mudou, a linguagem evoluiu muito, mas a vontade de aprender das pessoas, parece que não, ainda mais vindo de uma área onde é uma obrigação estar em constante atualização.

Posso dizer que já criei muitas páginas HTML de dar medo, sem o mínimo de obediência aos padrões estabelecidos pela W3C, ou mesmo seguindo a sintaxe correta, mas com tags erradas, semântica incorreta. Aprende-se mais a cada dia e hoje tento fazer o meu melhor em seguir a semântica, eu digo tento, porque os browsers teimam em me desafiar.

Não é novidade que o Internet Explorer é, de longe, o pior caso em seguir padrões web, mas simplesmente não podemos abandoná-lo. Que o digam os meus clientes, que de forma alguma trocam de navegador.

Não sou bom em design, nunca fui, dou minhas patadas, mas para bolar layouts de sites novos eu sempre passo para um outro amigo, também freelancer. Infelizmente ele, embora crie layouts muito bons, não tem experiência em padrões web, sendo assim, cabe a mim adequar o código fonte, e como já disse, faço o melhor que posso. Mas quando o seu layout deve ser flexível e um determinado elemento teima em não se apresentar corretamente em um certo “browser”, é necessário parar para pensar: “sacrifico o layout ou a semântica desse bloco ?”

O tempo urge pelo sacrifício da semântica, os mega indexadores preferem o sacrifício do layout. Eu opto tentar ao máximo ir pela semântica, mas não sou fanático ao ponto de jogar fora o layout só porque um elemento não funciona direito no browser X ou Y. Se o elemento que fugirá da semântica é de mínima importância, não pense duas vezes,  quebre o padrão, mas somente faça isso quando não houver outra alternativa, esgotaram-se mesmo as possibilidades. É fácil seguir a semântica quando sua página é um “linguição fixo”, agora quando os elementos devem ser adequar ao perfil do usuário aí você se complica.

Podem me jogar pedras, mas por favor, o façam também contra o IE. Sempre crio o conteúdo utilizando como navegador o Firefox, e tudo que fiz sempre funcionou corretamente nele. Rezo para que um dia ele chegue à liderança e com grande margem, e somente nesse dia é que eu conseguirei convencer meu cliente a trocar de navegador, antes disso, nós é que temos que ser flexíveis.

Mas lembre-se um pequeno trecho sacrificado que no futuro pode ser corrigido com o uso de melhores navegadores é uma coisa, chutar toda a semântica é bem diferente, por favor nunca façam este último, sigam padrões, ou pelo menos 99,99% deles.