Este artigo contém conselhos para desenvolvedores web escrito por dois engenheiros, um recomendando ténicas e ferramentas, já o outro fornecendo sugestões na solução de alguns desafios enfrentados quando desenvolve para navegadores.
Rebbeca Murphey, engenheira de software da Bazaarvoice, escreveu no início deste ano o post "A Baseline for Front-End [JS] Developers: 2015" fornecendo dicas para os desenvolvedores JavaScript sobre quais ferramentas e abordagens utilizar no desenvolvimento client-side web. Resumidamente, ela citou os seguintes pontos:
Aprender ECMAScript 2015. Segundo Murphey, há vários materiais de estudos: Understanding ES6, ES6 Rocks, e BabelJS. Há também o livro, recém lançado, Exploring ES6 escrito por Axel Rauschmayer. Considerando que atualmente não é uma obrigação saber tudo sobre ECMAScript 2015, Murphey recomenda saber em detalhes como usar chamadas assíncronas, callbacks e promises.
Usar Módulos. Murphey acredita que não há nenhuma discussão de que módulos devem ser os building blocks de aplicações client-side. Recentemente, ela tem utilizado o webpack, mas espera pelo o dia em que todos utilizarão módulos padrão ECMAScript.
Testar o código. É importante adicionar testes ao código e escrever código testável. Murphey utiliza a ferramenta Mocha na maior parte das vezes por força do hábito embora ache o projeto Intern agradável. Sobre este tema, Murphey também recomenda o livro de Michael Feathers, Working Effectively with Legacy Code.
Automatizar o processo. Além de ter usado Grunt e Gulp no passado, Murphey também acabou usando Yeoman que é ótimo para iniciar projetos a partir do zero usando tecnologias desconhecidas pelo desenvolvedor, e para quando for desenvolver bibliotecas, mantendo assim um padrão no desenvolvimento de bibliotecas JavaScript. Ela também menciona a ferramenta Broccoli, que poderá substituir Grunt no futuro.
Escrever código de qualidade. Murphey recomenda a refatoração do código que violar o guia de estilo de um projeto bem documentado e sugere utilizar ferramentas linter como o JSCS e o ESLint.
Usar Git. Utilize Git com feature branches, com o intuito de desenvolver pequenas tarefas a partir do branch de desenvolvimento. Outra dica que Murphey recomenda, é o uso da técnica de rebase interativo. Murphey acredita que desenvolver código em pequenas unidades dificilmente vai causar conflitos. Além disso, ela também indica executar ações de pre-push e pre-commit usando o módulo ghooks, como por exemplo, realizar o lint antes de fazer push.
Gerar HTML no servidor. Por motivos de desempenho, Murphey recomenda para projetos maiores gerar o HTML no servidor. Gerar e armazenar como arquivos estáticos para que possa ser entregue rapidamente - e completar o processo de renderizar a página com templates client-side e adicionando eventos".
Aderir ao NodeJS. Murphey aconselha desenvolvedores web a possuir conhecimento sobre Node.js, saber pelo menos como inicializar um projeto Node, como configurar um servidor Express e como usar o módulo request para requisições de proxy.
Em seu post recente How to Become a Great Front-End Engineer, Philip Walton, Engenheiro de Software da Google, tem uma abordagem diferente: ele não aconselha ferramentas e frameworks, mas sim a lidar com alguns dos desafios encontrados nesta área. Ele considera que "o que separa as pessoas boas das realmente boas não é o que elas sabem; é como elas pensam". Seus conselhos são:
Descobrir o que está acontecendo. Escrever um código que funciona não é o bastante para Walton. Ele conheceu várias pessoas que utilizam CSS e JavaScript porque eles "encontraram algo que funciona e então apenas seguem em frente". Há momentos em que um pedaço de código funciona, mas o desenvolvedor não sabe o porquê. Walton recomenda ir mais fundo:
Tomar tempo para descobrir por que seus hacks funcionam pode parecer custoso demais, mas prometo que vai lhe poupar tempo no futuro. Ter uma compreensão mais completa do sistema em que você está trabalhando significará menos tentativa-e-erro no futuro.
Antecipar mudanças no navegador. Os desenvolvedores web devem vigiar constantemente mudanças do navegador que pode quebrar o código existente. A seguinte linha de código criou problemas em um framework JavaScript quando o Internet Explorer 10 saiu.
var isIE6 = !isIE7 // !isIE8 // !isIE9;
Ler as especificações. Ainda que ler especificações seja uma tarefa difícil, Walton salienta que é necessário quando os navegadores processam uma página diferente, como por exemplo:
Um exemplo disso é o tamanho mínimo padrão de itens flex. De acordo com especificação, o valor inicial min-width e min-height para itens flex é auto (ao invés de zero). Isso significa que por padrão, itens flex não devem encolher para ficarem menores que o tamanho mínimo do seu contéudo. Nos primeiros meses de 2015, o Firefox foi o único navegador a implementar isso corretamente.
Quando encontramos incompatibilidade entre os navegadores e notamos que o site renderiza corretamente no Chrome, no IE, no Opera e no Safari, mas parece diferente no Firefox, assumimos que o Firefox está renderizando errado. De fato, testemunhei isso acontecer diversas vezes. Muito dos problemas reportados no meu projeto Flexbugs foram devidos a essa incompatibilidade. As soluções alternativas propostas, se implementadas, teriam falhado quando o Chrome 44 saiu. Se fossem realizados os workarounds, ao invés de seguir a especificação, acabaria penalizando o funcionamento correto.
Avaliar código. De acordo com Walton, há muito para aprender com a leitura do código de outros desenvolvedores, abrir a mente para "novas maneiras para fazer as coisas". Isto também ajuda no trabalho em equipe. Na realidade, isso é necessário porque a "maioria do seu tempo como um engenheiro é gasto adicionando ou modificando uma base de código existente," não escrevendo código novo a partir do zero.
Trabalhe com pessoas inteligentes. Walton recomenda "fortemente" para trabalhar em equipe no começo da carreira profissional. Para poder aprender com pessoas mais experientes e ter seu código revisado. Se mais tarde se optar por uma carreira freelance, ele sugere contribuir para projetos de código aberto para obter os benefícios de trabalhar em equipe.
Reinventar a roda. Embora concorde que "reinventar a roda é ruim para os negócios", Walton acredita ser ótimo para aprendizagem. Nem sempre, mas em alguns casos, em vez de usar código de terceiros, ele recomenda escrever seu próprio código por que há muito para aprender no processo.
Escrever sobre as lições aprendidas. O último conselho de Walton é sobre algumas das lições aprendidas ao longo do caminho: "Em minha experiência, escrever, dar palestras e criar demonstrações foram as melhores maneiras de me forçar a compreender em detalhes um assunto. Mesmo que ninguém nunca leia o que você escreve, o processo vale muito a pena".