React: interpretando código legado

O que é código legado? - Apresentação

Apresentando o instrutor e o curso

Olá! Meu nome é Vinicios Neves e sou instrutor deste curso de React.

Audiodescrição: Vinicios é um homem branco, careca, com barba e veste uma camisa da Alura. Ele está em um estúdio com uma parede clara ao fundo.

Neste curso, abordaremos um tema diferente. Até agora, em nossa trajetória com React, temos escrito bastante código. No entanto, ao trabalharmos em uma empresa, nem sempre o código estará utilizando a versão mais recente, bonita, atualizada ou segura. Muitas vezes, precisamos lidar com o que chamamos de legado.

Explorando o conceito de legado

Neste curso, vamos entender o que é legado. Discutiremos a literatura, livros e definições sobre o tema. Em seguida, faremos um mergulho profundo no React. O que conseguimos observar nesse contexto? Vamos treinar nossa habilidade de ler código.

Vamos discutir sobre como era o cenário no passado e compará-lo com o que temos atualmente. Isso nos ajudará a aprender a lidar com tecnologias mais antigas e a desenvolver estratégias para criar bons legados no futuro. Se já estamos atualizados com o React, podemos acompanhar essa jornada, olhando para o passado e nos preparando para o futuro.

Desenvolvendo habilidades para lidar com software legado

Nosso objetivo é lidar de forma eficiente com software legado e também preparar bons legados para nosso futuro ou para nossos colegas de profissão. Vamos desenvolver técnicas de leitura de código e aprender a lidar com software legado de maneira exemplar.

Esperamos que todos estejam tão animados quanto nós para este curso, que é bastante diferente, onde faremos exercícios de leitura e interpretação. Estamos ansiosos para o próximo vídeo.

O que é código legado? - O que significa “legado”

Definindo software legado

Vamos discutir sobre software legado. Inicialmente, apresentamos uma definição de Michael Feathers, que descreve o termo "software legado" como uma gíria para identificar software que é difícil de alterar e que não compreendemos bem. Esse termo acabou se associando a software que não entendemos e que é complicado de modificar. No entanto, existem outras perspectivas.

Ian Sommerville oferece uma definição mais acadêmica, afirmando que sistemas legados são mais antigos e baseados em linguagens e tecnologias que não são mais utilizadas no desenvolvimento de novos sistemas. Percebem a diferença entre as duas definições? Feathers apresenta várias definições, e essa é apenas uma delas. Recomendo o livro dele para quem deseja se aprofundar mais no assunto. Ele destaca o viés de software difícil de manter e entender, enquanto Sommerville define como software antigo, construído com tecnologias que não usaríamos mais para desenvolver um novo software atualmente.

Compreendendo a natureza do software legado

O que podemos dizer sobre software legado? Software legado é um código escrito no passado que continua funcionando, mas não é mais como faríamos hoje. É importante entender que, ao falarmos de software legado, não estamos atribuindo uma conotação negativa. Trata-se simplesmente de algo que já existia há mais tempo. Quando lidamos com esse tipo de software, devemos exercitar a empatia e nos transportar para a época em que ele foi escrito, considerando as condições e limitações daquela época. São muitas variáveis diferentes que devemos considerar.

Podemos pensar nisso como a construção de uma casa antiga. Imagine uma casa construída com tecnologia antiga, usando pedra e teto de palha, por exemplo. Apesar de ser antiga, ela ainda é habitável.

Comparando software legado com construções antigas

Ela está conservada e bem preservada. Apesar de ter sido feita com tecnologia antiga, ainda é habitável. É mais ou menos isso que falamos sobre software legado. Qual é o ponto principal aqui? Se fôssemos construir essa casa hoje, ela seria assim? Ou teria um estilo mais moderno? Não vou definir "moderno" entre aspas, pois não entendo de arquitetura, mas, aos meus olhos, seria uma casa mais moderna, com tecnologia atual, muito vidro e iluminação.

O software tem seu ciclo natural. A tecnologia está sempre evoluindo. O que era moderno ontem, hoje já é legado. O que é moderno hoje, se tornará legado amanhã. Por que estamos discutindo software legado se nosso foco é o React? Vamos falar sobre o React. Ele foi lançado em 2013 e, desde então, inúmeras versões foram lançadas. A cada versão, surgem novas formas de escrever código, modificações e funcionalidades. Coisas que antes eram de um jeito passaram a ser de outro. Precisamos estar atentos a isso.

Explorando a relevância do software legado no contexto do React

Você pode estar se perguntando: "Estamos estudando o React na versão 19. Por que me preocupar com software legado e versões antigas do React?" Vamos explorar isso ao longo do curso, mas já adianto alguns pontos. Quando estamos aprendendo uma tecnologia nova, provavelmente estamos na versão mais recente ou em uma versão próxima. Na carreira de React, estudamos a versão 19. No entanto, ao trabalhar, talvez não seja essa a versão utilizada. É provável que seja uma versão mais antiga, com uma base de código existente, o que pode facilitar ou dificultar a atualização da biblioteca.

Aprendendo a lidar com software legado

Vamos aprender sobre esses conceitos de software, pois somos todas pessoas desenvolvedoras de software. Vamos entender conceitos importantes para o dia a dia e boas práticas para lidar com legados ou deixar um bom legado para futuras pessoas desenvolvedoras que trabalharão no software que estamos desenvolvendo agora.

Software legado não é algo ruim. É algo feito anteriormente com a tecnologia disponível na época. Se fosse feito hoje, provavelmente seria diferente. Essa é a definição do nosso legado. Agora que entendemos o panorama geral do software legado, vamos mergulhar especificamente nos legados em React. Há muito para discutirmos e trocarmos ideias. Nos vemos no próximo vídeo.

O que é código legado? - Por que existe legado no React

Discutindo o React em software legado

Como este é nosso último encontro, vamos falar sobre React dentro do conceito de software legado. A primeira coisa que trouxemos é como o React se parecia em 2013. A forma de definir um componente era bem diferente. O JSX já estava presente, então essa parte era semelhante, mas havia diferenças. Fazíamos o import do React, e provavelmente era um require daquela época. Utilizávamos o createClass, ou seja, tínhamos um construtor e passávamos para esse createClass um objeto com várias configurações. Uma dessas configurações era uma função chamada render, que retornava o JSX. Isso é bem diferente do que fazemos hoje.

Para ilustrar, veja como era um componente simples naquela época:

// React 0.x
var Hello = React.createClass({
  render: function() {
    return <h1>Hello World</h1>;
  }
});

Evoluindo para componentes baseados em classes

Essa abordagem evoluiu para a orientação a objetos. Em vez de usar o createClass, criávamos uma classe JavaScript que estendia o comportamento de React.Component. Implementávamos o que era necessário diretamente na classe, com nossa função render.

Aqui está um exemplo de como isso era feito nas versões 15 e 16 do React:

// React 15/16
class Hello extends React.Component {
    render() {
        return <h1>Hello World</h1>;
    }
}

Quando tínhamos esse tipo de componente baseado em classes, o ciclo de vida era diferente. Hoje, provavelmente usamos o useEffect para resolver muitos problemas, mas antigamente não era assim. Existiam métodos específicos, como um método chamado antes de ser renderizado, quando as props eram modificadas, ou antes de atualizar o elemento no virtual DOM e, consecutivamente, no DOM. O ciclo de vida dos componentes era todo baseado em métodos de uma classe, seguindo a orientação a objetos.

Veja um exemplo de como esses métodos de ciclo de vida eram utilizados:

class Counter extends React.Component {
    componentWillMount() {
        /* antes do render */
    }
    componentWillReceiveProps(nextProps) {
        /* props novas */
    }
    componentWillUpdate() {
        /* antes de atualizar */
    }
}

Introduzindo hooks no React

Com a introdução dos hooks, isso mudou. Passamos a ter recursos como o useEffect, que mencionamos anteriormente, para gerar efeitos colaterais. Temos o useState para gerir estado. Antes, a gestão de estado era completamente diferente, toda baseada em uma propriedade local da classe.

Aqui está um exemplo de como um componente funcional com hooks pode ser implementado:

// React 16.8
function Counter() {
    const [count, setCount] = React.useState(0);

    React.useEffect(() => {
        console.log("montou ou atualizou");
    }, [count]);

    const handleClick = () => {
        setCount(count + 1);
    };

    return (
        <button onClick={handleClick}>
            {count}
        </button>
    );
}

Refletindo sobre a evolução do React

Observamos que a tecnologia evolui naturalmente. Lembramos daquele conceito de legado, aquele software antigo que, se fôssemos construir hoje, seria diferente. É exatamente sobre isso que falamos. Será que hoje, se começarmos um projeto em React, vamos usar o class component? Muito provavelmente não. O React está sempre evoluindo, e isso não é exclusividade do React. O software, como um todo, está sempre evoluindo.

Inclusive, o React 19 trouxe novidades interessantes. Agora, conseguimos capturar uma action de um formulário e obter os dados do formData. Antes, não era assim. Precisávamos capturar o evento de submit para evitar o recarregamento da página e, então, adotar várias estratégias para lidar com isso.

Veja como isso pode ser feito agora:

// React 19
function Form() {
    async function action(formData) {
        console.log(formData.get("name"));
    }
    
    return (
        <form onSubmit={(e) => { e.preventDefault(); action(new FormData(e.target)); }}>
            <input name="name" />
            <button type="submit">Enviar</button>
        </form>
    );
}

Concluindo com a importância da evolução contínua

Por que mencionamos tudo isso? As versões do React estão sempre sendo lançadas, sempre trazendo novidades. Uma característica muito interessante do time do React é que eles tentam fazer isso da forma menos dolorosa possível para nós, pessoas desenvolvedoras, para que possamos manter nossos projetos atualizados sem muita dificuldade.

O mais importante que devemos entender é que a evolução é natural. O ciclo de evolução do software é natural. Precisamos tomar cuidado com a forma como escrevemos e lidamos com as coisas.

Antes de começarmos a ver o código mais de perto, vamos abordar o que chamamos de Code Smells (códigos com problemas). São aspectos que conseguimos perceber no código e que já nos fazem identificar que algo parece um legado, que talvez não seja uma boa estratégia mexer ou lidar com ele da forma usual.

No nosso próximo encontro, vamos falar justamente sobre isso: como identificar esses primeiros sinais de código legado. Nos vemos lá.

Sobre o curso React: interpretando código legado

O curso React: interpretando código legado possui 75 minutos de vídeos, em um total de 35 atividades. Gostou? Conheça nossos outros cursos de React em Front-end, ou leia nossos artigos de Front-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• O que é código legado?
• Como o react começou?
• Padrões e ferramentas que mudaram
• Outras libs e formas de trabalhar
• Como lidar com software legado?