Neste post gostaríamos de aprofundar o relato sobre nossa parceria com um de nossos clientes.
Como já dissemos trata-se de nossa experiência na entrega de um projeto que visou a re-construção de um produto existente.
Para outras informações sobre o cenário deste relato leia este post.

Entre os pilares da concepção do novo produto havia uma proposta inovadora de elementos de usabilidade e apelo visual. Durante a inception do projeto enxergamos na abordagem SPA uma resposta a esta necessidade. Como de costume, conversamos com o cliente sobre trade-offs tais como familiaridade com a tecnologia, disponibilidade de profissionais no mercado e produtividade.

Quais resultados foram conseguidos?

Apostamos em SPA e acreditamos ter feito a escolha certa. Esta abordagem viabilizou a existência de comportamentos de interface bastante sofisticados e complexos. Dentre as funcionalidades mais desafiadoras destacam-se:

• Interações que lembram um processo de checkout de Ecommerce, mas acredite, com uma riqueza de detalhes muito maior
• Questionários que se desenham conforme cada resposta é assinalada
• Interações que lembram um carrinho de compras de Ecommerce
• Editores de texto transparentemente integrados ao aplicativo

Além das features, cada cantinho do aplicativo traz o mesmo padrão de usabilidade que costuma encher os olhos do Product Owner e dos stakeholders do projeto.
As features evoluíram aos poucos, uma sprint de cada vez. Tratar JavaScript como “cidadão de primeiro nível” foi imprescindível para que todo o código envolvido não deteriorasse após algum tempo.
Com o decorrer do projeto nós desenvolvedores chegamos a uma velocidade constante dentro dos padrões desejados pelo cliente.

Passado um ano do início do desenvolvimento, algo em torno de 50% de toda base de código está escrito em CoffeeScript. Código modular, bem organizado e bem testado. Código que hoje está nas mãos dos desenvolvedores do cliente.  Desenvolvedores que ajudamos a encontrar no mercado e que são plenamente capazes de trabalhar com o ferramental em questão.

Mais detalhes sobre a solução

A seguir anexamos prints de algumas telas para ilustrar o que é a aplicação em questão. As telas foram “ofuscadas” para manter a confidenciabilidade do produto.

Daqui em diante vamos aprofundar os aspectos técnicos existentes e como implementamos a arquitetura escolhida. Um bom momento para enchermos nossa xícara de café.

É prazeroso falar sobre a tecnologia empregada nesta solução. Tiramos grande proveito da experiência e conhecimentos adquiridos em 2012.
Backbone.js, CoffeeScript, RequireJS e Jasmine foram mais uma vez protagonistas em nossa arquitetura de front-end.
Também aproveitamos ao máximo as ferramentas npm, bower e gulp.js. Npm e bower ajudaram a manter o controle das dezenas de dependências JavaScript, de bibliotecas até as próprias ferramentas de build, como os compiladores de Coffee e Less, o gulp e o próprio bower.
Conseguimos tocar o projeto por bastante tempo sem utilizar uma ferramenta de build JavaScript. Isto porque sobrecarregávamos o Gradle, nossa ferramenta de build Java. Quando conhecemos o gulp.js decidimos fazer uma aposta e não olhamos mais para trás.

Como já foi dito, apostar em SPA significa tratar JavaScript como “cidadão de primeiro nível”.
Atualmente a base de código do front-end possui mais de 200 arquivos coffee e 100 templates html. Metade do código coffee é representada por Views.
Mais de 800 testes de unidade foram escritos com ajuda da prática de TDD. Algo em torno de 50 testes de aceitação também foram escritos e assim temos uma suíte de regressão que manteve o índice de bugs sempre baixo e também deu o respaldo necessário para que boa parte do código fosse revista frequentemente.

Assim como no backend, a grande receita desta base de código, a grosso modo,  é manter uma alta coesão e um baixo acomplamento.
Juntos Backbone e RequireJS  oferecem boa parte dos ingredientes para esta receita. Mas é importante observar que por ser minimalista o Backbone deixa a gente na mão em alguns aspectos. É  aí que entram os seus plugins. Por isto  desta vez também investimos pesado no Marionette, que correspondeu plenamente a nossas expectativas de escrever menos código “boilerplate”.
Além do Marionette também adotamos e recomendamos: Stickit, Backbone.Validation e Backbone-associations. Utilizamos também alguns outros plugins que resolvem problemas mais pontuais.
Com o uso destes plugins muito código deixa de precisar ser escrito. Além disso boa parte do código remanescente é declarativa, o que favorece muito a sua manutenção.

Ainda falando sobre a base de código, dois padrões de projeto centrais em nossa arquitetura emergiram durantes os primeiros meses de trabalho: Mediator e Event Aggregator.
Estes padrões fazem sentido a partir do momento em que muitos objetos de View precisam colaborar entre si ao implementar uma interface sofisticada.

Outro ingrediente importante nesta solução foi o template engine Handlebars, que ajuda a manter a produtividade na escrita das Views. Com o decorrer do projeto o time entendeu que comportamentos de renderização devem ficar no Handlebars. Quando os comportamentos são complexos, sobretudo ao envolver interações com o usuário, tomamos o cuidado de não deixar a renderização de uma interface inteira em um único template. Assim o código JavaScript fica melhor organizado: diversos objetos de View compõem a inteligência da interface e cada objeto delega a renderização para um template com poucas linhas de código.

Existem muitos detalhes que fazem esta arquitetura de front-end muito interessante, especialmente para quem ainda não possui experiência com este tipo de abordagem.
Sinta-se convidado a tirar dúvidas e trocar experiência com a gente, os comentários estão aí para isto.

Este foi mais um post relatando a experiência de nossa parceria com a Lumera. Ainda existe bastante conteúdo por vir!

Rafa Noronha

Rafa Noronha gosta de construir aplicações web inovadoras em qualquer plataforma. Possui experiência em diversas tecnologias mas a única com quem rolou algo mais sério foi a Web. Nos últimos anos precisou se especializar em JavaScript, single-page apps e Backbone.js. Na Lambda3 Rafa Noronha jura que Java é legal e está sempre vencendo seus colegas nos confrontos de Mortal Kombat e FIFA14.