Coordenar junto ao time de tecnologia a escolha de ferramentas na estratégia da empresa para orientar que essa decisão seja sensata, é uma delas.

O mundo Front-end é o mais cruel, a cada dois ou três anos você praticamente precisa se programar pra reescrever tudo, sempre!

Como escolher corretamente para a organização?

Entre os fatores que preciso orientar, estão: facilidade de contratação (oferta abundante de bons profissionais), produtividade na tecnologia (quantidade de materiais, tutoriais e libs), evolução da plataforma (qualidade do ecossistema).

Como o Front-end é extremament volátil, quando você começa a decidir qual plataforma será utilizada para a próxima meia década já está pelo menos um ano atrasado no mundo corporativo que é mais lento pelo próprio tamanho das empresas.

Foco na entrega

Dado um entregável em um intervalo de tempo e o planejamento de sua sustentação com seguida evolução, preciso estabelecer dados para me guiar nessa escolha.

Alguns indicadores famosos no mercado Javascript como State of Js, The State of Developer Ecosystem (da Jetbrains) e Developer Surveys (da Stackoverflow) determinam que praticamente os 3 maiores na preferência e uso são Angular, React e Vuejs.

Coletando informações do Google Trends para essas 3 libs, temos:

Observo ainda uma constante busca na contínua preferência para o React que grandes players mundiais usam como o grupo Facebook (Facebook, Instagram e WhatsApp), AirBnb, Netflix, Twitter, Walmart (USA), etc.

Tendências do mercado local

Vuejs parece ter um crescimento maior no Br do que no resto do mundo, apesar de menor em relação aos outros dois concorrentes, tem uma lista de empresas que utilizam por aqui que você pode acompanhar nessa conta do Github.

Não conferi a acurácia, mas a primeira grande empresa da lista que peguei pra conferir (O Boticário) não está em produção condizente com a lista.

Grandes Players no Brasil?

Um ecossistema moderno requer SPA e Server Side Renderer. Um grande Player na gritante maioria das vezes precisa integrar ferramentas internas e produtos de terceiros, espere poucos que serão homogêneos.

Filtrando pelos maiores varejistas generalistas para estabelecer um grupo de controle nessas condições, temos Magazine Luiza, B2W (Americanas e Submarino), Mercado Livre, Carrefour e Walmart. Deixei o grupo Via Varejo de fora (Casas Bahia, Ponto Frio e Extra.com) dessa análise rápida.

Existe também uma lista de empresas que usam React mantido pela comunidade de desenvolvedores nessa conta do Github.

Carrefour e Walmart Brasil não parecem ter algum desses 3 escolhidos, a não ser que seja apenas no SSR, não consegui identificar (foi muito superficial a análise). Magazine, B2W e Mercado Livre escolheram React seguindo essa tendência mundial e local.

Aqui não entrei no juízo de valores sobre o que é feito em casa ou de terceiros, afinal a contratação será de profissionais que entendam a tecnologia para construir ou no mínimo para integrar.

Siga o Mestre e Apelo a autoridade

Não se trata de falácia ao observar tendências, mas elementos óbvios que se o mercado onde você atua tem uma maior gama de profissionais em uma dada tecnologia, terá mais gente treinada disponível para contratação que por consequência deve impor um mercado de treinamento junto. Além de utilização de bibliotecas em comum que estarão mais maduras.

Se um número isolado fosse determinante, todo mundo seguiria com Angular por ter mais tempo e o que tem mais profissionais no mercado, é o cruzamento das informações.

Nesse contexto React tem uma maior procura e está na estratégia de um grupo considerável de grandes Players.

Desenvolvimento profissional

Nessa escolha alguns fatores sobre dados absolutos podem não fazer sentido, exemplo: “o sistema atual é em Angular e todos os profissionais são proeficientes nessa tecnologia”.

Contexto é tudo, dado o planejamento a médio e longo prazo, sai mais barato treinar todo mundo numa plataforma que faça sentido do que manter o Status Quo porque um número isolado indica um caminho cômodo.

Alguns profissionais podem não se adaptarem

Decisões racionais são necessárias pra empresa, não necessariamente para os profissionais, não vejo problema algum em um profissional se fixar em uma única tecnologia e determinar esse caminho pra sua carreira.

Como gestor você tem que saber que independente da escolha que fará, poderá perder alguns desses profissionais.

Como profissional você pode considerar conhecer e ser treinado na maior quantidade possível de ecossistemas que são tendências, sua expertise será aprimorada, mas como falei, vai da intenção de cada um.

Então, não devo experimentar Vuejs?

A análise que fiz no final de 2017 para o ano de 2018 ainda segue muito válida.

React e Vuejs seguem diretrizes, princípios e valores muito próximos, o que os difere é na forma em pequenos detalhes. Se a estratégia de evolução contemplar um pensamento em Microfrontends e padrões que sigam a integração entre ambos, manter um time polivalente pode render uma inovação frente aos concorrentes e uma oportunidade de investir em uma frente caso a outra entre em obsolescência.

Mas o experimento de abrir o ambiente a várias tecnologias também trás o risco de pulverizar esforço. O Tradeoff aqui requer uma dose de coragem além da experiência.

E o tl;dr?

Em um grande resumo disso tudo é, o mercado tende a continuar investindo em React, se você tem gente experiente o suficiente, vale a pena abrir mais de uma trincheira. Mas como conselho geral, treine seu time, fortaleça e construa uma arquitetura sólida primeiro em React.

Pra finalizar eu creio que vale a pena rever (se ainda não viu) essa palestra curtinha que eu e a Kete fizemos no React Brazil 2017 sobre evolução de plataformas javascript.

O segredo das grandes companhias na Era Digital se resume a ser uma plataforma de tecnologia self-service que integra o físico e o online com produtos que satisfazem insights capturados no comportamento dos clientes.

Não existem mais empresas de serviços ou produtos

Não existem mais empresas de varejo, viagens, hotelaria, comidas, aluguel ou transporte.

Todas as compahias dessa nova era são empresas de tecnologias que entregam a melhor plataforma de varejo, viagens, hotelaria, comidas, aluguel ou transporte de forma transparente não importando qual canal o seu cliente acessa em busca do serviço ou produto.

Este é o momento do ponto de virada

O homem mais rico do Brasil, o bilionário Jorge Paulo Lemann, declarou no início de 2018 que era um dinossauro apavorado e acordou o mercado nacional de que a fórmula de atrair talentos, ter preços baixos e extrema eficiência na redução de custos não seriam mais suficientes.

O mundo plano dos negócios ainda entende essa fórmula como o modelo de atingir o sucesso mesmo enfrentando a mudança cultural tecnológica que chega pela concorrência.

Em um mundo de rápida inovação de produtos e diversos canais de vendas o diferencial é trazer a visão do consumidor para frente do negócio e entregar a melhor experiência Self-service.

Permita seu cliente não precisar de você

Antigamente você construía um serviço apoiado por tecnologias, agora você constrói tecnologias que entregam serviços.

As diretorias tradicionais sempre conduziram tecnologia como suporte de operações ou Core em apenas determinado ponto estratégico da empresa, isso está superado, as empresas não tem mais essa opção.

Não tem opção de não serem empresas de tecnologia.

Você não pede comida falando com pessoas.

Você dá bom dia ou boa tarde por educação enquanto os carros não são ainda autoguiados quando pede um serviço particular de transporte.

Você se hospeda em uma residência particular sem precisar interagir com o proprietário e aluga um imóvel sem pisar em um cartório.

Ao mudar seu processo de entrega, transforma as pessoas

Você não muda as pessoas em uma transformação, você muda o processo para elas se adaptarem.

Para inverter o Mindset de criar serviços para apoiar operações precisamos automatizar todas as operações para as pessoas apoiarem as plataformas.

Não se cria processo baseado em pessoas, se cria em pessoas apoiando o processo.

Em vez de criar um processo baseado em serviços que pessoas executam, o processo automatizado precisa de pessoas na tomada final de decisão.

Além do fato das empresas tradicionais possuírem um legado que se apegam (como Mainframe) fragilizando a automação seja pelo preço ou na própria velocidade de entrega.

Olha como o Nubank nasceu com outra impressão digital, criou uma plataforma de auto-serviço pra seus clientes que desafoga a operação de atendimento.

Com um atendimento desafogado se torna muito mais humanizado, os atendentes podem ser especializados (porque diminui a vazão e pode contratar menos e melhor) que escrevem cartinhas de próprio punho aos clientes, além de resolver problemas no 1:1.

Empatia

Trazer a visão do consumidor pra frente num atendimento de auto-serviço torna os próprios funcionários nos maiores nos maiores influenciadores, quem se preocupa em atender bem e da melhor forma, cria empatia com todos os envolvidos.

Quem imaginaria que um dia amaríamos uma instituição financeira ao ponto de fazer Unboxing no youtube no recebimento do cartão?

3 Chaves da Transformação

Em resumo:

1. Trazer o cliente pra frente da missão, o segredo é como o atender automaticamente;
2. Criar plataformas modernas e ágeis guiadas por produtos que façam sentido pro sucesso do cliente;
3. Direcionar os produtos por dados.

No próximo Post (esse já ficou grande) vou falar sobre a estratégia de como fazer isso.

Qual o investimento?

Apenas 200 reais, que você pode se inscrever nesse link.

Quando vai ocorrer?

Acontecerá nos dias 15, 16, 17, 18 de maio de 2018 iniciando todos esses dias as 19h até as 21:00h. Dia 19 de maio de 2019 das 9h as 18h, com intervalo de 12 as 14h.

GMT-3 (Horário de Fortaleza-CE ou Mombaça, ex-capital do Brasil)

Formato online?

Utilizaremos o https://zoom.us/ para as aulas, os vídeos será disponibilizados para os inscritos após o curso.

Conteúdo

1. Experiência SPA e Content Centered
   1.1 Criar estrutura no Heroku para Server-side Rendering
   1.2 Setup e deploy com expressjs e Babel
   1.3 Criar estrutura de views com create-react-app
   1.4 Criar engine de template com react-dom/server no server side
   1.5 Exemplo de código isomorfico usando redux
   1.6 Criar estrutura de Hosting no Firebase para SPA
2. Mobile First e UX Design Patterns
   2.1 Conceptual model
   2.2 Complexion Reduction
   2.3 User Journey Simplification
   2.3.1 Linear User Flow com React Routes
   2.4 Progressive Disclosure
   2.5 Responsivo
   2.5.1 Responsive Logos
   2.5.2 Progressive Enhacement e Graceful degradation com Material Design
3. Offline First
   3.1 Criando estrutura de dados no IndexedDB
   3.2 Entendendo Service Workers, upgrade e migrate de versões
   3.3 Criando Sagas (Middleware redux) para funcionar offline e online
   3.4 Configurar https local pra validação
4. Web Instalável
   4.1 Manifest, tags e configurações
   4.2 Usando usuario anonimo com Firebase
   4.2.1 Aprendendo generators e redux-saga
   4.3 Vinculando usuario anonimo com login OAuth do Google
   4.4 Pedindo localização do usuário
   4.5 Integrando GMaps, Leaflet no App
   4.6 Acessando a câmera e salvando fotos
   4.7 Processos de sincronização e notificação com Web Workers
   4.8 Compartilhando itens com Web Share API
5. Integração Contínua sincrona com lightghouse-ci

tl;dr

Não existe uma fórmula pra isso, mas tem como trabalhar.

Disclaimer

Não existem dois times iguais simplesmente porque não existem dois seres humanos iguais, cada mudança de um membro você tem um time completamente diferente.

Portanto já saímos com o Mindset de que experiências passadas ou paralelas no máximo “ajudarão” a guiar o nosso instinto com tendências que deram certo ou errado.

Apelando para o bordão: “O todo é maior que a soma das partes”.

Desespero-me?

De maneira alguma, vamos aprender com a história, sobre o que deu certo e utilizar valores, princípios e práticas que garantam um monitoramento da saúde do coletivo e construa a cultura e motivação adequada a cada indivíduo.

Como eram os projetos de produtos de software nos anos 70/80

O formato que as equipes trabalhavam era a produção de um software seguindo um modelo tradicional de gerenciamento de projetos, uma equipe desenvolvia e outra recebia para manter.

O que se percebeu na época foi que esse modelo de “On-going” produzia diversos efeitos colaterais no produto final dado que o time que implementava não tinha o mesmo compromisso em qualidade de quem manteria pro resto do tempo em produção.

Além do fato de que projetos usavam times diferentes até na construção antes da ida pra produção, principalmente entre as fases de concepção e implementação.

Como a grande maioria dos projetos atrasavam e os testes ficavam como fase final, era comum serem relegados em prol da data de entrega.

Eram comuns também projetos demorarem 2 anos até serem colocados em produção, alguns levavam quase meia década (em off, eu trabalhei em um que levou uma década pra entrar em produção).

Fábula da galinho e do porco

Vários profissionais experientes estavam desenvolvendo um modelo alternativo no início dos anos 90 (alguns iniciaram até um pouco antes), trocando informações entre si e por volta do final da década você tem algumas metodologias e métodos bem definidos e maduros.

Em 2001 nasce o famoso Manifesto ágil, que seria o contrato de valores fundamentais que definia o comum que esses modelos traziam para resolver os problemas na construção de Software.

Em resumo, daqui pra frente a abordagem de pensar em produto em vez de projeto e um time que deveria ter o compromisso na qualidade e ciclo de vida deste produto foi algo que deveria permeiar entre eles.

Entre outras coisas, conceitos como trazer os testes pra frente, já sabemos que sempre vai atrasar algo, então que a qualidade não seja comprometida.

Ultimamente Deploy contínuo, colocar em produção desde o primeiro dia pra ir ajustando a arquitetura com ferramental, monitoramento e Status Check.

“Ultimamente” entre aspas duplas, isso já tem pelo menos uma década.

Quem falou primeiro em equipes multidisciplinares

Vários autores da era Agile estavam referenciando times multidisciplinares e desenvolvimento de produtos.

Você tem um claro viés da transição nessa época no tópico “Production Support Team” no livro do Kent Beck, chamado Planning Extreme Programming de 2000.

Trecho desse tópico:

Two or four programmers volunteer to focus on fixing bugs. Each programmer spends a couple of iterations in production support, then rotates back to development. Every iteration there is at least one devel- oper doing their first iteration and at least one doing the second. This works well in that there is a pair that has the responsibility for dealing with support issues and this (usually unpleasant) work is rotated around the team. Actually it’s not the rotation that is key, it is the fact that the team decides themselves how to handle it.

Em tradução livre:

Dois ou quatro (1) programadores voluntários para focar no conserto de bugs. Cada programador levaria um par de iterações no suporte em produção, então rotacionam (2) de volta ao desenvolvimento. Cada iteração tem pelo menos um dev fazendo sua primeira iteração e outro fazendo a sua segunda. Isso funciona bem quando um par tem a responsabilidade de lidar com questões de suporte e este (geralmente desagradável) trabalho é rotacionado em torno do time. Na verdade, não é a rotação que é a chave, é o fato de que o time decide por si só como lidar com isso.

(1) Observe que número par, pra trabalhar no princípio de Pair Programming do XP.

(2) XP tem algumas práticas como Move People Around pra todos no time trabalharem em praticamente todos os requisitos e tecnologias.

Projeto tem começo, meio e fim. Mas um produto de software por ser maleável e evolutivo se difere do produto clássico das literaturas anteriores, dificilmente você vai matar um legado e na minha experiência nem faz sentido.

Afinal se aquela folha de pagamento está funcionando em Cobol, não temos tempo e dinheiro suficiente que demande uma mudança em vez de trabalhar em prol de novas abordagens de negócio.

Modelo Squads e Guildas

Não poderia deixar de citar o Spotify que chamou a atenção ultimamente para seu modelo multidisciplinar em torno da abordagem de construção de produtos. Uma evolução do pensamento dessas últimas duas décadas no mínimo.

Um episódio bem leve e bacana sobre isso você escuta no Hipsters em seguida.

https://podtail.com/en/podcast/hipsters-ponto-tech/

Como selecionar o profissional certo?

Existem 3 tipos de profissionais quando falamos sobre evolução de uma produto em relação a tecnologia com times multidisciplinares:

1. Aqueles que por algum motivo se apegam a uma tecnologia e a defenderão com qualquer argumento para não haver mudança;
2. Aqueles que são Early Adopters e não querem trabalhar de forma alguma com legado;
3. Aqueles que entendem a necessidade e compromisso de ter que manter o legado, mas se sentem incomodados e gostariam de evoluir pra próxima tendência.

Existem Trade-offs nas 3 abordagens na minha experiência, na média desses profissionais você tem as seguintes características respectivamente:

1. São extremamente especialistas, conhecem a plataforma como ninguém e são mais aptos a solucionar problemas do presente, mas alimentam a ojeriza de qualquer mudança e até podem sabotar de forma inconsciente;
2. São especialistas em multi plataformas, estão preparados para o novo, mas contribuem pouco durante a evolução em relação a manutenção do legado, em contrapartida são os guiadores do processo de substituição;
3. São generalistas que podem atuar nas 11 posições (tomando analogia do futebol), não guiarão o processo de mudança, mas também não serão uma barreira de adoção.

Não quero “defecar” regra de qual tipo você deve dar atenção, acredito que é inevitável ter os 3 formatos no seu esquadrão, portanto é saber liderar e dosar o posicionamento correto de atuação entre os perfis.

Colocar o generalista ou o especialista do legado por exemplo pra puxar uma migração vai ser um tiro contra todos, vai conseguir desagradar a gregos e troianos.

Da mesma forma que colocar o Early Adopter pra manter legado e corrigir bugs vai só provocar ciúmes em quem ama a tecnologia e deveria ser o “dono”.

Mas claro, não são conselhos preditivos, existem graus entre os tipos e mais uma vez saber dosar requer um pouco de trabalho.

Além da diferença entre especialidade vs generalidade, você ainda enfrente a senioridade do profissional.

Efeito Sávio, Romário e Edmundo

A melhor seleção brasileira de futebol considerada pelos críticos foi a de 82/86 com craques do porte de Zico e Sócrates perdendo penalti.

Você tem vários experimentos que unir muitas estrelas com o ego inflado vai provocar mais danos na moral do time do que resultados, além do que você provavelmente tem o Budget apenas pra montar um time coeso e defensivo com um bom artilheiro na frente e ganhar o tetra.

Feedback e Cultura

Como citei antes, dificilmente você vai conseguir matar um legado inteiro, então ter um time que consiga atuar bem em torno dos objetivos do produto demanda cuidar da cultura e um processo de Feedback que consiga identificar que tipo de profissional trabalha com você e não confiar apenas no instinto na hora de delegar responsabilidades.

Muitas vezes você atribui que alguém está acomodado ou não gostaria de evoluir uma plataforma, mas a cultura do seu ambiente não privilegia ou piora o desenvolvimento pessoal.

Algumas vezes o sujeito só está na hora errada em relação as suas motivações pessoais ou no time errado para suas habilidades.

Mas não quero dizer que você não deve ter profissionais caros e bons, claro que precisa, só que não precisam e dificilmente serão todos ou ter que remontar o time inteiro (aqui existem dezenas de variáveis a se discutir).

É fácil?

De forma alguma, mas temos literatura suficiente já “antiga” pra utilizar.

Em resumo o formato que melhor funciona durante toda a história do desenvolvimento de software é um time multidisciplinar com multisenioridade construindo um produto com autonomia completa se preocupando com todas as práticas de engenharia em prol da entrega, mas pensando ciclicamente na evolução constante e qualidade total.

Então para montar esse time crie uma jornada interessante, convoque múltiplos perfis adequados para ela e os motive com o objetivo certo, que é construir um produto sem defeitos e que entregue valor adequado a quem tem o problema que ele se dispõe a resolver e está disposto a utilizar!

Se você vai trabalhar com React, vai se deparar com ele em algum momento. Chegam muitos testemunhos de que o React é fácil, mas o Redux ainda é um entrave.

Mudança de Mindset

Utilizar as melhores práticas com o Redux requer pensar de forma imutável e funcional com uma biblioteca e linguagem multi-paradigma, além disso a própria documentação do Redux não facilita, ela é pra quem já tem esse Mindset e confunde mais do que ajuda.

Vamos pensar apenas em React

Acredito que uma forma de entender um motor de estados é entender qual o problema que ele resolve primeiro, depois como ele funciona, para isso proponho nesse Workshop resolver essa compreensão puramente com React, lib da qual todo mundo me fala que entende fácil e é logo produtivo.

Workshop Construindo seu próprio Redux

Construiremos um Centralized State Management baseado no Pattern Flux fortemente inspirado no Redux. Pré-requisito é entender um pouco de React, mas nada que numa manhã não aprenda, de qualquer forma revisitaremos alguns conceitos de funcionamento da árvore.

Todo o código já está disponível caso queira se aventurar sozinho nesse repositório, só acompanhar os commits https://github.com/cmilfont/learn-redux/commits/master. Provavelmente eu inclua mais algum detalhe até lá, revisite sempre.

Qual o investimento?

Apenas 200 reais, que você pode se inscrever aqui nesse link. [no futuro teremos uma versão bitcoin ;)]

[update] O Workshop já aconteceu e você pode adquirir os vídeos das aulas comprando no link anterior, mas não temos mais canal no slack pra novos participantes dessa turma.

Quando vai ocorrer?

Primeira turma será nos dias 15, 16, 17 e 18 de janeiro de 2018 iniciando todos esses dias as 19h até por volta de 21:00.

Formato online?

Utilizaremos o https://zoom.us/ para as aulas, os vídeos será disponibilizados para os inscritos após o curso.

Conteúdo

1. Implementando acesso a dados no ciclo de vida da árvore React
2. Utilizando banco de dados locais (IndexedDB) como fonte de dados
3. Diferença entre props e state para manipular os dados
4. Refatorando a centralização do estado de uma árvore
5. Utilizando Context para conectar os componentes na árvore a uma mesma fonte
6. Construindo o seu Redux: Store como provider do estado.
7. Construindo o seu Redux: padronizando dispatch de ações.
8. Isolando os componentes com Containers conectados ao Store
9. Mapeando trechos do estado para as Views.

Próximos Workshops

Esse daqui servirá como pre-requisito a Workshops de Redux e Saga que serão disponibilizados em breve.

Linguagem

Javascript se tornou uma linguagem madura com um ecossistema rico de recursos auxiliares que a tornam presente no servidor, navegador e no seu celular.

Babel se tornou um padrão de fato para termos sempre as últimas novidades do JS, Typescript retornando com sucesso vencendo a concorrência contra o Flow e Webpack como Module Bundler tem aos poucos tornado obsoleto os anteriores (Grunt, Browserify e Gulp).

Indiferente da disputa histórica entre tipos dinâmicos e tipos estáticos, uma recomendação é sobre o pensamento imutável com Immutablejs.

Design Patterns

Domain Driven Design e outras coletâneas consagradas de padrões estão entrando na estante de livros do desenvolvedor Front agora com a maturidade do ecossistema e os Micro-frontends se tornando possíveis com algumas tecnologias como Import Async, seja utilizando o Webpack ou diretamente do Babel.

Sempre existiu uma grande necessidade do mercado em conservar código legado em vez de sempre reescrever tudo e agora a tecnologia nos permite uma evolução mais suave de como fazer isso.

Eu e a Kete Martins Rufino apresentamos “Transformando um front-end legado em uma React SPA” no ReactConfBR em outubro que traça algumas dicas e abordagens de como realizar essa evolução.

Frameworks

Falando em React, junto com Vue são as abordagens mais indicadas para focar em 2018 devido a sua recepção e crescimento aliado a esse pensamento de construção em blocos na evolução de legados em vez de um Framework de propósito geral que tenta resolver tudo. Óbvio que a escolha de um ecossistema envolve diversos aspectos, inclusive opinião pessoal.

Ouça o Hispters.tech sobre React que tentamos explicar um mundo de coisas sem código.

Algumas tecnologias como Reason, Elm e Clojurescript são interessantes, mas a realidade é que são relevantes apenas se você tem interesse especificamente em algumas poucas empresas que as utilizam.

Redux e Vuex

Se você abrir a lista de empresas que usam React ou Vue no BR e fizer um search vai perceber que praticamente 99,99% delas usam Redux e Vuex respectivamentes, que são um Centralized State Management.

Em outras palavras isso significa isolar o código que transforma e manipula seus dados para evitar acoplar nas suas Views tornando a manutenção e evolução bem mais robusta pela organização dessa abordagem.

Em composição a esse Mindset de coesão e baixo acoplamento também é recomendado um Middleware/Plugin que manipula chamadas assíncronas chamado de Saga, seja Redux ou Vuex, para evitar código dentro das Views.

Um Centralized State Management ainda facilita o Track e monitoramento de errors para PWA.

Progressive Web App

PWA não é uma tecnologia, é uma abordagem para construir Mobile Apps com os padrões WEB. No artigo “Progressive Web Apps: a palavra-chave é Progressive, não App ou Web” tem links, audio, video e slides sobre o tema.

Uma série de Apps já tem sua versão PWA: Twitter, Telegram, Instagram, Uber, Pinterest,… até o Tinder.

Middlewares

Com o lançamento do AWS AppSync agora no último re:Invent o GraphQL demonstrou que chamou a atenção e veio se consolidar como o Backend para o Frontend daqui pra frente.

É possível que Firebase, serverless campeão da atualidade, venha a oferecer GraphQL em breve.

Indiferente se você deseja continuar especialista em Front ou ganhar proeficiência no Backend pra se tornar um Full Stack, não vai poder ignorar Elasticsearch.

Esse motor de buscas é mais que uma DSL, hoje um mecanismo importante no Mindset imutável de construção dos seus Data Transfer Objects junto de Centralized State Management.

Automatizado

Por fim e não menos importante, um Front-end moderno não pode deixar de ser totalmente automatizado, desde o boilerplate gerador de build como o create-react-app, passando pelo Pipeline de CI com Jenkins (ou o seu preferido) a uma publicação em CDN como AWS Cloudfront.

Espero que esse guia de recomendações seja útil para sua evolução, deixe suas dúvidas nos comentários para complementarmos.

Colocou a App em produção? Vamos conversar.

Você não conseguirá impedir erros em produção e principalmente lidar com isso na interação com o usuário mesmo que sua aplicação tenha uma cobertura de 100% com testes unitários, um bom ratio pra cada linha de código e testes de aceitação/integração.

Você está errado em todas as metodologias se não testa de forma automatizada.

Reagindo a erros não esperados

A versão 16 do React trouxe um método excelente no ciclo de vida dos componentes, o componentDidCatch, que captura todas as exceções lançadas pelos nós abaixo na árvore do componente que manipula esse método.

Em outras palavras, todo erro que acontecer abaixo de ErrorBoundary (ver código seguinte) será capturado num único ponto sem a necessidade de espalhar try/catch pelo código de apresentação.

De qualquer forma, todas as transformações de estado devem ser concentradas no redux como o código a seguir.

https://gist.github.com/cmilfont/e4fa20e1ced19a36fcdf948916184ade

Independente de como mostrar a UI para o usuário ao acontecer um erro, essa informação virá exclusivamente de um ponto que é administrado por transações das sagas.

Estado Centralizado

Temos vários vantagens em centralizar a manipulação de erros no redux, a principal é que podemos concentrar o monitoramento em um único lugar com os dados trackeados pelo sua ferramenta, seja Airbreak, Logentries ou Sentry.

https://gist.github.com/cmilfont/a0009b8e0af3e4ce0eb1e23439324314

Qual a diferença entre colocar um window.onError?

Facilitar coordenar tipos de erros junto ao estado da aplicação, além de indicar um único ponto de manutenção porque esses tipos precisam de transformações e Tracking.

Track dos erros

Dado a centralização dos erros, agora partir para logar direto no seu serviço que provavelmente tem dezenas de métodos de notificações e habilitar a integração com seu Issue Tracking.

Offline

O ecossistema Redux também agrega a vantagem de facilitar a persistência dos erros para tracking e análise futura ou evitar a submissão constante de notificações aproveitando para enviar em Batch num tempo determinado.

Em alguns casos extremos, principalmente em integração, você pode exportar o store na window para disparar um error que extrapola a aplicação com window.onError = error=> (window.store.dispatch({ type: ‘GLOBAL_ERROR’, payload: error }));

Espero que essas dicas agreguem valor a sua App, porque é praticamente impossível evitar erros, é sempre melhor estar preparado pra agir quando eles surgem.

Comenta sobre algo que acontece(u) na sua App que essas dicas ainda não cobrem para eu melhorar o artigo.

O Sérgio Lopes, ou Sergio Caelum, um dos maiores nomes do Front-end do Brasil e quiça do mundo escreveu um excelente artigo defendendo o ponto de vista que o mais importante no PWA é o fator Web.

Discordo — e já concordei — e acredito que o mais fantástico de PWA é unificar o desenvolvimento Front-end moderno em um único dispositivo.

Estamos desenvolvendo e aperfeiçoando o The Rivendel Way apostando pesadamente que no Capítulo Front-end o PWA vai ser a solução para unificar tudo.

Front-end é o dispositivo que foi desenhado pra ser.

A programação Front-end nasceu no primeiro terminal, se é que não dá pra considerar desde o cartão perfurado.

No Desktop a grande facilidade encontrada foi a padronização de um Toolkit fornecido pelo próprio SO, você não tinha que desenhar sua tela, apenas usar a UI fornecida, os Patterns vem desde os anos 70 — como MVC — e o estado da arte já estava encontrado ali nos anos 90.

Temos que reescrever todo o código Mobile a cada 2 anos

Todo mundo aceita, mesmo a contragosto, reescrever toda a aplicação a cada dois anos porque não tem o que fazer, os dispositivos nem existem mais e os novos provavelmente dão algum “probleminha” de compatibilidade desde o SO a libs específicas.

Alguém citou IOS? Eu que não.

Qual o porquê desse mesmo comportamento não ser aceito pra Front-end Web?

Os dispositivos, conhecidos como navegadores, demoram um pouco mais e mantém uma certa retrocompatibilidade com a sua receita de bolo na construção da UI artesanal que ele não oferece.

Resultado: um time Front Web, um time Front Android e um time Front Ios P-O-R P-R-O-D-U-T-O.

Responsivo

Um dos fatores mais importantes na minha opinião é começar ponto a ponto a partir do responsivo do seu produto/site.

Se tem um mínimo necessário, pra mim seria isso e acredito que todo mundo concorde com isso, sem “responsividade” não dá pra nem conversar?

Mas Milfont, pra quê falar o óbvio em pleno 2107?

Acredite, não é ainda, por incrível que pareça. Sigamos.

Qual o Porquê de não esquecermos do aspecto App?

Voltando ao Post do Sergio, Web é importante como plataforma, unificar esses times e ecossistema de tecnologias, além de fornecer a mesma experiência para o usuário sem o punir com instalação, entre outras coisas.

Mas só pensar em Web não faremos essa mudança, precisamos indexar na lista de Apps dos dispositivos móveis, ter uma responsividade ao acessar um link em um Push Notification (*) , compartilhar entre Apps, acessar com facilidade recursos do aparelho (ou no caso do IOS pelo menos acessar) e pequenos detalhes que só lembramos na hora de implementar.

(*) (quem está usando o Twitter no Android já deve ter percebido que tem vezes que não abre a App quando clica na mensagem)

Progressivo

Enquanto o PWA não fornecer o aspecto App completo, não será aceito.

Precisamos progressivamente entregar um valor ao usuário mais próximo do que ele já tem hoje, que no Mobile nativo já lembra muito aquele estado da arte que o Desktop entregou nos anos 90.

Já estamos prontos?

Semana que vem vou palestrar no BrazilJS sobre as vitórias alcançadas do CEJS (primeiro semestre) pra cá, enquanto isso fique com as derrotas:

Pra finalizar, se ouviu o podcast referenciado no início do texto, vai perceber que profetizei o PWA no IOS (que é o que falta) até 31 de dezembro, a Apple está correndo atrás pra não furar o prazo.

Quero demonstrar como criar uma cultura de sucesso mantendo e atraindo os melhores, os empolgando constantemente e instigando o crescimento junto ao negócio.

Em primeiro lugar, entenda: na empresa somos todos mercenários, não membros da família como o DHH escreveu brilhantemente. Como? Pra explicar isso vamos precisar de um preâmbulo histórico.

Até a invenção do capitalismo, todas as relações de trabalho giravam em torno da terra, ou seja, você tem um suserano que é dono da terra por direito religioso ou social e vassalos que devem respeito e obediência ao seu nobre. [1]

Existe uma diferença substancial entre vassalo e escravo, o primeiro pode ser outro nobre inclusive. Você trabalha por Honra e satisfação ao seu suserano, não por um salário, antigamente não existiam sequer forças armadas, eram os vassalos e nobres quem formavam o exército — com excessão do exército Romano em um curto período de tempo e com suas particularidades.

Em contrapartida o suserano tinha a obrigação de fornecer segurança, alimentação e todos os recursos necessários a subsistência de seus vassalos.

Homens livres eram basicamente mercenários, aqueles que trabalhavam apenas para quem pagava mais, não necessariamente apenas pelo dinheiro, a reputação de um bom trabalho valia mais que seu peso em ouro pra conquistar trabalhos futuros e satisfazer o ego entre seus pares, noções de valores marginais já disseminados.

Na transição entre o feudalismo e o capitalismo surgiram outros pequenos artesãos, ordens e sociedades de outras especialidades, mas todos girando em torno da guerra e discriminados como mercenários.

Invenção do Capitalismo

Fomos nos ajustando como sociedade pela mudança sócio-cultural das relações de trabalho a partir da invenção da indústria e dos serviços entre leis trabalhistas e teorias financeiras sobre essa difícil relação, no fim das contas somos homens livres que trabalham por dinheiro ou uma boa reputação como os antigos mercenários, mas o ranço do significado da palavra nos impede de enxergarmos como tais e nos submetermos na maioria das vezes como vassalos.

Ao mesmo ponto que o empreendedor é dono do novo conceito de terra e precisa entender que contrata mercenários, não é suserano de seus colaboradores. [2]

Invenção do termo Colaboradores

Os departamentos de Recursos Humanos tentaram suavizar a visão entre um vassalo e um mercenário e inventaram o termo colaborador que incuta a noção que dinheiro não é envolvido, mas também não é descartado. Ou seja, não define na verdade o que você faz e nem quais responsabilidades são induzidas a quem é o dono do capital.

Colaborador pode ser tanto um fornecedor, quanto um funcionário ou um co-fundador. Mas na empresa existem os sócios e os funcionários apenas, estes divididos em hierarquias de chefia, seja técnica ou absolutamente burocrática.

Conduza a carreira

Vamos começar pelo dono do capital e da alta gestão, ao trabalhar o ego de seus funcionários vocês conseguem “corrigir sem ofender e orientar sem humilhar?“.

Tem certeza? Que tal medir o nível de satisfação dos seus colaboradores?

Plano de Carreiras

Não acredite em empresas horizontais, níveis de hierarquia e disparidade salarial são vistos como algo justo. Tem trabalhos científicos demonstrando isso. Um bom plano de carreiras com regras claras de como o funcionário crescerá na sua empresa.

Harmonia no ambiente de trabalho

Não ofereça puff e cadeiras confortáveis como diferencial, não está contratando crianças, um ambiente saudável é o que desafia sem explorar, não queira vender como um ambiente familiar que as pessoas viverão naquele panfleto da bíblia com leões e tigres convivendo entre seres humanos, lugar de trabalho é para a boa competição.

A harmonia é atingida quando todos sabem seus papéis e possuem a autonomia necessária para desempenhar, os inaptos sairão normalmente, mas não causará o infortúnio de perder os melhores. Não acredite em evitar choques de visões e opiniões fortes, isso não evitará possíveis desentendimentos e talvez surta o efeito contrário.

Networking e relacionamento

Invista no seu funcionário, o desafie a apresentar palestras, participar de conferências e se tornar o mais apto naquele aspecto técnico — mas pague as despesas, ao demonstrar o trabalho que fez na sua empresa ele se esforçará pra coordenar e organizar da melhor forma possível, afinal ele vai provar seus méritos a seus pares que serão bem criteriosos. Tire do Budget de Marketing pra financiar.

Atrair os melhores (e principalmente os manter) ainda vai ajudar a atrair os pares.

Tamanho de Time

Todo mundo quer fazer Cosplay da cultura de Squad do Spotify, mas você está tentando emular ou absorvendo os aspectos culturais?

O mais importante para o time é que você tem que preencher os papéis, não os transformar em cargos, isso é paralelo no plano de carreiras. Scrummaster não deve ser cargo (foi engano se já está na CBO).

Invista no treinamento e especialização

Queira o melhor mercenário no time que seu dinheiro pode pagar, se não dá pra bancar um salário gordo devido ao mercado e Market Share que possui, compre uma conta na Alura e um pacote na Casa do Código pra eles como complemento, alie com o tópico sobre palestras e Networking.

Coordene o que vão estudar, em vez de soltar 20% de horas pra pesquisa aleatória, promova ações sólidas como a resolução de um problema que seu produto/serviço atua e patrocine um Hackathon pra isso.

Os conselhos usam exemplos bem pontuais da área de desenvolvimento de software, porte e adapte para o seu segmento.

Conselho para os colaboradores

Você trabalha em uma empresa que hora extra é o normal e não recebe por isso?

Trabalha sob pressão e tem que se virar pra aprender seja lá o que for?

Ganha pouco e ainda por cima tem o risco constante de perder o emprego sob ameaças?

Não tem as conquistas valorizadas e quando erra isso é evidenciado?

Procure empresas que façam o aconselhado aqui e parem de trabalhar como vassalos, não acredite em empresas que se vendem como famílias ou vai viver sob mesada o resto da vida.

Citações

[1] Um livro excelente focado no entendimento entre as eras comerciais e termos a noção da cultura que girava em torno da terra.

[2] O melhor livro para entender sobre capitalismo.

Não vou entrar no mérito das discussões e pular direto pra sugestões de como enfrentarmos os problemas. Negar que sempre houve assédio nas relações de trabalho não funciona, mesmo quando achávamos que não existia racismo, homofobia, machismo, entre outras coisas.

Como se precaver?

Como fica a empresa diante de todas essas denúncias e a exposição de sua marca?

Lembre que a marca (brand) perde valor, o humor dos funcionários (ou colaboradores, pra incluir todos os credos) cai e como consequência a produtividade, a cobrança dos clientes intensifica por uma expectativa de resolução e lá se sabe quais mais prejuízos em cada confusão instaurada.

Uma saída encontrada e praticada para as empresas é criarem programas de recuperação da situação, o mais famoso é um programa de contenção depois que aconteceram os problemas, o Performance Improvement Plan (doravante denominado PIP).

Mas um ponto que entendemos, se a pessoa entrou em PIP, algum prejuízo já aconteceu. Piora se quem for fazer coaching/acompanhamento for do mesmo time e estrutura, porque alguma carga pessoal já existe.

Transparência

Lembra do NPS?

Então, se não lembra ou não conhece, a grosso modo de explicar é uma métrica pra saber a lealdade dos seus cliente, existe uma versão pra medir a lealdade também dos funcionários.

É bacana pra acompanhar o gráfico de quem está tendencioso a entrar em PIP. O acompanhamento da variação do seu NPS já é um forte indicador do humor em relação a empresa e aos pares.

O ideal é que cada um saiba sua nota e os objetivos claros que estão sendo mensurados, pelo menos pra abrir uma rodada de 1 pra 1 com seus pares ou superiores antes que o problema aconteça.

Mas isso não é o suficiente para identificar possíveis problemas, quanto de carga emocional existe nas relações que não consigo pegar no eNPS?

Processos subjetivos

Já trabalhei em times que medíamos frequentemente e cometemos o deslize de não desligar quando ultrapassava o ponto de recuperação por ignoramos o gráfico de acompanhamento dos resultados, isso causa um problema de contaminação na equipe.

Basta um insatisfeito por longo tempo pra causar um descontentamento geral (citation needed).

Alguns pontos são urgentes e difíceis de medir num processo objetivo e, quando já viu, passou daquele ponto de chamar pra conversa e evitar o PIP.

As vezes o time que é inadequado

Já trabalhei em equipes que trocamos algumas pessoas com times diferentes e funcionaram muito bem com outros pares, acontece. Não tem como evitar o aspecto cultural que se forma e cobrar inclusão irrestrita é incorrer em outros erros (polêmica pra post próprio).

O ideal que a própria equipe tenha autonomia necessária para rodar o seu processo de acompanhamento, sem a necessidade da empresa se envolver, mas para isso os líderes e board de direção precisam garantir.

Como meço o subjetivo?

Pra abrir uma rodada de processo subjetivo ou pré-PIP, não precisa de muita coisa, um responsável por coordenar abre uma campanha de feedback ao menor sinal de insatisfação (Come on baby, você sabe do que estou falando, aquelas conversas no café).

Basta todos informarem 3 (magic number) pontos negativos que incomodam naquela pessoa mesmo que os indicadores objetivos estejam sinalizando uma normalidade com menos detratores.

Computa-se os 3 mais relevantes e estabelece Keys objetivas ou claras para dar tempo de trabalhar a recuperação e esclarece o avaliado.

Em uma segunda rodada de avaliação (um ou dois meses depois) se mede o resultado alcançado.

Como escrevi anteriormente, existem pontos que são comportamentais e culturais que afetam as relações e nenhum dos dois lados estão dispostos a mudarem.

O que resta pra empresa é agir antes que aconteça o inevitável e blindar o time inteiro.

Que momento é adequado pra rodar o Feedback subjetivo?

Depende da estrutura da empresa, pode ser um líder técnico que identifica ou o próprio funcionário que sente algo diferente, aí depende.

Transparência e autonomia são as chaves, talvez só trabalhar isso já resolva o problema.