React JS e metodologias ágeis: Primeiras impressões

Teógenes Moura
Nov 10 · 8 min read
Image for post
Image for post

Oi pessoal, tudo bem? Me chamo Teógenes Moura (Teo) e sou desenvolvedor de front-end no Laboratório Hacker da Câmara dos Deputados. Neste texto, vou fazer extensão a uma história que começamos a contar algum tempo atrás, com o texto LABootcamp: dicas para aprender ReactJS, escrito pelo João Paulo, que também é do time de front-end aqui no LAB. Desta vez, farei um apanhado geral dos pontos positivos, desafios e aprendizados obtidos durante o projeto Linguagem Simples — que depois de ganhar uma certa maturidade institucional passou a se chamar “Plenário Fácil” — em relação ao uso da ferramenta ReactJS e do SCRUM, metodologia ágil possível de ser utilizada no desenvolvimento de software (falamos sobre a implementação dela no LABHacker aqui nesta publicação).

Para os que não são familiarizados com o mundo do desenvolvimento, o React permite a elaboração de interfaces de usuário complexas, compostas por várias pequenas partes que se relacionam com o todo. Na imagem abaixo, por exemplo, temos a interface do Facebook dividida em vários componentes “pequenininhos”: o componente de stories que, por sua vez, é formado pelos stories individuais; o componente dos posts, formado pelas postagens individuais; o componente de cada post individual, formado por título, imagem de perfil, texto e anexo de mídia; e assim por diante. Em oposição a paradigmas de desenvolvimento anteriores — como o desenvolvimento puro em Javascript e CSS — , o React nos permite controlar cada um desses pequenos componentes de modo isolado. Desta maneira, conseguimos construir a aplicação toda a partir de várias peças de quebra-cabeça que se encaixam perfeitamente umas nas outras.

Image for post
Image for post

Aqueles que acompanham o trabalho do LAB provavelmente estranharão o título deste texto. Como assim “Primeiras impressões”? Vocês já utilizaram o ReactJS no projeto Dashboard da participação! E é verdade. De fato, o primeiro uso da biblioteca num projeto do Laboratório foi com esta ferramenta. No entanto, ele demandava funcionalidades razoavelmente simples, e que não nos levavam a compreender, efetivamente, o poderio completo do arsenal provido pelo ReactJS.

No projeto Plenário Fácil, no entanto, nos deparamos com um cenário mais complexo. Sendo uma das ideias derivadas a partir do evento Nós do LAB, ele tenta resolver um dos problemas levantados por vários setores da sociedade: é difícil entender o que acontece no dia a dia da Câmara. Portanto, precisamos simplificar a linguagem utilizada pela instituição para que a sociedade possa compreender, de forma clara e objetiva, o que acontece no cotidiano da Casa e dos parlamentares, com ênfase especial no plenário, onde são discutidos os projetos de lei.

Image for post
Image for post
Créditos da imagem: Câmara dos Deputados

A solução idealizada pelo Lab é composta de duas partes. A primeira será uma linha do tempo dos eventos que ocorrem no plenário a ser colocada no Portal da Câmara, permitindo ao cidadão acompanhar, em uma interface simples e intuitiva, os acontecimentos. Essa parte será implementada pelo setor de tecnologia da Casa, a DITEC e, portanto, não a abordaremos em profundidade neste texto. A segunda parte, que é o nosso foco, é o painel que será utilizado pelas(os) jornalistas responsáveis por alimentar a plataforma. Por meio dele — e seguindo a técnica da Linguagem Simples — a comunicação da Câmara dos Deputados será capaz de passar conteúdos relevantes aos cidadãos, como imagens, links para notícias, tweets incorporados etc, disponibilizando-os diretamente na linha do tempo de uma determinada sessão. A imagem abaixo é um protótipo visual do dashboard:

Image for post
Image for post

O dashboard é composto por duas sessões principais: a Linha do tempo e Conteúdos; e ambas são formadas por vários componentes internos com suas respectivas funcionalidades, que podem, ou não, depender uns dos outros. Por exemplo, o feed de posts (na parte inferior da linha do tempo) depende necessariamente da caixa de nova atualização — um novo post só é feito caso seja introduzido primeiro nesta opção de entrada. Ao mesmo tempo, uma outra mudança pode estar sendo feita em outro ponto da aplicação sem que haja interferências — outros desenvolvedores podem implementar funcionalidades novas na parte de Conteúdos, por exemplo. Então, o primeiro ponto positivo, que é interessante de ser destacado, é que o React nos permite manipular o estado de cada pequeno componente independentemente e de forma organizada. Por isso, a equipe de front foi capaz de desenvolver duas partes distintas da plataforma de maneira praticamente autônoma, sem que ocorressem dependências que pudessem travar o desenvolvimento.

Outro ponto positivo que nos ajudou bastante foi a vastidão de recursos em torno da ferramenta: a comunidade de desenvolvedores disponibiliza, de forma aberta, vários dos componentes que pudemos incorporar no nosso software para agilizar o desenvolvimento. Por exemplo, para incorporar tweets, nós utilizamos o react-twitter-embed, disponível neste link. Além disso, uma das bibliotecas abertas a qual recorremos e que facilitou muito o desenvolvimento da parte visual foi o Material UI para o React, que implementa, em componentes React, os padrões de design estabelecidos pelo Material UI, desenvolvido originalmente pelo Google.

Um dos desafios que ocorreram durante o desenvolvimento do Plenário Fácil foi o aumento na complexidade em relação ao projeto mencionado anteriormente, o Dashboard da participação. Nele, tínhamos vários componentes separados mas que exerciam funções razoavelmente simples — como buscar dados em uma API (interface de programação) e apresentá-los, de forma visual, para o usuário. Em oposição, o componente da linha do tempo, por exemplo, possui múltiplos estados que são interdependentes: a caixa de texto “Nova atualização” altera — por baixo dos panos — o mesmo componente que as caixas de texto que aparecem ao clicar nos botões de inserir imagem, tweet ou link.

Image for post
Image for post
Modal para inserção de imagem acompanhada por possível texto

Essa foi uma decisão cujo intuito era diminuir a repetição de código e manter o princípio de uma única “fonte da verdade” para os dados que transitam entre os diversos componentes da aplicação. Isso nos permitiu ter apenas uma rotina, por exemplo, para fazer o que chamamos de garbage collection (coleta de lixo), em que limpamos os dados que não serão mais utilizados da memória do computador, liberando espaço e prevenindo possíveis falhas futuras.

Contudo, manusear todas as mudanças de estado de cada componente tem suas consequências: o que acontece quando um usuário sobe uma imagem e se arrepende? Como deve responder o texto escrito até então? Deve ser apagado ou continuar guardado caso o usuário queira continuar editando? Além das alterações de requisitos naturais que acontecem durante o processo, o projeto forçou-nos a passar por uma transformação significativa na implementação: o que antes eram vários componentes separados entre si (uma modal para imagem, outra para tweet, outra para texto e assim por diante) e razoavelmente horizontais em hierarquia viraram apenas duas modais, uma para inserção de links (independente de ser do Twitter ou não) e uma para pré-visualização do que viria a ser colocado na linha do tempo.

Image for post
Image for post
Pré-visualização de post com tweet incluído

Essa mudança, além de todas as alterações de lógica envolvidas, trouxe ainda outro desafio: os testes. Como já havia colocado ao time antes, minha experiência com testes era pequena, pois minhas vivências anteriores não haviam requerido esse conhecimento. Para este projeto, aprendi, então, vários tipos de testes e como implementá-los; desde os puramente visuais (como o teste de snapshot), até mais complexos de funcionalidade, como simular a abertura de uma modal, inserir informações e esperar que o software funcione como esperado. Esta parte gerou um estudo considerável que, com certeza, ajudará bastante em propostas futuras.

A adaptação à metodologia ágil também foi algo que puxou bastante energia, já que impacta diretamente na rotina por conta das reuniões diárias e, eventualmente, o cargo de scrum master — que por motivos práticos acabou sendo desempenhado rotativamente pelos próprios desenvolvedores. Além disso, há a parte técnica, com implementação de estórias de usuário (User stories) e estórias técnicas (Technical stories), seguindo critérios específicos de aceitação, desde o modo de escrita até, o mais importante, modelo de fluxo de trabalho no Github — seguindo a política de commits delimitada no começo do projeto e disponível na wiki do nosso repositório de backend neste link.

Considero, então, que o projeto Plenário Fácil foi bastante intenso em pelo menos três frentes distintas. A primeira, com o aprendizado sobre o ReactJS e suas partes mais complexas, em termos de saber manusear o estado de cada componente de forma adequada para que não gere erros e que possa ser reutilizado por outros desenvolvedores. A segunda, que lida com os critérios de aceitação: sair praticamente do zero para conseguir implementar os testes necessários para não abaixar a cobertura de testagens do repositório como um todo — o que acabou acontecendo, de fato, uma vez, negociada com os gerentes do projeto. E a terceira, por fim, a adaptação à própria metodologia ágil e o que ela implica; tanto no aprendizado de gestão do tempo, quanto da relação dela no fluxo de incorporação de código ao repositório no Github.

O projeto passou por várias fases importantes para que pudéssemos chegar ao ponto de escrever este texto. O começo, escutando ativamente as demandas do cidadão e transformando-as em protótipos visuais — devidamente testados com diversos usuários de todo o país. O meio, em que o modelo visual foi transformado em 12 semanas de desenvolvimento, o que demandou bastante criatividade das equipes de front-end e back-end (estes últimos demonstraram, na prática, que é possível hackear a burocracia inerente a organismos grandes com criatividade). E então o aprendizado sobre como operar a parte de tecnologia de um laboratório de inovação no Legislativo, gerando um fluxo de trabalho bem estruturado, baseado em práticas reconhecidas e que passa por mudanças constantes de forma a garantir que está sendo realizado o melhor trabalho possível para o cliente mais importante de todos: você que está lendo esse texto! :)

Obrigado,

Teo

LABHacker

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store