---
title: Padrões Web em grandes empresas
authors: Diego Eis
type: post
date: 2006-08-10
url: /padroes-web-em-grandes-empresas/
tweetbackscheck:
  - 1356453937
shorturls:
  - 'a:3:{s:9:"permalink";s:55:"https://tableless.com.br/padroes-web-em-grandes-empresas";s:7:"tinyurl";s:26:"https://tinyurl.com/42kof48";s:4:"isgd";s:19:"https://is.gd/b4GqsR";}'
twittercomments:
  - 'a:0:{}'
dsq_thread_id: 503035824
categories:
  - Artigos
  - Geral
tags:
  - cotidiano
  - Técnicas e Práticas

---
Porque é tão dificil adotar Padrões Web em grandes empresas? E quando adotam, porque é sempre pela metade?
  
Parece um enigma indecifrável, até você conhecer o processo de trabalho de uma grande empresa.
  
Já recebi muitos emails acusando essas empresas de atrasarem a adoção dos Padrões. Dizendo que elas não estão interessadas em mudar de hábito, mudar de método e tudo mais&#8230; Eu acho totalmente o contrário.
  
Você acha que alguma empresa com o mínimo de bom senso, ignoraria alguma oportunidade de economizar dinheiro, de aumentar a produtividade e melhorar a qualidade de seus produtos? Eu acho que não.

O que acontece é algo um pouco mais complicado, entretanto fácil de entender. As duas opções a seguir são as mais prováveis, mas podem não as únicas:

  1. O método e o ambiente de trabalho é mostruosamente complicado e burocrático.
  2. A publicação de conteúdo não depende de profissionais de web.

### 1. Método e ambiente de trabalho

O método de trabalho das empresas grandes é na maioria das vezes muito mais complicado que qualquer empresa de menor porte.

A equipe de desenvolvedores muitas vezes é enorme, ajudando a dificultar a organização do fluxo. Não, ela não ficou enorme de um dia pro outro. Isso é coisa que acontece aos poucos, de acordo com as necessidades e dependendo de cada caso. O resultado final, na maioria das vezes, há uma equipe grande de desenvolvedores, apenas tentando resolver problemas do que fazendo algo realmente produtivo.

A estrutura do lugar também pode ser tão complicada quanto a equipe. Em muitos lugares é normal haver uma divisão de ambientes de trabalho: homologação, desenvolvimento, produção etc. Essa divisão é ótima, você consegue manter um certo controle, na teoria. Sempre há desenvolvedores &#8220;fora da lei&#8221;, que alteram seus arquivos ignorando solenemente o CVS.
  
Outro ponto é que algumas empresas dependem de colaboradores terceirizados. E se esses colaboradores não seguirem os Padrões? E se forem centenas de colaboradores? Cada um com métodos diferentes, pessoas diferentes, estruturas diferentes. Qual seria o processo para fazê-los migrar para os Padrões?

Métodos e ambientes de trabalho monstruosos e burocráticos.

### Publicação de conteúdo

Se o site produz muito conteúdo como artigos, notícias, redação e etc, normalmente estas coisas não são publicadas pelos desenvolvedores. Geralmente são feitos por jornalistas, redatores ou editores, pessoal que na esmagadora maioria das vezes desconhece os Padrões Web. Nem sabem o que é HTML e nem estão interessados em saber.
  
O sistema de publicação de conteúdo que usam, muitas vezes tem mal suporte aos Padrões. Usam tags fora de contexto e a estruturação/identação do código costuma ser feita porcamente. Juntando estes dois fatores, o resultado é um código fonte desorganizadíssimo. Uma verdadeira canja.

Pequenos fatores como este fazem parte do dia-a-dia do desenvolvimento web de varias empresas por aí. A coisa não é tão fácil quanto parece. Em algumas empresas, pode parecer até impossível. Por isso, pense bem antes de criticar qualquer trabalho feito por aí.

### Indo com calma

A adoção dos padrões muda muita coisa. Não é só o desenvolvedor aprender a fazer layouts sem tabela e com CSS que o problema está resolvido. Nada disso. Há toda uma curva de migração, que começa no desenvolvedor, passado para seu método de produção, afetando a relação que ele tem com outros profissionais que trabalham ao seu lado e assim uma aplicação efetiva e que dê resultados nos projetos posteriores.

Leva-se tempo para configurar e personlizar um sistema que gerencie conteúdo afim de melhorar a estrutura de código final. Os desenvolvedores devem analisar as possibilidades e indicar qual a melhor forma de fazer tudo isso. Para tanto eles precisam de tempo, livrar-se dos problemas. Coisa não muito fácil de fazer. Há toda uma estrutura que deve ser seguida e respeitada.