Carreira Dev

25 mar, 2014

5 mentalidades de “boas práticas” que você deve parar de ter

Publicidade

Todo desenvolvedor se esforça para escrever um código limpo, sustentável e funcional, seja para o lado do cliente ou do servidor. Durante essas poucas décadas de web, temos aprendido com alguns dos nossos primeiros erros e trabalhado de forma a sempre mudar as boas práticas. Essas boas práticas geralmente nos mantêm fora de perigos, mas algumas delas são levadas muito ao pé da letra, ao ponto de alguns desenvolvedores se tornarem rígidos demais e “aleijados” por elas. Verdade seja dita, esse tipo de boas práticas, quando são quebradas, não é por complacência, mas por necessidade.

Aqui está uma lista com 5 dessas boas práticas que não são tão realistas como pensamos.

“Não adicione Globals a windows

Quem trabalha com JavaScript realmente batalha para encapsular seus códigos, através da criação de classes, closures e módulos. Eu concordo que devemos evitar globals, mas às vezes você simplesmente tem que tê-los. Eu recomendo que você crie um objeto global com o nome do projeto (Dojo Toolkit é dojo, o do Groupon é objeto groupon) e marque as propriedades ali. Criar um exército de globals vai te dar problemas, mas colocar apenas alguns é ok, se não for possível evitar. Enquanto você conhecer o meio ambiente onde o código está rodando, você não vai ter problemas de nomenclaturas iguais.

Adicionar prototypes nativos é ruim

Os primeiros frameworks JavaScript, como Prototype e MooTools, ganharam popularidade porque empoderavam prototype objects nativos. Você não precisava mais escrever funções disponíveis globalmente para modificar instâncias de String, Number, Array, Object, Function etc. Era possível aplicar métodos no prototype para cada um de forma que toda instância, existente ou futura, tivesse tais métodos; um super boost de produtividade e eficiência de código. Então, depois de alguns conflitos de nomenclaturas devido a implementações de API para web e navegador, tanto padrões como proprietárias, os desenvolvedores tornaram isso uma prática, a ponto de que o mero pensamento de adicionar um método a um prototype nativo significava que você deveria deixar de ser um programador!

Muito de adicionar um global a window, adicionando métodos a um prototype object nativo, é feito bem corretamente. Nomeie o seu método corretamente (por exemplo, não usando um nome comum), e tudo ficará bem. Não estou dizendo para que você faça isso sempre, apenas que adicionar um método a um prototype não vai levar sua carreira para o buraco.

Nunca use nomes que possam ser rastreados

Rastreamento de usuários (ou user agente sniffing) tem um nome terrível porque originalmente era usado pra rastrear features, e sabemos como isso foi ruim. Acredite ou não, o sniffing ainda é muito usado por grandes sites para detectar acesso via dispositivo móvel e então encaminhar o usuário para a versão mobile do site. E isso é bem confiável e feito pelo bem do usuário. Já me perguntaram “e se o usuário fizer um spoof no navegador?”. Eu respondi que então “eles recebem qualquer visualização que vier, quem se importa? Eles fizeram isso de propósito e, se recebem um site disfuncional, é problema deles.”. Enquanto você oferecer o link para a versão desktop do site, tudo estará bem.

É ok carregar [Library JavaScript] do CDN porque o usuário provavelmente já o carregou

Isso realmente me chateia, especialmente depois que fui ao Brasil para promover o Firefox OS. Sim, carregar utilidades do CDN é rápido e, desde que haja pessoas suficientes usando o CDN, há uma boa chance de que o usuário tenha o código em cache, mas não é tão simples assim. Presumindo que um site tenha o jQuery em cache, por exemplo, é arriscado porque há inúmeras versões e sub-versões e sub-sub-versões sendo utilizadas. Se o usuário não tem um plano de dados ilimitado (o que não existe na maioria dos países), ele pagará um bom dinheiro para cada site que usa a biblioteza JavaScript ou que carrega grandes arquivos, com CDN ou não. Quando fui ao Brasil, eu teria que pagar 20 centavos apenas para o jQuery se acessasse um site usando isso. Para resumir: presumir que os usuários não vão pagar o pato por uma fonte hospedada em CDN é muito, muito ruim.

Perfeição no pixel em uma obrigação

Bons designers e desenvolvedores geralmente são perfeccionistas, é por isso que eles são bons. No entanto, somos pegos na “perfeição no pixel” quando vamos do design para uma página de trabalho – provavelmente porque essa perfeição é alcançável. O problema em focar nisso é que a obsessão leva a um grande consumo de tempo que deveria ser gasto em melhorar a experiência do usuário, mas que está sendo gasto em melhorar o nosso ego. Claro que outros designers e desenvolvedores acessarão o site e perceberão alguns problemas na largura ou altura, mas mais de 90% dos usuários vão preferir que realizar alguma atividade seja mais fácil, em vez de que as colunas tenham medidas exatas. Claro que não é para você criar sites com tantos pixels “off” que pareçam mais um campo minado, mas às vezes você precisa deixar para consertar um bug depois e continuar fazendo com que o site seja mais usável, acessível e divertido!

É importante não perder de vista o lado prático quando formos trabalhar as boas práticas. Podemos ser bastante severos com algumas boas práticas, mas o mais importante é criarmos site funcionais, usáveis. Nunca aceitar uma regra sem questionar sua validade e nunca ter medo de pisar fora das linhas dessas regras rígidas!

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://davidwalsh.name/get-over