Prefácio

Bem-vindo à refatoração de JavaScript . Ao longo deste livro, veremos maneiras de es-

crever JavaScript melhor, inspirando-se em técnicas clássicas de refatoração en-
quanto explora vários estilos de codificação.

Por que este livro existe

Goste ou não, o JavaScript não vai desaparecer. Não importa qual framework ou lin-
guagem ou biblioteca “compila para JS” você use, bugs e problemas de desempenho
sempre serão um problema se a qualidade subjacente do seu JavaScript for ruim. As
reescritas, incluindo a portabilidade para a estrutura do mês, são terrivelmente caras
e imprevisíveis. Os bugs não desaparecerão magicamente e podem se reproduzir ale-
gremente em um novo contexto. Para complicar ainda mais as coisas, os recursos se-
rão descartados, pelo menos temporariamente.

Este livro fornece orientações claras sobre a melhor forma de evitar essas abordagens
patológicas para escrever JavaScript. Código ruim não precisa ficar assim. E torná-lo
melhor não precisa ser intimidante ou excessivamente caro.

Para quem é este livro

Este livro destina-se a programadores que tenham alguma experiência em escrever

códigos ruins e interesse em escrever códigos melhores. É para aqueles que escrevem
JavaScript no frontend ou no backend. É para aqueles que escrevem JavaScript por
opção, bem como para aqueles que estão “presos a ele” devido ao monopólio do Ja-
vaScript da plataforma do navegador.

Se você é um iniciante absoluto, talvez queira escrever algum código ruim por alguns
meses primeiro. Se você não estiver interessado em escrever um código melhor, tal-
vez não tenha paciência para este livro. Se nenhuma dessas situações descreve você,
estamos prontos.

Curiosamente, existem vários esforços trabalhando para tornar o JavaScript melhor,

enquanto ao mesmo tempo outros visam torná-lo obsoleto. O número de maneiras de
escrever JavaScript bom e ruim continua a se expandir. Os frameworks podem per-
correr um longo caminho para lidar com a complexidade, mas os programadores li-
mitados por frameworks serão limitados. Se você achar que você (ou sua base de có-
digo) está lutando para trabalhar fora de um framework (ou em algumas das bordas
mais confusas dele), este livro deve lhe dar novas ideias sobre como abordar seu
trabalho.

Se você tiver problemas para testar, depurar ou confiar em sua base de código, este
livro deve ser útil.

A maioria de nós não trabalha em bases de código perfeitas, especialmente em JavaS-

cript, onde os engenheiros podem usar principalmente Ruby, Python, Java e assim por
diante. O que este livro faz é ajudá-lo a identificar quais partes específicas de uma
base de código são ruins, ao mesmo tempo em que oferece várias opções de melhoria.

Como usar este livro

Os capítulos 1 a 5 descrevem a interação entre JavaScript, refatoração, qualidade, con-

fiança e teste. Em muitos livros, é comum incluir testes no final. Neste livro, para os
tipos de código que estamos explorando, isso não seria apropriado. O teste é essencial
para a confiança. A confiança é essencial para a refatoração. A refatoração é essencial
para a qualidade, que é o objetivo:

teste -> confiança -> refatoração -> qualidade

O JavaScript (e seu ecossistema) fornece o espaço no qual essa transformação ocorre,

de modo que esses capítulos iniciais necessariamente incluem uma exploração da
própria linguagem. Se você estiver completamente confortável com a transformação
que acabamos de descrever, você pode querer dar uma olhada ou pular estes capítu-
los. Embora isso não seja recomendado, é o seu livro, então você pode usá-lo como
quiser. Se você acha que é melhor usá-lo como um batente de porta ou para iniciar
uma fogueira para aquecer ou algum tipo de sacrifício, vá em frente. Se você encon-
trar um uso não convencional para o livro, envie-me uma foto ou um vídeo por e-
mail. Estou em http://evanburchard.com/contact ou @evanburchard no Twitter e no
GitHub.
P O S S O G R AVA R O U B L O Q U E A R C Ó P I A S D I G I TA I S TA M B É M ?

Infelizmente não. No entanto , como este livro está sob uma licença Creative Commons, você
pode compartilhar links para a versão HTML e quaisquer outros arquivos disponíveis em
http://refactoringjs.com , por exemplo.

Após o Capítulo 5 , as coisas ficam mais difíceis, especialmente se você pulou de 1 a 5.

Há mais código para escrever e acompanhar. Nos Capítulos 6 e 7 , passamos pela refa-
toração de funções e objetos, e não nos esquivamos de algumas das partes mais com-
plicadas do JavaScript. Geralmente, o objetivo desses capítulos é fornecer opções para
melhorar o código sem alterar radicalmente a interface. Por meio da aplicação das
técnicas encontradas nestes dois capítulos, você poderá transformar uma base de có-
digo confusa em uma base de qualidade decente.

O Capítulo 8 expande nossa visão de arquitetura para aquelas que incluem (ou evi-
tam) hierarquias.

Os Capítulos 9 , 10 e 11 são dedicados a tópicos específicos (padrões de design, progra-

mação assíncrona e programação funcional, respectivamente) que podem levar seu
código além dessa linha de base, mas necessariamente envolvem alterações mais
agressivas. Com os padrões de projeto no Capítulo 9 , reconhecemos maneiras de es-
tender e desenhar do lado orientado a objetos do JavaScript e abordamos a conexão
histórica entre refatoração e programação orientada a objetos (OOP). No Capítulo 10 ,
lidamos com a realidade de que muitas bases de código JavaScript têm mais de uma
coisa para fazer ao mesmo tempo. No Capítulo 11, fazemos um tour pela programação
funcional por meio de algumas bibliotecas que fornecem interfaces úteis que vão
além daquelas que nossas Array funções padrão ( forEach , map , reduce , etc.) nos
fornecem.

De certa forma, esses três últimos capítulos em particular rompem com nosso objetivo
inicial de refatoração, alterando os detalhes da implementação sem alterar a interface .
Por outro lado, essas interfaces são úteis e às vezes inevitáveis. Podemos facilmente
nos encontrar querendo escrever código que seja necessariamente assíncrono por
motivos de desempenho. Ou podemos nos encontrar “presos” em uma base de código
que investiu muito em coisas boas ou ruinstentativas de OOP ou programação funcio-
nal (FP). Portanto, seja por escolha ou código que herdamos, essas são partes do Ja-
vaScript que devemos prestar atenção e poder melhorar. Se você adotar um para-
digma completamente diferente de uma base de código, é improvável que você esteja
“refatorando” no sentido que queremos dizer na maior parte do livro.
Se quisermos ser rígidos sobre isso, esses capítulos ainda refatoram dentro de seus pa-
radigmas (OOP para melhor OOP, assíncrono para melhor assíncrono e FP para me-
lhor FP), e se quisermos pensar nos termos mais amplos sobre a execução do nosso
programa (por exemplo, “executando ” como entrada e “estar satisfeito com a forma
como funcionou” como saída ), então podemos estar refatorando mesmo pulando de
paradigma em paradigma. Eu encorajo você a trabalhar primeiro com mudanças me-
nores e incrementais que sejam fáceis de testar e nas quais você tenha
confiança. node myprogram.js

Para citar a tese original de William Opdyke sobre refatoração:

Essa definição de equivalência semântica permite mudanças em todo o programa,

desde que esse mapeamento de valores de entrada para saída permaneça o
mesmo. Imagine que um círculo é desenhado em torno das partes de um pro-
grama afetadas por uma refatoração. O comportamento visto de fora do círculo
não muda. Para algumas refatorações, o círculo envolve a maior parte ou todo o
programa. Por exemplo, se uma variável for referenciada em todo o programa, a
refatoração que altera seu nome afetará grande parte do programa. Para outras
refatorações, o círculo cobre uma área muito menor;

por exemplo, apenas parte de um corpo de função é efetivada quando uma cha-
mada de função específica contida nele é expandida em linha. Em ambos os casos,
a ideia-chave é que os resultados (incluindo os efeitos colaterais) das operações
invocadas e as referências feitas de fora do círculo não mudam, quando vistas de
fora do círculo. 1

Embora sejamos livres para desenhar “o círculo” tão grande quanto quisermos, é
muito comum que o termo refatoração seja usado como se significasse simplesmente
“alterar código”. Como discutimos no Capítulo 1 , não. Isso é mais fácil de ver em pe-
quena escala, como aquelas em que passamos mais páginas. Pense nos Capítulos 8 , 9
e 10 apresentando primeiro como opções de arquitetura e as segundas possibilidades
para criar um código melhor (com segurança e incrementalmente) dentro dessas op-
ções. Por exemplo, se alguém disser algo sobre “ refactoring para usar código assín-
crono”, provavelmente é um problema muito amplo para ser executado de maneira
segura e incremental. Mas se você quiser pensar no Capítulo 9como lhe dando o po-
der de fazê-lo, não posso impedi-lo. É o seu livro agora. Você pode desenhar o círculo
do tamanho que quiser.

Se você achar alguma das ferramentas ou conceitos confusos, provavelmente achará

o apêndice útil. Se você estiver procurando por exemplos de código e outras informa-
ções, visite o site do livro . Você também pode encontrar uma versão HTML do livro,
se preferir ler dessa maneira.

Então, em resumo, use este livro para aprender sobre:

Reestruturação
Teste
JavaScript
Refatorando e testando JavaScript
Alguns paradigmas JavaScript
Refatorando e testando dentro desses paradigmas JavaScript

Alternativamente (sob supervisão de um adulto, é claro), a versão em papel do livro

pode ser incendiada e usada para:

Cordialidade
Protesto
Sacrifícios rituais de livros de tecnologia

Os arquivos digitais de http://refactoringjs.com podem ser repassados ​de acordo com

as restrições de licença Creative Commons.

Se você tiver algum problema, dúvida, reclamação ou elogio, sinta-se à vontade para
entrar em contato comigo através do meu site .

Algumas palavras deste livro

Aplicativo, Aplicativo, Programa

Algumas palavras neste livro são imprecisas. Aplicativo , aplicativo , programa e site
são intercambiáveis ​na maioria das vezes. Caso haja alguma confusão, este livro des-
creve princípios gerais para melhorar a qualidade do JavaScript, portanto, nenhum
desses termos deve ser tomado literalmente. Talvez seu código seja uma biblioteca ou
framework? De qualquer forma, as técnicas deste livro devem ser aplicadas
perfeitamente.

Inclusão através de palavras e diagramas

Algumas palavras neste livro podem não parecer inclusivas para todos. Tentei equili-
brar o uso de ele e ela , o que percebo que não é o ideal de todos. Embora eu prefira
usar o singular eles, isso não está dentro das diretrizes do editor no momento.

Além disso, estou percebendo (tarde demais) que minha confiança em diagramas, es-
pecialmente os do Capítulo 5, pode fazer um terrível desserviço aos leitores com defi-
ciência visual. Se você sentir que perdeu algum conteúdo por esse motivo, sinta-se à
vontade para entrar em contato comigo com qualquer dúvida.

Usuários

Há também uma palavra neste livro que eu realmente odeio, e isso é usuários . É im-
preciso e também cria certa distância entre os criadores (desenvolvedores/designers)
e os consumidores (usuários). Palavras mais precisas e caridosas geralmente são espe-
cíficas para o domínio do problema, ou então ficamos presos a termos como “pessoas”
ou “pessoas que usam o programa/site”. Se não houver um termo mais específico do
que pessoa ou usuário (inclusive customer ), pode ser uma dica de que o modelo de
negócios é baseado puramente na venda de pessoas como dados, mas isso é outra
discussão.

A questão é que o termo usuário é usado neste livro para transmitir um conceito fami-
liar: uma pessoa que usa o programa/site. Além disso, ainda não existem termos mag-
nânimos e precisos para suplantar os termos relacionados de experiência do usuário
(UX) ou interface do usuário (UI). Em vez de explicar isso em vários lugares ou usar
termos não padronizados ou específicos para conceitos frequentemente abstratos, op-
tei por economizar o esforço e apenas falar sobre isso aqui.

De qualquer forma, endosso totalmente a seguinte citação (e suas implicações) do “Le-

onardo da Vinci de Data”, Edward Tufte:

Existem apenas duas indústrias que se referem a seus clientes como usuários:
drogas ilegais e software houses.

Existe um movimento chamado “design ético” que esperamos ajudar a indústria a

abandonar esse termo (e as práticas imprudentes que derivam dele) em algum
momento.

Bibliotecas e comunidades de terceiros

Embora eu tenha tentado muito apresentar as melhores ferramentas para demons-
trar os fundamentos de refatoração e teste em JavaScript, pode haver momentos em
que você descubra que uma ferramenta específica não está funcionando para você. A
grande notícia aqui é que o JavaScript tem um rico ecossistema de opções. Tenho pre-
ferência por ferramentas simples, flexíveis e atômicas, mas você pode se sentir dife-
rente. Estruturas grandes em particular não são exploradas neste texto, pois tendem a
vir com seus próprios ecossistemas de outras ferramentas (muitas vezes bastante ati-
vas e variadas). Eu absolutamente recomendaria um framework quando você está co-
meçando, mas eles são mais úteis quando combinados com a facilidade na linguagem
subjacente, que acredito que este livro vai te ensinar muito bem.

Além disso, cada ferramenta, estrutura e biblioteca virá com alguma comunidade e
história. Assim como não acredito em nenhuma maneira verdadeira de ferramentas,
também não endosso a comunidade por trás de nenhum código ou projeto de tercei-
ros. Muitos projetos virão com um código de conduta que informará se participar de-
les será um uso agradável do seu tempo.

API, Interface, Implementação, “Código do Cliente”

Isso fica um pouco obscuro, mas uma coisa que eu gostaria de destacar mais é a hie-
rarquia não em termos de objetos, mas na interface de uma base de código bem proje-
tada. Quando o código é um script simples, esperamos que ele seja executado de cima
para baixo, como um procedimento. À medida que uma base de código amadurece
(através do design, não da carnificina misturada com entropia), esperamos que ela se
desenvolva em três camadas principais (embora isso seja obviamente estendido em
bases de código mais complexas ).

A primeira camada — o código nos bastidores, mais profundo na base de código — é

chamada neste livro de implementação . Para refatoração, a distinção mais impor-
tante é entre a implementação e a próxima camada. Essa segunda camada pode ser
chamada de interface ou API e descreve as funções e objetos “públicos” com os quais
se deve esperar interagir se uma base de código for usada como módulo. A terceira
camada de consequência é às vezes chamada de código do cliente ou código de cha-
mada . Refere-se ao código que é escrito para interagir com a camada de interface.
Este é o código que as pessoas que usam um módulo escreveriam, bem como o código
de teste que escreveremos para testar a camada de interface.
NOÇÕES BÁSICAS DE ARQUITETURA

Ao longo deste livro, estamos criando programas que começam muito desestruturados, e nosso
principal objetivo (independentemente de um paradigma como OOP ou FP) é fazer divisões en-
tre essas três camadas. Isso é o que permite que o código seja testável e portátil. Se você de-
pende principalmente de estruturas que fornecem sua própria organização, esse processo pode
não ser familiar.

Entradas (Variáveis ​Não Locais e Livres)

Ao longo do livro (especialmente no Capítulo 5), distinguimos três tipos de entradas:

Entradas explícitas (os parâmetros passados ​para uma função)

Entradas implícitas (o this que se refere ao objeto de contexto, função ou classe
que o contém)
Entradas não locais (os valores usados ​em uma função ou objeto que são definidos
em outro lugar )

Há duas coisas dignas de nota aqui. Primeiro, variáveis ​locais (ou constantes) criadas
dentro do escopo de uma função não são consideradas “entradas” para fins de diagra-
mação ou de outra forma. Segundo, embora o termo entrada não local seja usado
como um termo preciso neste texto, variável livre é um nome mais comum. No en-
tanto, é um pouco impreciso, uma vez que entradas não locais podem ser constantes
em vez de variáveis. Da mesma forma, alguns usam o termo variáveis ​vinculadas para
se referir ao que chamamos de entradas explícitas e, até certo ponto, também entra-
das implícitas .

Convenções utilizadas neste livro

As seguintes convenções tipográficas são usadas neste livro:

itálico
Indica novos termos, URLs, endereços de e-mail, nomes de arquivo e extensões
de arquivo. Também usado ocasionalmente para ênfase e contraste.

Constant width
Usado para listagens de programas, bem como dentro de parágrafos para se re-
ferir a elementos de programa, como nomes de variáveis ​ou funções, bancos de
dados, tipos de dados, variáveis ​de ambiente, instruções e palavras-chave.
 Constant width bold
Mostra comandos ou outro texto que deve ser digitado literalmente pelo
usuário.

Constant width italic

Mostra o texto que deve ser substituído por valores fornecidos pelo usuário ou
por valores determinados pelo contexto.

DICA

Este elemento significa uma dica ou sugestão.

O B S E RVA Ç Ã O

Este elemento significa uma nota geral.

AV I S O

Este elemento indica um aviso ou cuidado.

Usando exemplos de código

O material suplementar (exemplos de código, exercícios, etc.) está disponível para

download em https://refactoringjs.com .

Este livro está aqui para ajudá-lo a fazer o seu trabalho. Em geral, se um código de
exemplo for oferecido com este livro, você poderá usá-lo em seus programas e docu-
mentação. Você não precisa entrar em contato conosco para obter permissão, a menos
que esteja reproduzindo uma parte significativa do código. Por exemplo, escrever um
programa que usa vários pedaços de código deste livro não requer permissão. Vender
ou distribuir um CD-ROM de exemplos dos livros da O'Reilly requer permissão. Res-
ponder a uma pergunta citando este livro e citando um código de exemplo não requer
permissão. Incorporar uma quantidade significativa de código de exemplo deste livro
na documentação do seu produto requer permissão.

Agradecemos, mas não exigimos, atribuição. Uma atribuição geralmente inclui o tí-
tulo, autor, editora e ISBN. Por exemplo: “ Refatorando JavaScript por Evan Burchard
(O'Reilly). Copyright 2017 O'Reilly Media, 978-1-491-96492-7.”

Se você achar que o uso de exemplos de código está fora do uso justo ou da permissão
dada acima, sinta-se à vontade para nos contatar em permissions@oreilly.com .

As ferramentas usadas no código deste livro podem ser encontradas no apêndice, jun-
tamente com recursos para mais informações sobre os tópicos abordados. Para refe-
rência, as ferramentas usadas neste livro junto com suas versões são:

nó 6.7.0
npm 3.10.3
desejo 0.1.2
mocha 3.2.0
profundo igual a 1.0.1
testdouble 1.10.0
fita 4.6.3
lodash 4.17.2
afirmar 1.4.1
sublinhado 1.8.3
ramda 0.22.1
santuário 0.11.1

É improvável que as versões posteriores causem problemas, mas as anteriores po-

dem. Em versões inferiores, sabe-se que o nó em particular não suporta totalmente o
código neste livro.

O'Reilly Safari

O Safari (anteriormente Safari Books Online) é uma plataforma de treinamento e refe-

rência baseada em associação para empresas, governos, educadores e indivíduos.

Os membros têm acesso a milhares de livros, vídeos de treinamento, trilhas de apren-

dizado, tutoriais interativos e listas de reprodução selecionadas de mais de 250 edito-
ras, incluindo O'Reilly Media, Harvard Business Review, Prentice Hall Professional,
Addison-Wesley Professional, Microsoft Press, Sams, Que , Peachpit Press, Adobe, Fo-
cal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks,
Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bar-
tlett e Course Tecnologia, entre outros.

Para obter mais informações, visite http://oreilly.com/safari .

Como entrar em contato conosco

Envie comentários e perguntas sobre este livro à editora:

O'Reilly Media, Inc.

1005 Gravestein Highway North

Sebastopol, CA 95472

800-998-9938 (nos Estados Unidos ou Canadá)

707-829-0515 (internacional ou local)

707-829-0104 (fax)

Temos uma página web para este livro, onde listamos erratas, exemplos e qualquer
informação adicional. Você pode acessar esta página em http://bit.ly/refactoring-js_1e .

Para comentar ou fazer perguntas técnicas sobre este livro, envie um e-mail para
bookquestions@oreilly.com .

Para obter mais informações sobre nossos livros, cursos, conferências e notícias, con-
sulte nosso site em http://www.oreilly.com .

Encontre-nos no Facebook: http://facebook.com/oreilly

Siga-nos no Twitter: http://twitter.com/oreillymedia

Assista-nos no YouTube: http://www.youtube.com/oreillymedia

Agradecimentos

Agradeço à minha família pelo apoio na realização deste livro: mamãe, papai, Amy,
Scott, Gretchen, Max e Jade.
Agradecimentos especiais às pessoas que ajudaram a dar o pontapé inicial: Zeke Tem-
plin, Steve Souders, Mary Treseler, Simon St. Laurent e Tyler Ortman.

E para aqueles que deram inspiração técnica e feedback: Jacob Barss-Bailey, Matt
Blake, Charles Baakel, Stefano De Vuono e Ryan Duchin.

E o restante da equipe da O'Reilly que ajudou ao longo do caminho: Annalis Clint,

Nena Caviness, Michelle Gilliland, Rita Scordamalgia, Josh Garstka, Kristen Brown, Re-
becca Demarest, Rachel Monaghan, Shiny Kalapurakkel e especialmente meus edito-
res, Nan Barber e Ally MacDonald.

E aos meus revisores técnicos: Steve Suering, Shelley Powers, Chris Deely, Darrell He-
ath e Jade Applegate.

E para aqueles cujo trabalho achei útil e inspirador: William F. Opdyke, Martin Fo-
wler, Kent Beck, John Brant, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissi-
des, Douglas Crockford, Tony Hoare, Alexis Deveria, Addy Osmani, Robert Nystrom,
Brian Lonsdorf, Reginald Braithwaite, Miran Lipovaca, Kyle Simpson, Tom Stuart, Mi-
chael Fogus, David Chambers, Michael Hurley, Scott Sauyet, Yehuda Katz, Jay Fields,
Shane Harvie, Russ Olsen, Joshua Kerievsky, James Halliday, TJ Holowaychuk, Justin
Searls, Eric Elliot, Jake Archibald, Arnau Sanchez , Alex Chaffee, Eric Hodel, Sean
Hussey, Brian Cardarella, Foy Savas e Katrina Owen e Bryan Liles.

Um agradecimento especial ao Dr. Axel Rauschmayer por seu incrível trabalho inter-
pretando especificações para nós, meros mortais, além de fornecer o prefácio deste
livro.

P S S . . . E I , L E I TO R !

Eu sei que parece apenas uma grande lista de nomes, mas as pessoas nesta seção são realmente
incríveis. Os recursos no apêndice são menos importantes do que esta lista. Muitas dessas pes-
soas fizeram essas coisas. E pesquisar seus nomes permitirá que você saiba sobre suas coisas
novas, o que provavelmente é melhor do que suas coisas antigas. Olhe para essas pessoas.

E obrigado em geral a todas as pessoas da TC39 e MDN.

E ao meu cachorro por me levar para passear, mesmo quando eu estava no meio de
alguma coisa .
Para você também. Obrigado por apoiar o meu trabalho. Me chame se precisar de al-
guma coisa.

1
William Opdyke, “Refactoring Object-Oriented Frameworks” (tese de doutorado,
University of Illinois at Urbana-Champaign, 1992), 40.

Apoiar Sair

© 2022 O'REILLY MEDIA, INC.  TERMOS DE SERVIÇO POLÍTICA DE PRIVACIDADE