Como é ser um engenheiro front-end na EmCasa?

Cesar De Carvalho Boaventura
EmCasa
Published in
5 min readDec 8, 2021
Photo by Nicole Wolf on Unsplash

Nosso dia-a-dia

Na EmCasa, seguimos a metodologia Shape Up e a nossa rotina é bastante prática: temos cerimônias e ciclos de desenvolvimento, implementamos novas features e aprimoramos nosso produto.

Nossos planejamentos, tarefas, discussões e documentações ficam armazenadas no Notion, pois essa ferramenta fornece uma infinidade de recursos para nos organizarmos.

Usamos o Github para armazenar os nossos repositórios, criar as Pull Requests, fazer as revisões de código, e, consequentemente, fazer o deploy 🎉. O deploy acontece por meio do CircleCI, onde temos a opção de subir as alterações em staging (ambiente de testes) ou em produção. Ambos os ambientes estão na AWS.

Uma vez por semana temos um meetup interno de engenharia, onde levamos uma pauta de assuntos para serem discutidos ou até mesmo tech talks. É daqui que surgem muitos pontos iniciais de melhorias, não só técnicas, mas também sobre como podemos melhorar a experiência de todos os devs no dia a dia.

A stack da EmCasa

Visando as tecnologias atuais do mercado e o poder que elas têm dentro da comunidade, como também a nossa constante evolução, na EmCasa temos a seguinte stack de front-end:

ferramentas
  • React: Utilizamos essa biblioteca para criar nossa interface através de componentes, sejam de baixa ou alta complexidade;
  • Typescript: Linguagem/sistema de tipagem (entenda como preferir) que usamos para escrever nosso código. (estamos migrando aos poucos);
  • SSR (Server Side Rendering): Basicamente, é a renderização de páginas no lado do servidor. Isso nos ajuda a proporcionar uma melhor experiência para o usuário, tendo em vista que ele vai ver a página totalmente carregada, e até mesmo em questões de SEO. O nosso sistema de SSR foi desenvolvido internamente usando o Express, framework para o NodeJS . Logo, não usamos nenhuma ferramenta externa para isso;
  • Apollo Client: Pelo fato de usarmos GraphQL, precisamos de uma ferramenta que nos auxilie no consumo do lado do front-end. É aí que o Apollo entra: nos ajudando a consumir nossas APIs e até mesmo indo além, como por exemplo, fornecendo uma sistema de cache para as requisições, aumentando ainda mais a performance das nossas plataformas;
  • Redux (com Saga) : Utilizamos essa ferramenta para gerenciar o estado global da nossa aplicação. No geral, não fazemos muito uso do Redux, mas ele está lá para quando for necessário;
  • Storybook: Usamos essa biblioteca para auxiliar no processo de documentação dos nossos componentes;
  • Jest e React Testing Library: Utilitários para escrever e rodar os testes unitários da nossa aplicação.

Nosso foco atual

A EmCasa é uma startup em expansão no setor imobiliário, logo, nosso time de tecnologia está crescendo bastante, assim como nossas aplicações. Visando garantir alta qualidade e resiliência, passamos a atacar alguns pontos cruciais nos últimos meses:

Criamos uma suíte de testes

Testes, no geral, não vão garantir que sua aplicação estará livre de bugs, mas com certeza vão diminuir bastante essa possibilidade. Também vão assegurar que outras pessoas não quebrem determinada parte do código, por conta de alguma alteração, seja indevida ou não.

Optamos por utilizar a React Testing Library, criada pelo Kent C. Dodds (esse cara é bom 🤓) e mantida pela comunidade. Essa biblioteca nos ajuda a testar os componentes React de uma forma fácil e prática, nos forçando a simular um comportamento muito próximo ao de um usuário interagindo com nossa aplicação, o que agrega muita assertividade e valor aos nossos testes.

Implementamos Typescript no projeto

O Typescript nos ajuda a diminuir bugs em runtime e acaba servindo como auto-documentação de trechos do código. Por exemplo: podemos entender quais são os tipos de cada prop que um componente espera receber; ou documentar cada campo que podemos obter na response de uma API. Isso tudo auxilia no entendimento de alguém que nunca mexeu em determinada parte da aplicação.

Estamos planejando um Design System

Com o crescimento do produto, novas telas e novos componentes surgem, nos forçando a pensar em uma maneira de organizar um conjunto cada vez mais de elementos. O Design System surge com o propósito de mantermos um padrão de estilo e de código, que nos auxilia para criarmos interfaces de usuário mais agradáveis e funcionais. Facilitando tanto a vida dos desenvolvedores, quanto a dos designers.

E os nossos próximos passos na EmCasa?

Nosso principal objetivo futuro é assegurar que nossos sistemas continuem evoluindo com qualidade e resiliência. Questões como crescimento de repositórios, templates modulares, padrões e melhores práticas, performance, documentações, entre outros, são temas que já mapeados e discutidos internamente.

Aqui na EmCasa, valorizamos muito o trabalho em equipe, por isso tomamos todas as decisões em conjunto. Logo, tudo o que pensamos e fizemos até então foi discutido com a maior quantidade de pessoas possível.

Um outro ponto que estamos aprimorando, é a nossa maneira de documentar o que for preciso para que outras pessoas possam entender partes mais complexas e/ou específicas da aplicação, boas práticas de desenvolvimento e detalhes de como uma nova feature foi implementada. Tudo isso que estamos fazendo está documentado, ou, pelo menos, temos planos para isso acontecer.

Quer ser um engenheiro front-end na EmCasa?

Nosso time de tecnologia está crescendo, e, por essa razão, temos diversas vagas em aberto. Você pode conferi-las em nosso LinkedIn.

Buscamos devs e devas que estejam motivados a participar e contribuir com todo esse cenário de crescimento, trazendo novas ideias para crescermos juntos.

Se você quiser entender um pouquinho mais sobre nosso time, dê uma conferida em outro artigo: Por que você deveria fazer parte do time de produto da EmCasa?.

--

--