Capítulo

Refatoração 1

Refatoração. O que é? Por que fazê-la?

De forma resumida, refatoração é a melhoria gradual de uma base
de código por meio de pequenas mudanças que não modificam o com-
portamento de um programa, normalmente com a ajuda de algum tipo
de ferramenta automatizada. O objetivo da refatoração é remover os pro-
blemas acumulados em anos de código legado e produzir código mais
claro que seja mais fácil de manter, mais fácil de depurar e mais fácil de
adicionar funcionalidades.
Tecnicamente, a refatoração nunca corrige um erro ou adiciona uma
funcionalidade. Entretanto, na prática, ao refatorar eu quase sempre des-
cubro erros que precisam ser corrigidos e identifico oportunidades para
novas funcionalidades. Frequentemente, a refatoração faz com que pro-
blemas antes difíceis tornem-se problemas tratáveis ou até mesmo fáceis.
Reorganizar código é o primeiro passo para melhorá-lo.
Se você é do tipo que inicia um novo semestre, projeto ou trabalho
arrumando cuidadosamente seu espaço de trabalho, mesa ou escritório,
você entenderá imediatamente. A refatoração ajuda você a evitar que o
que já existe atrapalhe o que está chegando. Ela não deixa você iniciar
a partir de uma página em branco. Em vez disso, ela deixa você em um
espaço de trabalho limpo e organizado no qual você pode encontrar tudo
o que precisa e a partir do qual pode avançar.
O conceito de refatoração originalmente vem da comunidade de pro-
gramação orientada a objetos e data, pelo menos, dos anos 90 (William
F. Opdyke e Ralph Johnson, “Refactoring: An Aid in Designing Applica-
tion Frameworks and Evolving Object-Oriented Systems”, Anais do Sim-
pósio em Programação Orientada a Objetos com Ênfase em Aplicações
Práticas [SOOPPA], setembro de 1990, ACM), apesar de ser provável
24 Refatorando HTML

que técnicas de refatoração já estivessem sendo usadas, ao menos de ma-

neira limitada. Entretanto, o termo foi popularizado por Martin Fowler
*
em 1999 em seu livro Refactoring (Addison-Wesley, 1999) . Desde en-
tão, numerosas IDEs e outras ferramentas, tais como Eclipse, IDEA da
IntelliJ e C# Refactory, têm implementado muitos de seus catálogos de
refatoração para linguagens tais como Java e C#, bem como têm inven-
tado muitas refatorações.
Entretanto, não é só código orientado a objetos e linguagens orientadas
a objetos que podem produzir código ruim e que precisam de refatoração.
Na verdade, não são só as linguagens de programação. Quase todos os sis-
temas suficientemente complexos desenvolvidos e mantidos ao longo do
tempo podem se beneficiar de refatoração. As razões são as seguintes:
1. Um conhecimento maior tanto sobre o sistema quanto sobre o domí-
nio do problema frequentemente revela detalhes que não eram apa-
rentes para os projetistas iniciais. Ninguém acerta tudo na primeira
versão. Você precisa ver o sistema em produção por um tempo, an-
tes que alguns dos problemas se tornem aparentes.
2. Ao longo do tempo, a funcionalidade aumenta e um novo código
é escrito para atender a esse aumento. Mesmo se o sistema origi-
nal resolvesse o problema perfeitamente, o novo código escrito para
atender às novas funcionalidades não casa perfeitamente com o có-
digo antigo. Por fim você pode chegar a um ponto no qual a base
de código antigo não consegue suportar o peso de todas as novas
funcionalidades que você quer adicionar.
Ao deparar-se com um sistema que não é capaz de suportar caracte-
rísticas adicionais, você tem duas escolhas: pode jogá-lo fora e construir
um novo sistema do zero, ou pode reforçar as fundações do sistema. Na
prática, raramente temos tempo ou orçamento para criar um sistema com-
pletamente novo apenas para substituir algo que já funciona. É muito mais
vantajoso em termos de custos adicionar o suporte necessário que o sis-
tema precisa antes que novas funcionalidades possam ser adicionadas. Se
pudermos inserir esse suporte de maneira gradual, um pouco de cada vez,
em vez de uma grande integração, melhor.
Muitos sistemas complexos com grandes quantidades de código não são
escritos em linguagens orientadas a objetos e talvez nem mesmo em lin-
guagens de programação. Por exemplo, Scott Ambler e Pramod Sadalage
demonstraram como refatorar bases de dados SQL que dão suporte a muitas
aplicações grandes em Refactoring Databases (Addison-Wesley, 2006).

* N. de R. T.: Publicado no Brasil sob o título Refatoração, pela Bookman Editora.

 Capítulo 1 Refatoração 25

Entretanto, enquanto o lado servidor de uma grande aplicação distribuída

muitas vezes funciona sobre uma base de dados relacional, o lado cliente é um
*
site web. Interfaces gráficas baseadas em clientes leves (thin client ) que ro-
dam no Firefox ou no Internet Explorer em todos os lugares estão rapidamente
substituindo as basedas em clientes pesados (thick client ou fat client) para
todos os tipos de aplicações de negócios, tais como folhas de pagamento e sis-
temas de rastreamento. Usuários mais ousados em empresas como a Sun e a
Google estão indo um passo além e substituindo aplicações desktop tais como
processadores de texto e planilhas eletrônicas por aplicações web construídas
em HTML, CSS e JavaScript. Por fim, a Web e a onipresença dos navegadores
web têm permitido tipos completamente novos de aplicações que não existiam
antes, tais como eBay, Netflix, PayPal, Google Reader e Google Maps.
O HTML tornou essas aplicações possíveis e tornou-as mais rápidas de
serem desenvolvidas, mas não as tornou mais fáceis. Não as deixou simples.
E certamente não as deixou menos fundamentalmente complexas. Alguns
desses sistemas estão em sua segunda, terceira ou quarta gerações e – quer
saber? – tal como qualquer outra aplicação complexa, e de vida suficiente-
mente longa, estas aplicações web estão acumulando problemas de código.
As novas peças não estão mais casando perfeitamente com as mais antigas.
Os sistemas estão se tornando mais lentos porque toda a estrutura é muito
difícil de manipular. A segurança está sendo comprometida quando hackers
deslizam por entre as brechas criadas pela união entre as novas partes e as
partes mais antigas. Mais uma vez, a escolha aparece como sendo de duas
mãos: jogar a antiga aplicação fora e iniciar novamente, ou corrigir a base
destas aplicações; mas realmente não existe escolha. No mundo acelerado em
que vivemos hoje, ninguém pode pagar o preço de esperar por um substituto
completamente novo. A única opção realista é refatorar.

POR QUE REFATORAR?

Como você sabe que é hora de refatorar? Quais são os problemas de código
**
e sintomas que fazem com que você fique atento? Existem alguns poucos
sintomas, mas estes estão entre os piores.

Problema: código ilegível

O sintoma mais óbvio é quando você escolhe a opção Exibir Código Fonte
em uma página, e parece que ela foi escrita em Grego (a menos, é cla-

* N. de R. T.: Utiliza-se também a tradução cliente “magro”.

** N. de R. T.: Na literatura e na comunidade de programação orientada a objetos, o termo usado para um
problema ou sintoma é bad smell (mau cheiro).
26 Refatorando HTML

ro, que você esteja trabalhando na Grécia). A maioria dos programadores

reconhece código ruim quando o veem. Código ruim parece ruim. Qual
você prefere ver, a Listagem 1.1 ou a Listagem 1.2? Eu não acho que eu
tenha que dizer a você qual delas é pior, e qual vai ser mais fácil de manter
e atualizar.

Listagem 1.1 Código ruim, desorganizado

<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" WIDTH="100%">
<TR><TD WIDTH="70"> <A HREF="http://www.example.com/" TARGET=
"_blank"
>
<IMG SRC="/images/logo-footer.gif"
HSPACE = 5 VSPACE="0" BORDER="0"></A></TD>
<td class="footer" VALIGN="top"> &#169;2007 <A HREF="http://
www.example.com/" TARGET="_blank">Example Inc.</A>.
All rights reserved.<br>
<A HREF="http://www.example.com/legal/index.html"
TARGET="_blank">Legal Notice</A> -
<A HREF="http://www.example.com/legal/privacy.htm"
TARGET="_blank">Privacy Policy</A> - <A HREF="http://www.example.com/
legal/permissions.html"
TARGET="_blank">

Permissions</A>
</td>
</TR></TABLE>

Listagem 1.2 Código mais claro

<div id='footer'>
<a href="http://www.example.com/">
<img src="/images/logo-footer.gif" alt="Example Inc."
width='70' height='41' />
</a>
<ul>
<li>© 2007 <a href="http://www.example.com/">Example Inc.</a>.
All rights reserved.</li>
<li><a href="http://www.example.com/legal/index.html">
Legal Notice
</a></li>
<li><a href="http://www.example.com/legal/privacy.htm">
Privacy Policy
</a></li>
<li><a href="http://www.example.com/legal/permissions.html">
Permissions
</a></li>
</ul>
</div>

Agora, você pode argumentar que na Listagem 1.2 eu não apenas re-
formatei o código. Eu também o modifiquei. Por exemplo, uma tabela
 Capítulo 1 Refatoração 27

tornou-se uma div e uma lista, e alguns hífens foram removidos. Entre-
tanto, a Listagem 1.2 é na verdade muito mais próxima do significado do
conteúdo que a Listagem 1.1. Presume-se aqui que a Listagem 1.2 utiliza
uma folha de estilo CSS externa para fornecer todos os detalhes de forma-
tação que removi da Listagem 1.1. Conforme você verá, essa será uma das
técnicas principais que você usará para refatorar suas páginas e limpar o
código dos documentos.
Eu também joguei fora os atributos TARGET="_blank" que abrem links
em uma nova janela ou aba. Normalmente o usuário não deseja isso, e
raramente é uma boa ideia. Deixe o usuário usar o botão voltar e a lista
de histórico se for necessário, e, caso contrário, deixe ele abrir a maioria
dos links na mesma janela. Se os usuários quiserem abrir um link em uma
nova janela, eles podem fazer isso facilmente pelo menu de contexto, mas
a escolha agora é deles. Algumas vezes metade do processo de organiza-
ção e limpeza consiste em nada mais nada menos que remover trechos que
não deveriam estar lá em primeiro lugar.

Tamanho da linha
A Listagem 1.2 é ainda um pouco pior que o ideal. Estou um pouco
restrito pela necessidade de encaixar o código dentro das margens
desta página impressa. Em código fonte real, eu poderia fazer com
que um pouco mais de código fosse colocado em cada linha. En-
tretanto, não levo isso a extremos. Mais que 80 caracteres por linha
pode fazer com que o código fique difícil de ler e isso por si só,
pode se tornar um problema.

Uma pequena exceção pode ser feita aqui para código gerado por
um sistema de gerenciamento de conteúdo (CMS) de algum tipo. Neste
caso, o código que você vê em Exibir Código Fonte não é, na verdade, o
código fonte. Ele é mais próximo de um formato de máquina compila-
do. Neste caso, é a entrada para o CMS que deve parecer boa e aparecer
de forma legível.
Independentemente disso, é ainda melhor se ferramentas como CMSs
e editores web gerem código claro e bem formado. Surpreendentemente,
você descobrirá que muitas vezes o código que as ferramentas geram é um
início, não um fim. Você pode querer adicionar folhas de estilo, scripts, e
outras coisas no código depois de a ferramenta gerá-lo. Nesse caso, você
terá de lidar com a marcação pura, e isto é bem mais fácil de ser feito
quando o código é claro e limpo.
28 Refatorando HTML

Problema: o diretor não consegue preencher

seus próprios formulários de despesas
A usabilidade na Web tem melhorado nos últimos anos, mas não tanto
quanto poderia ou deveria. Todos, exceto os melhores sites, podem se
beneficiar de um foco maior no usuário e menos nos desenvolvedores
e designers de sites. Algumas poucas mudanças focadas em melhorar
a usabilidade – tal como aumentar o tamanho da fonte (ou não especi-
ficá-lo) ou combinar campos de um formulário – podem ter retornos
amplamente desproporcionais em produtividade. Isso é especialmente
importante para sites da intranet, e qualquer site que esteja tentando
vender algo para seus clientes.

Problema: lentidão no carregamento de páginas

Se qualquer um dos principais navegadores levar mais que meio segundo
para mostrar uma página, você tem um problema. Isso pode ser difícil
de julgar, dado que muitas páginas lentas são causadas pela latência da
rede, por bases de dados e servidores HTTP sobrecarregados. Esses são
problemas também, apesar de você normalmente não poder corrigi-los
modificando o HTML. Entretanto, se uma página salva em um sistema de
arquivos local leva mais que meio segundo para ser desenhada no navega-
dor, você precisa refatorá-la para melhorar este tempo.

Problema: páginas aparecem de maneira

diferente em navegadores diferentes
As páginas não precisam ser mostradas de maneira idêntica em diferentes
navegadores. Entretanto, todo conteúdo e funcionalidade devem ser aces-
síveis para todos que usam um navegador atual razoavelmente conhecido.
Se a página é ilegível ou não funcional no Safari, Opera, Internet Explorer
ou Firefox, você tem um problema. Por exemplo, você pode ver a página
com uma barra lateral da largura de toda a página, seguida pelo painel de
conteúdo. Alternativamente, a barra lateral pode ser mostrada abaixo do
conteúdo ao invés de por cima dele. Isso normalmente significa que a pá-
gina aparece perfeitamente bem no navegador do autor. Entretanto, ele não
se deu ao trabalho de verificá-la no navegador que você está usando. Certi-
fique-se de verificar suas páginas em todos os principais navegadores.
Sempre que você vir algo como “Melhor visualizado no Internet Ex-
plorer” você tem um problema de código e precisa de refatoração. Sem-
pre que vir algo como o mostrado na Figura 1.1, você tem um imenso
problema de código – e um problema com o qual todos os seus leitores
 Capítulo 1 Refatoração 29

FIGURA 1.1 O site do Wal-Mart bloqueia usuários não-IE.

podem sofrer também. O Internet Explorer detém menos de 80% do

mercado de navegadores, e isto está caindo rapidamente. Na verdade,
provavelmente esse valor é bastante superestimado dado que a maioria
dos web spiders e bots identificam-se falsamente como IE, e eles con-
tam por um número de acessos desproporcional. Usuários do Mac OS X
e do Linux nem mesmo tem a opção de escolher pelo Internet Explorer.
Os dias nos quais você podia projetar seu site para apenas um navegador
terminaram.
Uma variante comum disso é precisar de um tamanho de tela em
particular – por exemplo, “Esta página é melhor visualizada com uma re-
solução de 1024 x 768. Para trocar a resolução de seu monitor, vá em...”.
Páginas web bem projetadas não necessitam de nenhum navegador ou
tamanho de tela específico.

Problema: as páginas requerem tecnologias

perigosas ou não padronizadas
Muitos sites requerem cookies, JavaScript, Flash, PDF, Java, ou outras
tecnologias não HTML. Apesar de todas essas tecnologias terem o seu
lugar, elas são utilizadas em demasia na Web. Elas não são nem de perto
tão inter operáveis ou confiáveis no mundo real como a maioria dos web
designers pensam. Elas são assunto de notas frequentes sobre falhas de
seguranças que dizem para que os usuários as desabilitem em um nave-
gador ou outro para evitar o crack da semana. Elas são frequentemente
30 Refatorando HTML

não suportadas pelo Google e pela maioria dos robôs das outras máqui-
nas de busca. Consequentemente, você deve se certificar que a maioria
das páginas de seu site funciona de maneira apropriada, mesmo se essas
tecnologias não estiverem disponíveis.
Felizmente, os problemas de código aqui são muito óbvios e muito
fáceis de detectar. Toda vez que você vir uma nota tal como a nota a seguir,
você tem um problema:
Cookies requeridos
Desculpe, você deve aceitar cookies para acessar este
site.
Para continuar neste site, você deve habilitar cookies
em seu navegador Internet. Usamos cookies para adaptar
nosso site para as suas necessidades, para entregar um
serviço melhor, mais personalizado e para lembrar cer-
tas escolhas que você fez, de modo que não precise in-
formá-las novamente.

Além de tal situação incomodar os usuários, faz com que tais sites sejam
rotineiramente excluídos pelo Google, acarretando um posicionamento
ruim nas buscas.
De maneira embaraçosa, o seguinte exemplo vem de uma página que
fala sobre melhorar código HTML:
Nota: Existe um Sumário, mas ele é gerado dinamicamente.
Por favor, habilite JavaScript para vê-lo.

A maneira correta de gerar conteúdo dinâmico é usar templates no

servidor, mas mandar conteúdo HTML estático para o cliente.
Em um site, consegui esbarrar em quase todos estes:
Este site usa JavaScript, Cookies, Flash, janelas pop-
up, e é projetado para ser utilizado com as últimas ver-
sões do Internet Explorer, Netscape Navigator (NOT Nets-
cape 6) e Opera.

Se eles tivessem pedido um tamanho de tela específico, eles teriam atingi-

do a perfeição.
Este site também adicionou um novo incômodo. Eu havia esquecido
das janelas pop-up. Dado o crescente e descontrolado abuso das janelas
pop-up e a consequente instalação de bloqueadores de pop-ups, nenhum
site legítimo baseia-se nelas.
 Capítulo 1 Refatoração 31

É claro, há algumas coisas que você só pode fazer com JavaScript ou

outras tecnologias não HTML. Eu não pretendo dizer a você que não pro-
jete o próximo Google Maps ou YouTube, se na verdade for isso o que
você está tentando fazer. Apenas tente manter os truques decorativos a um
mínimo, e certifique-se de que tudo o que você pode fazer sem Java/JavaS-
cript/Flash/e assim por diante seja feito sem essas tecnologias. A mensa-
gem do Flickr é muito menos problemática:
Para obter as vantagens completas de usar o Flickr, você
deve usar um navegador com JavaScript habilitado e ins-
talar a última versão do Macromedia Flash Player.

A diferença chave é que eu vejo isso em uma página que ainda assim
consegue mostrar o conteúdo, apesar de estar com JavaScript e Flash de-
sabilitados. Eu posso não ver tudo, ou não ter a funcionalidade completa,
mas não sou bloqueado. Isso é muito mais amigável para os usuários e
para máquinas de busca tal como o Google.
Como um desenvolvedor de sites, eu ainda dou uma segunda olhada
nesta página para ver se eu seria capaz de remover alguns dos requisitos
dos clientes. Entretanto, não seria minha primeira prioridade.

Problema: a página principal de sua empresa

repentinamente diz: “Pwned by elite doodz”
A desfiguração de sites web é um forte aviso, do tipo que chama a atenção
de todos imediatamente. Isso pode acontecer por diversas razões, mas de
longe a mais comum é um ataque de injeção de código direcionado a um
script de processamento de formulários projetado pobremente.
Francamente, se tudo o que ocorrer for a desfiguração de seu site web,
você está com sorte e deveria agradecer aos hackers que mostraram isso
a você. Ataques mais sérios podem roubar dados confidenciais ou apagar
informações cruciais.

Problema: sua primeira aparição no Google é na página 17

Otimização para máquinas de busca é um grande fator de motivação para
a refatoração de sites web. As máquinas de busca valorizam mais os textos
do que as imagens, e textos que aparecem mais cedo na página do que os
que aparecem mais tarde. Elas não entendem layouts baseados em tabelas,
e elas não se importam muito com cookies ou JavaScript. Entretanto, elas
amam títulos únicos e talvez até tags com metainformações.
32 Refatorando HTML

Problema: os leitores mandam email

dizendo que seu site não funciona
Esta é absolutamente uma das melhores maneiras de descobrir que você
tem um problema. Por exemplo, eu recentemente recebi este email de um
de meus leitores:
Os links na seção “Leitura Adicional” do Café au Lait
para “A Próxima Grande Linguagem” e “Testando HopStop”
estão quebrados.
Atenciosamente,
Kent

Isso foi um pouco surpreendente dado que a seção que Kent estava recla-
mando era automaticamente gerada usando XSLT que transformava um
feed Atom de outro site. Eu verifiquei o feed e ele estava correto. Entre-
tanto, Kent estava correto e o link estava quebrado. Finalmente rastreei
o problema na folha de estilo XSLT. Ela estava lendo um elemento que
normalmente, mas nem sempre, era igual ao link, em vez do elemento que
era de fato o link. Cinco minutos depois, o site estava corrigido.
Noventa e nove por cento de seus leitores irá apenas resmungar e nun-
ca dirão a você que seu site está com problemas. Os leitores que somam
1% e que reclamam valem ouro. Você precisa tratá-los bem e escutar o que
têm a dizer. Não faça com que seja difícil que eles o encontrem. Todo o
site e praticamente toda a página deve ter uma pessoa óbvia para contato
para qualquer problema que ocorra. Esses retornos devem ser cuidadosa-
mente considerados e você deve agir rápido.
Os leitores também podem mandar a você emails sobre coisas não rela-
cionadas ao site: pedidos cancelados, datas de envio, requisições de links,
discordâncias políticas, e milhares de outras coisas. Você precisa ser capaz
de separar os problemas técnicos dos problemas não técnicos de forma que
a correspondência possa ser roteada apropriadamente. Alguns sites usam
um formulário e pedem que os leitores classifiquem o problema. Entretanto,
isso não é confiável, dado que os leitores normalmente não pensam sobre o
site da mesma maneira que os desenvolvedores. Por exemplo, se um cliente
não consegue informar um CEP com um hífen em seu formulário de ende-
reço de entrega, você pode pensar nisso como sendo um problema técnico
(e você estaria certo), mas o cliente provavelmente o classificaria como sen-
do um problema de envio e o direcionaria para um departamento que nem
mesmo entenderia a pergunta, quanto mais saberia o que fazer. Talvez você
tenha que treinar uma pessoa ou equipe que identifique cada email e decida
quem é a pessoa correta para respondê-lo. Essa é uma função crítica que
não deve ser terceirizada pelo menor preço.
 Capítulo 1 Refatoração 33

Independentemente do que fizer, não deixe que os relatos de erros caiam

no buraco negro do serviço de atendimento ao consumidor. Certifique-se de
que as pessoas que têm o poder de corrigir os problemas recebam o feedback
diretamente dos usuários do site, e que elas prestem atenção a eles. Muitos
sites usam formulários de contato e emails para evitar que os usuários os con-
tatem, bloqueando assim os desenvolvedores dos usuários do site. Não caia
nessa armadilha. Os sites web pagam um monte de dinheiro para contratar
equipes responsáveis pelo controle de qualidade. Se as pessoas são voluntá-
rias para fazer isso para você, ame-as por isso e tire vantagem delas.

QUANDO REFATORAR
Quando você deve refatorar? Quando você diz que é hora de colocar em
espera a adição de novas funcionalidades para que você possa melhorar e
organizar seu código legado? Existem diversas respostas possíveis para
essa questão, e elas não são mutuamente excludentes.
A primeira vez que você deve refatorar é antes de qualquer redese-
nho. Se o seu site estiver passando por um grande redesenvolvimento,
a primeira coisa que você precisa fazer é controlar seu conteúdo. O pri-
meiro benefício de refatorar a esta altura é simplesmente o fato de que
você criará uma base muito mais estável sobre a qual irá implementar o
novo design. Uma página bem formada, bem organizada é muito mais
fácil de ser reformatada.
A segunda razão para refatorar antes de redesenhar é que o processo
de refatoração ajudará a familiarizar os desenvolvedores com o site. Você
verá onde as páginas estão, como elas se encaixam umas nas outras na hie-
rarquia do site, quais elementos são comuns entre as páginas, e assim por
diante. Você também provavelmente descobrirá novas ideias para o rede-
senho. Não as implemente ainda, mas anote-as (melhor ainda, atribua-as
*
para o aplicativo de acompanhamento de pendências ) de forma que pos-
sa implementá-las posteriormente, após a refatoração. Refatoração é uma
ferramenta muito importante para melhorar a velocidade com a qual os
desenvolvedores constroem um site. Se é um site no qual os desenvolve-
dores nunca trabalharam, a refatoração irá ajudá-los a aprender sobre ele.
Se é um site no qual eles já trabalham nos últimos dez anos, a refatoração
irá lembrá-los de coisas que esqueceram. Em ambos os casos, a refatora-
ção ajuda a fazer com que os desenvolvedores sintam-se mais confortáveis
com o site.

* N. de R. T.: O termo em inglês é issue tracker.

34 Refatorando HTML

Talvez as novas funções estejam em páginas completamente novas,

talvez até mesmo em um site completamente novo. Se ainda existe algu-
ma conexão com o site antigo, você vai querer analisá-lo de forma a ver
o que você pode reutilizar ou pegar emprestado. Estilos, gráficos, scripts
e templates podem ser candidatos para o reuso. Na verdade, fazer isso
ajuda você a manter uma experiência consistente entre as partes antigas
e as partes novas do site. Entretanto, se as partes antigas que você quer
reutilizar têm algum problema, você precisará organizá-las e melhorá-las
primeiro. Por razões similares, você deve considerar refatorar antes de
construir algum novo grande projeto sobre um antigo. Por exemplo, se
você implementará compras com um único clique, certifique-se que o
antigo carrinho de compras ainda faça sentido. Se o departamento jurídi-
co está solicitando a inserção de um pequeno impresso no final de cada
página, descubra se cada uma delas tem um rodapé consistente no qual
você possa inserir esse impresso facilmente. Você não precisa refatorar
tudo, mas faça as mudanças que irão ajudar a integrar mais facilmente o
novo conteúdo em seu site.
Finalmente, você pode querer considerar uma refatoração semicontí-
nua. Se você encontrar um problema que o está incomodando, não espere
por um bloco ininterrupto de duas semanas no qual você poderá refatorar
tudo. Descubra o que você pode fazer para corrigir o problema imediata-
mente, mesmo se não corrigir todo o resto. Na medida do possível, tente
usar práticas de desenvolvimento ágil. Codifique um pouco, teste um
pouco, refatore um pouco. Repita. Apesar de muitos projetos serem ini-
ciados a partir de uma grande base de código legado ruim, se você tiver a
oportunidade de iniciar um projeto do zero tente não fazer com que ele se
torne uma grande base de código ruim logo de início. Quando você notar
que está repetindo o mesmo código, extraia-o para templates ou folhas
de estilo externas. Quando você notar que um de seus desenvolvedores
HTML contratados está inserindo elementos que são desencorajados,
substitua-os por CSS (e aproveite a oportunidade para educá-lo sobre o
porquê da substituição). Uma lista de muitas mudanças pequenas, mas
significativas, podem ter um grande efeito ao longo do tempo.
Independentemente do que fizer, não deixe a perfeição ser a inimiga
do bem. Se você tem tempo apenas para fazer uma pequena refatoração
necessária, faça-a. Você sempre pode fazer mais posteriormente. Gran-
des redesenhos ostentam e impressionam, mas não são tão importantes
quanto as pequenas melhorias graduais feitas ao longo do tempo. Faça
com que seu objetivo seja deixar o código em melhor forma no final do
dia do que no início dele. Faça isso em um período de meses, e mais
cedo que o esperado, você terá uma base de código clara que terá orgu-
lho de mostrar.
 Capítulo 1 Refatoração 35

REFATORAR PARA O QUÊ?

Existe uma diferença crítica entre refatorar em uma linguagem de progra-
mação tal como Java e refatorar em uma linguagem de marcação como
HTML. Comparada com HTML, Java realmente não mudou tanto assim.
C++ mudou menos ainda, e C muito pouco mesmo. Um programa escrito
em Java 1.0 ainda roda praticamente da mesma forma que um programa
escrito em Java 6. Muitas funcionalidades foram adicionadas à linguagem,
mas ela permaneceu mais ou menos a mesma.
Em contrapartida, HTML e tecnologias associadas evoluíram muito
rapidamente no mesmo período de tempo. O HTML de hoje realmente
não é a mesma linguagem de 1995. Palavras-chave foram removidas,
outras foram adicionadas. Sintaxe e algoritmos de análise sintática
mudaram. Apesar de um navegador moderno tal como o Firefox ou o
Internet Explorer 7 poder normalmente mostrar uma página no estilo
antigo, você descobrirá que um monte de coisas não funcionam muito
bem. Adicionalmente, componentes inteiramente novos tais como CSS
e ECMAScript foram adicionados à sopa de formatos que um navega-
dor deve consumir.
Muitas das refatorações deste livro focarão em atualizar sites para os
padrões web, especificamente:
• XHTML
• CSS
• REST
Elas ajudarão você a distanciar-se de
• Sopa de tags
• Marcação baseada em apresentação
• Aplicações com manutenção de sessão*
Essas não são decisões binárias ou do tipo tudo ou nada. Você pode fre-
quentemente melhorar as características de seus sites ao longo desses três
eixos sem rumar para um extremo. Uma característica importante da re-
fatoração é que ela é linear. Pequenas mudanças geram pequenas melho-
rias. Você não precisa fazer tudo de uma vez só. Você pode implementar
XHTML bem formado antes de você implementar XHTML válido. Você
pode implementar XHTML válido antes de mover para CSS. Você pode
ter um site com CSS completamente válido antes de você considerar o que
é necessário para eliminar sessões e cookies de sessão.

* N. de R. T.: O termo em inglês é stateful applications.

36 Refatorando HTML

E não é necessário implementar essas mudanças nessa ordem. Você

pode escolher as refatorações do catálogo que trazem mais benefícios para
suas aplicações. Você pode não requerer XHTML, mas pode precisar de
CSS desesperadamente. Você pode querer mover a arquitetura de sua apli-
cação para usar REST de forma a melhorar o desempenho, mas talvez não
dê muita importância para a conversão de seus documentos para XHTML.
No fim, a decisão é sua. Este livro apresenta as escolhas e opções de forma
que você mesmo possa medir os custos e benefícios.
Certamente é possível construir aplicações web usando uma sopa de
tags, layouts baseados em tabelas, mapas de imagens e cookies. Entre-
tanto, não é possível escalar essas aplicações, ao menos não sem um in-
vestimento desproporcional em tempo e recursos que a maioria de nós
não pode pagar. O crescimento horizontal (mais usuários) e o crescimento
vertical (mais funcionalidades) requer uma fundação sólida. Isso é o que
XHTML, CSS e REST fornecem.

Por que XHTML?

XHTML é simplesmente uma versão XML de HTML. Enquanto HTML
é, ao menos teoricamente, construída sobre SGML, XHTML é construída
sobre XML. XML é uma especificação muito mais simples e clara que
SGML. Logo, XHMTL é uma versão mais simples e clara de HTML. En-
tretanto, tal como uma arma, tudo depende se você está de frente para a
coronha ou para o cano.
XHTML torna a vida mais difícil para autores de documentos em troca
de tornar a vida dos consumidores de documentos mais fácil. Enquan-
to HTML perdoa, XHTML não. Em HTML, nada muito sério acontece
se você esquecer uma tag de fechamento ou se esquecer de umas aspas
aqui, outras ali. Algum texto extra pode ser marcado como negrito ou pode
ser indentado impropriamente. No pior dos casos, algumas poucas pala-
vras aqui ou ali podem desaparecer. Entretanto, a maioria da página será
mostrada. Essa característica de perdoar pequenos equívocos faz com que
HTML tenha uma curva de aprendizagem suave. Apesar de poder cometer
equívocos quando estiver escrevendo em HTML, nada de terrível acontece
a você.
Em contrapartida, XHTML é muito mais estrita. Um erro trivial tal
como esquecer aspas ou esquecer uma tag de fechamento que um nave-
gador iria recuperar silenciosamente em HTML torna-se um alarme má-
ximo, do tipo “largue-tudo”, uma emergência com sirenes tocando em
XHTML. Um erro pequeno, minúsculo, em um documento XHTML, e
o navegador levantará as mãos e se recusará a mostrar a página, confor-
me mostrado na Figura 1.2. Isso dificulta a escrita de páginas XHTML,
 Capítulo 1 Refatoração 37

FIGURA 1.2 Firefox respondendo a um erro em uma página XHTML.

*
especialmente se você estiver usando um editor de texto plano . Tal
como escrever um programa de computador, um erro de sintaxe quebra
tudo. Não existem atalhos, nem margem para erros.
Por que, então, alguém escolheria XHTML? Porque as mesmas carac-
terísticas que tornam o desenvolvimento de documentos XHTML um de-
safio (manipulação de erros draconiana) tornam o consumo de documen-
tos XHTML um passeio no parque. O trabalho é deslocado do navegador
para o autor. Um navegador web (ou qualquer outro programa que leia a
página) não precisa tentar descobrir qual o sentido de uma sopa de tags e
adivinhar o que a página realmente queria dizer. Se a página não é clara de
alguma forma, o navegador pode, na verdade deve, levantar suas mãos e se
recusar a processá-la. Isso torna o trabalho do navegador muito mais sim-
ples. Uma grande porção dos navegadores de hoje dedica grande parte de
seu código para analisar sintaticamente uma página HTML para corrigir
erros em páginas. Com XHTML eles não precisam fazer isso.
É claro, muitos de nós não somos vendedores de navegadores e nunca
iremos escrever um navegador. O que ganharíamos com o uso de XHTML e
sua manipulação de erros draconiana? Existem diversos benefícios. Primeiro
de todos, mesmo que a maioria de nós nunca escreva um navegador, muitos
de nós escrevemos programas que consomem páginas web. Tais programas
podem ser mashups, web spiders, agregadores de blogs, máquinas de busca,
ferramentas de autoria e uma dezena de outros programas que precisam ler
páginas web. Esses programas são muito mais fáceis de escrever quando os
dados que você está processando são XHTML em vez de HTML.

* N. de R. T.: Um editor de texto comum (como um bloco de notas) que não fornece o apoio à codifica-
ção geralmente presente em editores dos ambientes de desenvolvimento (IDEs).
38 Refatorando HTML

É claro, a maioria das pessoas que trabalham na Web e a maioria das

que criam documentos para a Web não são programadores clássicos e não
escreverão um web spider ou um agregador de blogs. Entretanto, existem
duas coisas que elas provavelmente escreverão: JavaScript e folhas de estilo.
Numericamente, esses são amplamente os tipos mais comuns de programas
que leem páginas web. Cada programa JavaScript embutido em uma página
web lê esta página. Cada folha de estilo CSS (apesar de não ser talvez um
programa no sentido tradicional da palavra) também lê a página web. JavaS-
cript e CSS são muito mais fáceis de escrever e depurar quando as páginas
que eles operam são páginas XHTML em vez de HTML. Na verdade, o cus-
to extra de criar uma página XHTML válida é mais que compensado pelo
tempo que você salva depurando seu código JavaScript e CSS.
Embora corrigir XHTML seja uma tarefa que incomoda e que leva
algum tempo, é um processo bastante direto e que não é tão difícil assim
de fazer. Um validador listará os erros. Então você percorre a lista e cor-
rige cada um deles. Na verdade, erros neste nível são bastante previsíveis
e podem muitas vezes ser corrigidos automaticamente, conforme vere-
mos nos Capítulos 3 e 4. Você normalmente não precisa corrigir todos
os problemas manualmente. Corrigir XHTML pode levar um pouco de
tempo, mas a quantidade de tempo é previsível. Tal tarefa não se torna
algo com um tempo indefinido para solução, como você encontra quando
está depurando JavaScript que deve rodar em diferentes navegadores ou
interações CSS com documentos HTML mal formados.
Escrever XHTML correto é apenas moderadamente desafiador quando
escrevemos manualmente em um editor de textos. Se ferramentas gerarem
sua marcação, o XHTML tornaria-se algo que não precisaria ser pensado.
Bons editores WYSIWYG HTML tais como o Dreamweaver 8 podem (e
devem) ser configurados para produzir documentos XHTML válidos por
padrão. Editores de marcação tais como o BBEdit podem também ser con-
figurados para usarem regras XHTML, apesar dos autores necessitarem
ser mais cuidadosos aqui. Muitos têm opções de verificar a validade de
documentos XHTML e podem até mesmo corrigir erros automaticamente
com o clique de um botão. Certifique-se de ter habilitado todas as pre-
ferências necessárias em seu editor escolhido. De maneira similar, boas
ferramentas de CMS, Wikis e máquinas de blog podem ser configuradas
para gerar XHTML. Se a sua ferramenta de autoria não oferece suporte
a XHTML, arrume uma ferramenta melhor. No século XXI, não existem
desculpas para que um editor HTML ou um sistema de publicação web
não ofereça suporte a XHTML.
Se seu site estiver usando um sistema de templates criado manual-
mente, você pode ter um pouco mais de trabalho; e você verá exatamente
 Capítulo 1 Refatoração 39

o que precisa fazer nos Capítulos 3 e 4. Apesar do processo aqui ser um

pouco mais manual, uma vez que você fizer as mudanças, documentos
XHTML serão criados automaticamente. Autores informando conteúdo
por meio de bases de dados ou formulários web podem nem precisar trocar
seu fluxo de trabalho, especialmente se eles já estiverem informando da-
dos em um formato não HTML tal como markdown ou wikitext. O sistema
pode fazer a transição para XHTML de forma transparente e sem esforço.
A segunda razão para preferir XHTML em vez de HTML é a compati-
bilidade entre navegadores. Na prática, XHTML é muito mais consistente
nos navegadores atuais que HTML. Isso é especialmente verdade para pá-
ginas complexas que utilizam amplamente CSS para estilos ou JavaScript
para comportamento. Apesar de os navegadores poderem corrigir enganos
de marcação em HTML clássico, eles nem sempre os corrigem da mesma
maneira. Dois navegadores podem ler a mesma página e produzir modelos
internos muito diferentes a partir dela. Isso torna um desafio escrever uma
folha de estilo ou script que funcione em diferentes navegadores. Em con-
trapartida, XHTML não deixa muito para a interpretação do navegador.
Há menos espaço para problemas de navegador. Apesar de ser certamente
uma verdade que diferentes navegadores diferem em seu nível de suporte
a CSS, e que seus dialetos de JavaScript e árvores DOM não sejam com-
pletamente compatíveis, mover para XHTML remove ao menos a maior
causa dos problemas entre navegadores. Não é uma solução completa, mas
corrige muitas coisas.
A terceira razão para preferir XHTML em vez de HTML é permitir a
você incorporar novas tecnologias em suas páginas no futuro. Por razões
já discutidas, XHMTL é uma plataforma muito mais forte para ser usada
como base. HTML é uma linguagem muito boa para mostrar textos e fi-
guras, e não é tão ruim para formulários simples. Entretanto, além disso o
navegador torna-se primariamente um hospedeiro para outras tecnologias
como Flash, Java e AJAX. Existem muitas coisas que o navegador não
pode fazer facilmente, tal como lidar com expressões matemáticas e no-
tação musical. Existem outras coisas que são muito mais difíceis do que
elas deveriam ser, tal como alertar o usuário quando ele digitar um valor
incorreto em um campo de um formulário.
Tecnologias existem para melhorar isso, e mais estão em desenvolvimen-
to. Tais tecnologias incluem MathML para equações, MusicXML para parti-
turas, Scalable Vector Graphics (SVG) para figuras animadas, XForms para
aplicações-cliente muito poderosas, e mais. Todas essas tecnologias iniciam-
se a partir da fundação de XHTML. Nenhuma delas opera apropriadamente
em HTML clássico. Refatorar suas páginas para XHTML permitirá que você
obtenha vantagem dessas e de outras tecnologias novas que estão avançan-
40 Refatorando HTML

do. Em alguns casos, elas deixam que você faça coisas que você não pode-
ria fazer agora. Em outros casos, elas deixam você fazer coisas que você já
está fazendo agora, mas mais rapidamente e de uma maneira mais barata. De
qualquer forma, elas compensam o custo de refatorar para XHTML.

Por que CSS?

A separação de apresentação e conteúdo é um dos princípios de design
fundamentais de HTML. Separar a apresentação do conteúdo permite a
você servir o mesmo texto a diferentes clientes e deixá-los decidir como
formatá-lo da forma que melhor atender às suas necessidades. Um nave-
gador de um telefone celular não tem as mesmas capacidades que um na-
vegador desktop tal como o Firefox. Na verdade, um navegador pode até
mesmo não mostrar o conteúdo visualmente. Por exemplo, ele pode ler o
documento para o usuário.
Consequentemente, o HTML deve focar no que o documento significa
em vez de como ele se parece. Mais importante, o estilo de autoria respeita
as preferências do usuário. Um leitor pode escolher as fontes e cores que
melhor lhe convêm em vez de depender dos padrões da página. Um tamanho
não atende melhor a todos. O que é facilmente legível para um piloto de 30
anos de idade com uma visão perfeita pode ser impossível de ler para uma
avó de 85 anos. Um belo design vermelho e verde pode ser incompreensível
para um usuário daltônico. E um layout de tabela cuidadosamente montado
pode ser uma grande confusão de palavras aleatórias para um motorista ou-
vindo uma página em seu telefone celular enquanto dirige numa estrada.
Então, em HTML, você não diz que o texto “Por que CSS?” uns poucos
parágrafos acima deve ser formatado com a fonte Arial, tamanho 11, negri-
to, alinhado à esquerda. Em vez disso, você diz que o texto é um cabeçalho
H2. Ao menos você fazia, até que o Netscape surgiu e inventou a tag de
fonte e uma dúzia de outros elementos de apresentação, os quais come-
çaram a ser usados pelas pessoas imediatamente. O W3C respondeu com
CSS, mas o estrago já havia sido feito. As páginas web em todos os lugares
foram criadas com uma mistura confusa de fontes, frames, textos deslizan-
tes e outros elementos de apresentação. Elementos semânticos tais como
blockquote, table, igm e ul foram subvertidos para atender aos objetivos
de apresentação. Para ser honesto, isso nunca funcionou realmente muito
bem, mas por um longo tempo era o melhor que tínhamos.
Isso não é mais verdade. O CSS atual permite não somente os mesmos,
mas sim melhores layouts e apresentações que alguém poderia criar usando
hacks tais como frames, GIFs de espaçamento, e texto inserido dentro de
figuras. Os layouts baseados em CSS não só são mais bonitos, mas também
são mais leves, mais eficientes e mais acessíveis. Eles fazem com que as pá-
 Capítulo 1 Refatoração 41

ginas sejam carregadas mais rapidamente e sejam mostradas de uma maneira

melhor. Com algum esforço, eles podem produzir páginas que funcionam
melhor em uma ampla variedade de navegadores em múltiplas plataformas.
Mover a marcação para fora da página em uma folha de estilo separada
nos permite começar com uma página simples que é ao menos legível para
todos os leitores, mesmo aqueles com navegadores de dez anos de idade. Po-
demos então aplicar belos efeitos a essas páginas que melhoram a experiên-
cia dos usuários que estão prontos para manipulá-las. Entretanto, ninguém é
deixado de fora completamente. Páginas degradam-se graciosamente.
Mover a marcação para fora da página também traz benefícios para os
desenvolvedores. Primeiro, permite que diferentes pessoas com diferen-
tes conhecimentos trabalhem naquilo que elas são melhores. Escritores
podem escrever palavras em uma linha sem se preocupar como o resto
será formatado. Designers podem organizar e reorganizar uma página sem
tocar nas palavras dos escritores. Programadores podem escrever scripts
que adicionam atividades a uma página sem interferir com a aparência.
CSS permite que todos façam aquilo que sabem fazer melhor sem ficar
interferindo no trabalho alheio.
Embora CSS seja benéfica para escritores e designers, é uma dádiva
para os desenvolvedores. Da perspectiva de um programador, uma página
é muito, muito mais simples quando todo o layout e a informação de estilo
é retirada e movida para uma folha de estilo CSS separada. A árvore do
documento tem menos elementos e não está aninhada tão profundamente.
Isso torna mais fácil escrever scripts que interagem com a página.
Finalmente, os maiores ganhadores são os sobrecarregados webmas-
ters que gerenciam todo o site. Mover a marcação para fora das páginas
em folhas de estilo separadas permite a eles combinarem estilos comuns
e manterem um visual consistente ao longo de todo o site. Trocar a fonte
padrão de Arial para Helvetica não mais requer editar milhares de docu-
mentos HTML. Isso pode ser feito com uma simples modificação em um
único arquivo de folha de estilo.
CSS permite aos desenvolvedores web, webmasters, e designers web se-
guirem o princípio DRY: Don’t Repeat Yourself (Não se repita). Ao combinar
regras comuns em arquivos separados, reutilizáveis, CSS torna muito mais
simples a manutenção, a atualização e a edição desses arquivos. Mesmo os
usuários finais serão beneficiados dado que eles carregam as regras de estilo
para um site uma vez, em vez de carregá-las a cada página. As páginas meno-
res carregam e são mostradas mais rapidamente. Todo mundo sai ganhando.
Finalmente, não vamos negligenciar a importância de CSS para nossos
gerentes de redes e auditores. Deve haver apenas um kilobyte ou dois de
informação puramente de apresentação em cada página. Entretanto, soma-
das as milhares de páginas e os milhões de usuários, esses kilobytes vão se
42 Refatorando HTML

acumulando. Você obtém economias reais de largura de banda ao carregar

os estilos apenas uma vez, em vez de a cada página. Quando a ESPN tro-
cou para marcação usando CSS ela economizou cerca de dois terabytes de
dados por dia. Neste nível, isso se traduz em economias reais de custos que
você pode medir no final das contas. Agora, admitamos, a maioria de nós
não é a ESPN e apenas podemos sonhar em ter dois terabytes de tráfego
por dia, imagine ter dois terabytes por dia que podemos economizar. Inde-
pendentemente disso, se você está experimentando picos de sobrecarga ou
*
é promovido à primeira página do Digg inesperadamente, mover seu estilo
para folhas de estilo CSS externas pode ajudá-lo a lidar com isso.

Por que REST?

Transferência de Estado Representacional (REST – Representational State
Transfer) é a tecnologia mais antiga e mesmo assim a menos familiar dos
três objetivos de refatoração que apresentei aqui. Apesar de eu focar prin-
cipalmente em HTML neste livro, ninguém pode ignorar o protocolo pelo
qual os documentos HTML trafegam. Tal protocolo é chamado de HTTP,
e REST é a arquitetura desse protocolo.
Entender HTTP e REST tem consequências importantes para o
design de aplicações web. Toda vez que você coloca um formulário em
uma página, ou usa AJAX para enviar dados para um programa JavaS-
cript e recebê-los de volta, você está usando HTTP. Use HTTP corre-
tamente e você desenvolverá aplicações robustas, seguras e escaláveis.
Use-o incorretamente e o melhor que você pode esperar é um sistema
com uma funcionalidade marginal. O pior que pode acontecer, entretan-
to, é bastante ruim: um web spider que apague todo o seu site, um site
de compras que não aguente um tráfego pesado durante a temporada
de compras do Natal ou um site que as máquinas de busca não podem
indexar ou os usuários não podem encontrar.
Apesar de páginas HTML estáticas básicas serem inerentemente ba-
seadas em REST, a maioria das aplicações web mais complexas não o
são. Em particular, você deve considerar REST toda vez que sua aplicação
envolver os seguintes itens comuns:
• Formulários
• Autenticação de usuário
• Cookies

* N. de R. T.: Digg é uma rede social que reúne links para notícias, podcasts e vídeos enviados e prin-
cipalmente avaliados pelos próprios usuários. Os links mais aclamados pela comunidade (possuindo
mais votos – diggs) são exibidos na primeira página do site.
 Capítulo 1 Refatoração 43

• Sessões
• Estado
Esses itens são bastante problemáticos, e muitas aplicações atualmente
os utilizam muito mais de forma errônea do que correta. A Web não é uma
rede local. As técnicas que funcionaram para sistemas cliente/servidor li-
mitados a algumas dúzias ou algumas centenas de usuários não se compa-
ram sistemas web que devem acomodar de milhares a milhões de usuários.
Arquiteturas cliente/servidor baseadas em sessões e conexões persistentes
simplesmente são impossíveis na Web. Tentativas de recriá-las falham em
grande escala, frequentemente com consequências desastrosas.
REST, conforme implementado em HTTP, tem várias ideias chave, as
quais são discutidas nas seções seguintes.

Todos os recursos são identificados por URLs

Marcar recursos distintos com URLs distintas permite a adição de itens
favoritos, a criação de links, o armazenamento pelas máquinas de busca
e a aparição em rankings na Internet. É muito mais fácil encontrar um re-
curso quando você pode dizer “Vá para http://www.example.com/foo/bar”
do que se você tiver que dizer “Vá para http://www.example.com/. Digite
‘bar’ no campo do formulário. Então pressione o botão ‘foo’”.
Não tenha medo das URLs. A maioria dos recursos deve ser identifica-
da apenas por URLs. Por exemplo, um registro de consumidor deve ter uma
URL tal como http://example.com/patroninfo/username em vez de http://
example.com/patroninfo/. Ou seja, cada consumidor deve ter uma URL se-
parada que se liga diretamente a seu registro (protegido por uma senha, é
claro), em vez de todos os consumidores compartilharem uma única URL
cujo conteúdo muda dependendo do valor de algum cookie de login.

Operações seguras, livres de efeitos colaterais tais como

consultas ou operações de navegação usando GET
O Google pode apenas indexar páginas que são acessadas via GET. Os
usuários podem apenas marcar como favoritas páginas que são acessadas
via GET. Outros sites podem apenas ligarem-se a páginas por meio de
GET. Se você preocupa-se em aumentar o tráfego de seu site, você precisa
fazer com que a maioria dele seja acessível via GET.

Operações não seguras, como comprar um item ou adicionar

um comentário a uma página, operam usando POST
Web spiders rotineiramente seguem os links de uma página que são acessí-
veis via GET, algumas vezes mesmo quando é dito que eles não devem seguir
44 Refatorando HTML

tais links. Os usuários digitam URLs em barras de endereços dos navegado-

res e então as editam para ver o que acontece. Os navegadores pré-carregam
páginas ligadas. Se uma operação tal como apagar conteúdo, concordar com
um contrato, ou fazer um pedido é realizada via GET, então algum programa
em algum lugar irá realizá-la sem perguntar ou consultar um usuário real,
algumas vezes com consequências desastrosas. Sites inteiros desapareceram
quando o Google os descobriu e começou a seguir os links “apague esta pá-
gina”, tudo porque GET estava sendo usado em vez de POST.

Cada requisição é independente das demais

Tanto o cliente quanto o servidor podem ter um estado, mas nenhum deles
baseia-se no outro lado para lembrar qual é o estado atual. Toda a informa-
ção necessária é transferida em cada comunicação. A não manutenção de
estado permite a escalabilidade por meio de caching e servidores proxy. Ela
também permite que um servidor seja facilmente substituído por um conjun-
to de servidores se for necessário. Não existe nenhum requisito que o mesmo
servidor deva responder ao mesmo cliente duas vezes em sequência.
Aplicações web robustas e escaláveis trabalham com o HTTP e não
contra ele. Aplicações RESTful podem fazer tudo o que as aplicações
cliente/servidor mais familiares fazem, e elas podem fazer isso em gran-
de escala. Entretanto, implementar isso pode requerer algumas das maio-
res mudanças em seus sistemas. Independentemente disso, se você está
tendo problemas de escalabilidade, essas estão dentre as refatorações
mais críticas a serem aplicadas.

OBJEÇÕES À REFATORAÇÃO
Não é incomum que pessoas que vão desde o CEO, até gerentes e desenvol-
vedores HTML tenham objeções contra o conceito de refatoração. A preo-
cupação é expressa de muitas maneiras, mas normalmente é algo como:

Não temos tempo a perder com melhorias no código. Temos

que implementar essa funcionalidade agora!

Existem duas possíveis respostas a esse comentário. A primeira é que

refatoração economiza tempo a longo prazo. A segunda é que você tem
mais tempo do que pensa que tem. Ambas são verdadeiras.
Refatoração economiza tempo a longo prazo, e frequentemente no
curto prazo, dado que código claro e organizado é mais fácil de corrigir e
manter. É mais fácil construir sobre a rocha que sobre a areia. É mais fácil
de encontrar erros em código claro que em código obscuro. Na verdade,
 Capítulo 1 Refatoração 45

quando a fonte de um erro não aparece rapidamente, eu normalmente co-

meço a refatorar até que ela apareça. O processo de refatoração modifica
tanto o código propriamente dito quanto minha visão dele. A refatoração
pode levar meus olhos para novos locais e permitir que eu veja um código
antigo de um modo que eu nunca havia visto.
É claro, para maximizar a economia de tempo, é importante automatizar
o quanto possível as atividades de refatoração. Por isso irei enfatizar fer-
ramentas tal como Tidy e TagSoup, bem como soluções simples, baseadas
em expressões regulares. Apesar de algumas refatorações necessitarem de
esforços humanos significativos – converter um site de tabelas para layouts
baseados em CSS, por exemplo – muitas outras podem ser feitas com o
clique de um botão – converter uma página estática para XHTML bem for-
mado, por exemplo. Muitas refatorações estão no meio desta escala.
Bem menos reconhecido é o fato de que muito mais tempo para refa-
toração está realmente disponível do que aquele que os gerentes contam
em suas planilhas. Escrever novo código é difícil, e requer grandes blocos
ininterruptos de tempo. Um dia de trabalho típico preenchido com email,
chamadas telefônicas, reuniões, pausas para fumar, e assim por diante, não
oferece, infelizmente, muitos blocos ininterruptos de tempo para que os
desenvolvedores possam trabalhar.
Em contrapartida, a refatoração não é difícil. Ela não requer grandes
blocos ininterruptos de tempo. Sessenta minutos de refatoração feitos em
incrementos de seis minutos em momentos variados durante o dia têm pra-
ticamente o mesmo impacto que um bloco de 60 minutos de refatoração.
Sessenta minutos ininterruptos não são suficientes nem para iniciar a co-
dificar, e blocos de seis minutos são praticamente inúteis para desenvolvi-
mento.
Também vale apena levar em consideração o estado de humor dos de-
senvolvedores. A verdade pura e simples é que você é mais produtivo al-
gumas vezes que outras. Algumas vezes você pode criar centenas de linhas
de código com a mesma rapidez que pode digitar, e outras vezes é um
esforço mover os dedos pelo teclado. Algumas vezes você está na área,
completamente focado na tarefa que tem em mãos. Outras vezes você está
distraído por uma dor de dente, uma reunião com o cliente que acontecerá
em instantes ou com seus planos para o final de semana. Codificar, proje-
tar e outras atividades complexas não funcionam muito bem quando você
está distraído, mas refatoração não é uma tarefa complexa. É uma tarefa
simples. Refatoração permite que você faça algo e avance, mesmo quando
você estiver operando com uma eficiência significativamente reduzida.
Talvez o mais importante, descobri que quando eu estou operando
abaixo do pico de eficiência, a refatoração me permite aumentar a veloci-
dade e me concentrar. É uma forma de mergulhar um dedo na parte rasa
46 Refatorando HTML

da piscina e se acostumar com a temperatura antes de mergulhar com-

pletamente. Realizar uma tarefa simples tal como refatorar permite que
eu me mova mentalmente para a área de trabalho, de forma que eu possa
trabalhar em problemas maiores, mais desafiadores.

Fazendo as coisas acontecerem

A refatoração não é única nisso, a propósito. Existem muitas tarefas
produtivas que você pode usar para melhorar o seu foco no trabalho.
Escrever testes, medir e melhorar a cobertura de código, corrigir erros
conhecidos, usar analisadores estáticos de código e mesmo correções
ortográficas podem ajudar você a ser mais produtivo e fazer as coisas
acontecerem justamente quando você não está no seu melhor dia para
realizar grandes tarefas. A chave aqui é não ficar bloqueado em nenhu-
ma tarefa. Sempre tenha algo mais (idealmente várias coisas a mais)
para ser realizado a qualquer momento. Algumas vezes você precisa
apenas encontrar a tarefa que melhor se encaixa no momento, em vez
de encontrar o momento para encaixar a tarefa.

Refatoração é realmente um caso clássico de trabalhar de um modo

mais inteligente, não mais difícil. Apesar de essa máxima poder ser um
bom clichê para uma paródia de Dilbert, ela realmente se aplica aqui.