ti-enxame.com

Quais detalhes técnicos o programador de um aplicativo da web deve considerar antes de tornar o site público?

O que um programador que implementa os detalhes técnicos de um aplicativo da web deve considerar antes de tornar o site público? Se Jeff Atwood puder esquecer cookies HttpOnly , sitemaps , esolicitação entre sites falsificações todos no mesmo site, que coisa importante eu poderia estar esquecendo também?

Estou pensando sobre isso da perspectiva de um desenvolvedor da Web, para que outra pessoa esteja criando o design e o conteúdo reais do site. Portanto, embora a usabilidade e o conteúdo possam ser mais importantes que a plataforma, você, o programador, tem pouco a dizer sobre isso. O que você precisa se preocupar é que sua implementação da plataforma seja estável, tenha bom desempenho, seja segura e atenda a quaisquer outras metas de negócios (como não custar muito, demorar muito para criar e classificar tão bem quanto o Google como o suporte de conteúdo).

Pense nisso da perspectiva de um desenvolvedor que fez algum trabalho para aplicativos do tipo intranet em um ambiente bastante confiável e está prestes a ter sua primeira chance e lançar um site potencialmente popular para toda a grande e ruim rede mundial de computadores.

Além disso, estou procurando algo mais específico do que apenas uma resposta vaga de "padrões da web". Quero dizer, HTML, JavaScript e CSS sobre HTTP são praticamente um dado, especialmente quando eu já especifiquei que você é um desenvolvedor web profissional. Então, indo além disso, Quais padrões? Em que circunstâncias e por quê? Forneça um link para a especificação da norma.

2187
Joel Coehoorn

A idéia aqui é que a maioria de nós já saiba a maioria do que está nesta lista. Mas pode haver apenas um ou dois itens que você realmente não analisou antes, que não entende completamente, ou talvez nunca tenha ouvido falar.

Interface e experiência do usuário

  • Esteja ciente de que os navegadores implementam os padrões de maneira inconsistente e verifique se o site funciona razoavelmente bem em todos os principais navegadores. Em um teste mínimo com relação a um Gecko engine recente ( Firefox ), um mecanismo WebKit ( Safari e alguns navegadores móveis) , Chrome , seus navegadores IE suportados (aproveite as Imagens VPC de compatibilidade de aplicativos ) e Opera . Considere também como browsers processam seu site / em diferentes sistemas operacionais.
  • Considere como as pessoas podem usar o site que não seja dos principais navegadores: telefones celulares, leitores de tela e mecanismos de pesquisa, por exemplo. - Algumas informações de acessibilidade: WAI e Section508 , Desenvolvimento móvel: MobiForge .
  • Preparo: Como implantar atualizações sem afetar seus usuários. Tenha um ou mais ambientes de teste ou teste disponíveis para implementar alterações na arquitetura, no código ou no conteúdo abrangente e garantir que eles possam ser implantados de maneira controlada sem quebrar nada. Tenha uma maneira automatizada de implantar alterações aprovadas no site ativo. Isso é implementado de maneira mais eficaz em conjunto com o uso de um sistema de controle de versão (git, Subversion, etc.) e um mecanismo de compilação automatizado (Ant, NAnt, etc.).
  • Não exiba erros hostis diretamente para o usuário.
  • Não coloque os endereços de email dos usuários em texto sem formatação, pois eles receberão spam até a morte.
  • Adicione o atributo _rel="nofollow"_ aos links gerados pelo usuário para evitar spam .
  • Crie limites bem considerados no seu site - Isso também pertence a Segurança.
  • Aprenda a fazer aprimoramento progressivo .
  • Redirecione após um POST se esse POST foi bem-sucedido, para impedir que uma atualização seja enviada novamente.
  • Não se esqueça de levar em consideração a acessibilidade. É sempre uma boa ideia e, em determinadas circunstâncias, é um requisito legal . WAI-ARIA e WCAG 2 são bons recursos nessa área.
  • Leia Não me faça pensar .

Segurança

Desempenho

  • Implemente o cache, se necessário, entenda e use HTTP caching corretamente, bem como HTML5 Manifest .
  • Otimizar imagens - não use uma imagem de 20 KB para um fundo repetitivo.
  • Compactar conteúdo para velocidade, consulte brotli , gzip/deflate (deflate é melhor).
  • Combine/concatene várias folhas de estilo ou vários arquivos de script para reduzir o número de conexões do navegador e melhorar a capacidade do gzip para compactar duplicações entre arquivos.
  • Dê uma olhada no site Yahoo Exceptional Performance , muitas ótimas diretrizes, incluindo a melhoria do desempenho do front-end e sua YSlow ferramenta (requer Firefox, Safari, Chrome ou Opera). Além disso, velocidade da página do Google (use com extensão do navegador ) é outra ferramenta para criação de perfil de desempenho e otimiza suas imagens também.
  • Use CSS Image Sprites para imagens relacionadas pequenas, como barras de ferramentas (consulte o ponto "minimizar solicitações HTTP")
  • Use sprites de imagem SVG para pequenas imagens relacionadas, como barras de ferramentas. A coloração SVG é um pouco complicada. Você pode ler sobre isso aqui .
  • Sites ocupados devem considerar dividir componentes entre domínios . Especificamente...
  • O conteúdo estático (ou seja, imagens, CSS, JavaScript e, geralmente, o conteúdo que não precisa de acesso a cookies) deve ir em um domínio separado que não usa cookies, porque todos os cookies de um domínio e seus subdomínios são enviados com todas as solicitações para o domínio e seus subdomínios. Uma boa opção aqui é usar uma rede de entrega de conteúdo (CDN), mas considere o caso em que essa CDN pode falhar incluindo CDNs alternativas ou cópias locais que podem ser veiculadas.
  • Minimize o número total de solicitações HTTP necessárias para um navegador renderizar a página.
  • Escolha um template engine e renderize/pré-compile usando os executores de tarefas como gulp ou grunt
  • Verifique se há um arquivo _favicon.ico_ na raiz do site, ou seja, _/favicon.ico_. Os navegadores solicitarão automaticamente , mesmo que o ícone não seja mencionado no HTML. Se você não tiver um _/favicon.ico_, isso resultará em muitos 404s, consumindo a largura de banda do servidor.

SEO (Otimização de mecanismos de pesquisa)

  • Use URLs "compatíveis com o mecanismo de pesquisa", ou seja, use _example.com/pages/45-article-title_ em vez de _example.com/index.php?page=45_
  • Ao usar _#_ para conteúdo dinâmico, altere _#_ para _#!_ e, em seguida, no servidor _$_REQUEST["_escaped_fragment_"]_, é o que o googlebot usa em vez de _#!_. Em outras palavras, _./#!page=1_ se torna _./?_escaped_fragments_=page=1_. Além disso, para usuários que possam estar usando o FF.b4 ou o Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1"); é um ótimo comando. Portanto, mesmo que a barra de endereço tenha mudado, a página não é recarregada. Isso permite que você use _?_ em vez de _#!_ para manter o conteúdo dinâmico e também informar ao servidor quando você enviar por e-mail o link que estamos após esta página, e o AJAX não precisa para fazer outro pedido extra.
  • Não use links que digam "clique aqui" . Você está desperdiçando uma oportunidade de SEO e isso torna as coisas mais difíceis para as pessoas com leitores de tela.
  • Tenha um XML sitemap , de preferência no local padrão _/sitemap.xml_.
  • Use _<link rel="canonical" ... />_ quando você tiver vários URLs que apontam para o mesmo conteúdo, esse problema também pode ser solucionado em Ferramentas do Google para webmasters .
  • Use Ferramentas para webmasters do Google e Ferramentas para webmasters do Bing .
  • Instale Google Analytics logo no início (ou uma ferramenta de análise de código aberto como Piwik /).
  • Saiba como robots.txt e as aranhas dos mecanismos de pesquisa funcionam.
  • Redirecione solicitações (usando _301 Moved Permanently_) solicitando _www.example.com_ para _example.com_ (ou o contrário) para impedir a divisão da classificação do Google entre os dois sites.
  • Saiba que pode haver aranhas mal comportadas por aí.
  • Se você tiver conteúdo não textual, procure as extensões de mapa do site do Google para vídeos, etc. Há algumas informações boas sobre isso em Tim Farley's answer .

Tecnologia

  • Entenda HTTP e coisas como GET, POST, sessões, cookies e o que significa ser "sem estado".
  • Escreva seu XHTML / HTML e CSS de acordo com as especificações W3C e certifique-se de que eles validam /. O objetivo aqui é evitar os modos peculiares do navegador e, como bônus, facilitar o trabalho com navegadores não tradicionais, como leitores de tela e dispositivos móveis.
  • Entenda como o JavaScript é processado no navegador.
  • Entenda como o JavaScript, as folhas de estilo e outros recursos usados ​​por sua página são carregados e considere seu impacto no desempenho percebido . Agora, é amplamente considerado adequado mover scripts para o final das páginas das suas páginas, com exceções que normalmente são coisas como aplicativos de análise ou shims HTML5.
  • Entenda como a sandbox JavaScript funciona, especialmente se você pretende usar iframes.
  • Esteja ciente de que o JavaScript pode e será desativado e que AJAX é, portanto, uma extensão, não uma linha de base. Mesmo que a maioria dos usuários o deixe ligado agora, lembre-se de que NoScript está se tornando mais popular. Embora os robôs de rastreamento modernos suportem a indexação de conteúdo gerado por JavaScript, considere usar a renderização no servidor para outros robôs ou usuários que desativaram o JavaScript.
  • Aprenda a diferença entre os redirecionamentos 301 e 302 (esse também é um problema de SEO).
  • Aprenda o máximo possível sobre sua plataforma de implantação.
  • Considere usar uma Redefinir folha de estilos ou normalize.css .
  • Considere estruturas JavaScript (como jQuery , MooTools , Prototype , Dojo ou YUI 3 ), que ocultará muitas diferenças do navegador ao usar JavaScript para manipulação de DOM.
  • Reunindo o desempenho percebido e as estruturas JS, considere usar um serviço como a API das Bibliotecas do Google para carregar estruturas para que um navegador possa usar uma cópia da estrutura que ele já armazenou em cache, em vez de fazer o download de uma cópia duplicada. copiar do seu site.
  • Não reinvente a roda. Antes de fazer QUALQUER COISA, procure um componente ou exemplo de como fazê-lo. Há 99% de chance de alguém ter feito isso e lançado uma versão OSS do código.
  • Por outro lado, não comece com 20 bibliotecas antes mesmo de decidir quais são suas necessidades. Particularmente na Web do lado do cliente, onde quase sempre é mais importante manter as coisas leves, rápidas e flexíveis.

Correção de erros

  • Entenda que você gastará 20% do seu tempo codificando e 80% dele mantendo, portanto, codifique de acordo.
  • Configure uma boa solução de relatório de erros.
  • Tenha um sistema para as pessoas entrarem em contato com você com sugestões e críticas.
  • Documente como o aplicativo funciona para futuras equipes de suporte e pessoas que realizam manutenção.
  • Faça backups frequentes! (E verifique se esses backups estão funcionando) Tenha uma estratégia de restauração, não apenas uma estratégia de backup.
  • Use um sistema de controle de versão para armazenar seus arquivos, como Subversion , Mercurial ou Git .
  • Não se esqueça de fazer seu teste de aceitação. Estruturas como Selenium podem ajudar. Especialmente se você automatizar completamente seus testes, talvez usando uma ferramenta de Integração Contínua, como Jenkins .
  • Verifique se você possui log suficiente usando estruturas como log4j , log4net ou log4r . Se algo der errado no seu site ao vivo, você precisará descobrir como.
  • Ao fazer o log, certifique-se de capturar as exceções tratadas e não tratadas. Relate/analise a saída do log, pois mostrará onde estão os principais problemas em seu site.

Outros

  • Implemente monitoramento e análise do lado do servidor e do cliente (um deve ser proativo em vez de reativo).
  • Use serviços como UserVoice e Intercom (ou qualquer outra ferramenta similar) para manter contato constante com seus usuários.
  • Siga Vincent Driessen 's Git branching model

Muitas coisas foram omitidas não necessariamente porque não são respostas úteis, mas porque são muito detalhadas, estão fora do escopo ou vão um pouco longe demais para alguém que deseja obter uma visão geral do que deve saber. Sinta-se à vontade para editar isso também, provavelmente perdi algumas coisas ou cometi alguns erros.

2655
victoriah