👩🏿‍🤝‍👨🏾 💪🏾 🙏🏾 Desenvolvimento de front-end na empresa: o que é e como torná-lo eficaz 😊 🔵 🦂

Nós da KORUS Consulting CIS organizamos o desenvolvimento de serviços da Web para nossos clientes há mais de dez anos. Já temos várias dezenas de projetos sérios no setor bancário, alguns dos quais receberam reconhecimento internacional.

Nos últimos dois anos, o número de equipes e projetos em nossa empresa aumentou várias vezes, enquanto a eficácia do desenvolvimento de front-end também aumentou muitas vezes. Aprendemos como criar aplicativos em poucas semanas, e não em alguns meses.

Estamos trabalhando constantemente no desenvolvimento da infraestrutura de nosso desenvolvimento front-end e hoje compartilharei alguns desenvolvimentos na organização do departamento front-end, que podem ser úteis para quem organiza o front-end em sua empresa.

Neste artigo, você aprenderá sobre o nosso caminho para responder às seguintes perguntas:

, ;
, ;
;
;
;
.

A parte front-end de um site ou aplicativo é o que você vê no seu navegador; essa parte interage ativamente com a parte do servidor (back-end), localizada em qualquer servidor, trocando constantemente dados com ele.

Do ponto de vista técnico, o front-end do aplicativo é um conjunto de arquivos, entre os quais arquivos, imagens HTML, CSS e JavaScript, etc. O trabalho com CSS e HTML está relacionado à tipografia, JavaScript - à programação. Ambas as áreas oferecem um grande número de ferramentas e tecnologias para o trabalho, desenvolvem-se ativamente e exigem muito conhecimento. Isso é especialmente verdade no JavaScript, que criou um grande número de estruturas e bibliotecas para a criação "cada vez mais eficiente" de aplicativos da web.

De alguma forma, me perguntaram o que agora preciso fazer para que os aplicativos não fiquem obsoletos por mais alguns anos?

Como programador, posso dar uma resposta completamente precisa e completamente inútil: HTML, CSS e JavaScript. O que exatamente escolher, jQuery, Angular ou React - esses são os detalhes.

Se você se aprofundar nesses detalhes, poderá dar outra resposta igualmente correta e inútil: sobre qualquer coisa. Sim isso é verdade. O aplicativo pode ser escrito em qualquer coisa, funcionará, pode ser alterado e desenvolvido.

Qual é a diferença?

Para encontrar a resposta, vejamos o que a empresa deseja do front-end. Acho que não vou surpreender ninguém se disser que a empresa deseja obter de maneira rápida e barata um resultado de alta qualidade.

Então, no que você precisa fazer aplicativos agora, para que o desenvolvimento seja rápido, eficiente e não arruine o cliente?

Velocidade de desenvolvimento

Um programador com vasta experiência com o React poderá escrever rapidamente um aplicativo no React, pois a experiência com o Angular permite agilizar o trabalho com o Angular e assim por diante. Tudo é bem óbvio. As próprias estruturas economizam tempo de desenvolvimento, fornecendo soluções para problemas e tarefas comuns. Em essência, essas soluções podem estar muito próximas umas das outras e a diferença entre elas pode estar no paradigma de sintaxe ou programação.

A velocidade do desenvolvimento usando uma estrutura específica depende da experiência e das qualificações dos programadores que a escrevem; a estrutura em si é de importância secundária.

Qualidade do produto

É o mesmo aqui: é bom e ruim que você pode escrever em qualquer estrutura. Você pode colocar a arquitetura certa e errada em qualquer lugar.

Tudo depende da experiência e conhecimento do desenvolvedor.

Custo

Todas as principais estruturas modernas são gratuitas; portanto, se você omitir os detalhes, o custo de desenvolvimento é o tempo gasto pelos desenvolvedores no estudo dos requisitos, tecnologias, elaboração da arquitetura e redação do código. Além do custo de encontrar / treinar esses desenvolvedores.

Daí a conclusão: você precisa confiar não tanto na tecnologia como nos desenvolvedores e na organização de seu trabalho.

Quase qualquer estrutura popular moderna é boa o suficiente para criar nela quase qualquer aplicativo que os negócios modernos possam exigir.

Portanto, será aprofundada a eficácia do front end em termos de organização do desenvolvimento.

Como foi com a gente

Em 2017, tínhamos aplicativos em quase tudo que merecia atenção no mundo do JavaScript: do jQuery a diferentes versões do Angular e React no Typescript e Flow. Os desenvolvedores de layouts e backend / fullstack trabalharam no lado do cliente de nossos aplicativos. Cada desenvolvedor escolheu ferramentas para suas tarefas, dependendo do seu conhecimento das tecnologias front-end.

Agora só posso especular, mas parece-me que a escolha de estruturas e bibliotecas pelos desenvolvedores de fullstack / back-end era algo como isto:

“Vamos ver o que eles escrevem na Internet ...”

Bem, você entende.

Ao escolher uma estrutura / biblioteca, o desenvolvedor é limitado no tempo, na maioria das vezes ele não tem tempo para implantar novas estruturas de forma independente para ele e fazer aplicativos de teste. Portanto, ele de alguma forma faz uma escolha mais ou menos bem fundamentada e segue na direção escolhida.

Em momentos diferentes, essa opção pode ser diferente, mesmo para o mesmo desenvolvedor (veja as ilustrações acima). Ao mesmo tempo, ele não se torna menos racional. O que esperar de diferentes desenvolvedores com experiências diferentes?

Sem o conhecimento de 2017, nos transformamos em um verdadeiro zoológico de tecnologia front-end.

Frontend como uma unidade separada

Um grande número de tecnologias diferentes na empresa é uma fonte de risco. Um desenvolvedor com o conhecimento necessário pode estar ocupado em outro projeto, ele pode deixar completamente a empresa. Contratar especialistas com vasta experiência em vários campos também não é uma tarefa fácil.

Documentação de alta qualidade pode atenuar os efeitos negativos dessa diversidade, mas geralmente leva muito tempo para estudar e mergulhar em tecnologias desconhecidas.

Em 2017, uma divisão de front-end apareceu em nossa empresa, que foi uma resposta às crescentes demandas sobre a qualidade da parte de front-end de nossos projetos e sua quantidade, bem como uma tentativa de estabilizar a diversidade de tecnologias e aumentar a eficiência do desenvolvimento.

Essa foi uma etapa importante para o desenvolvimento de nossa empresa: o que estamos fazendo agora, seria impossível fazer com a ajuda de desenvolvedores sem se especializar em front-end.

Como curar o zoológico?

Uma variedade descontrolada de tecnologias torna difícil prever a velocidade e a qualidade do desenvolvimento em geral, enquanto o desenvolvimento comercial exige exatamente isso.

Portanto, nosso próximo passo foi unificar a pilha da empresa com a ajuda de especialistas da nova divisão.

Uma pilha unificada é um conjunto estritamente limitado de bibliotecas e ferramentas que os desenvolvedores podem usar para resolver problemas de negócios. Também inclui políticas relacionadas a diferentes abordagens de programação, por exemplo, o uso de uma abordagem predominantemente funcional, ou vice-versa, sua rejeição.

Uma única pilha oferece ao desenvolvedor a capacidade de alternar rapidamente de um projeto para outro, realizar uma revisão entre equipes e compartilhar efetivamente a experiência e as melhores práticas com os colegas.

A principal tarefa aqui não é decidir o que estamos escrevendo no React ou Angular, mas fazer com que os desenvolvedores usem as mesmas ferramentas para criar aplicativos e as mesmas abordagens para resolver problemas comuns.

Para referência: nossa principal ferramenta é React, mas também estamos desenvolvendo expertise em Angular.

Isto é onde a diversão começa. Forçar no mundo da programação funciona muito mal.

Portanto, em vez de coerção, você precisa garantir que os próprios desenvolvedores sigam certas regras de desenvolvimento.

Para fazer isso, você precisa:

de alguma forma, conserte, formalize os requisitos de desenvolvimento;
Incentive os desenvolvedores a seguir estas diretrizes.

Formalizar uma pilha é uma atividade que requer a capacidade de manter um equilíbrio. Não é necessário elaborar regulamentos detalhados para tudo, a fim de transmitir as idéias básicas aos desenvolvedores. Além disso, a criação e manutenção de especificações detalhadas consome muitos recursos.

Resolvemos o problema de motivação da seguinte maneira: é melhor do que qualquer documentação fornecer ao desenvolvedor um aplicativo semi-acabado (modelo).

Isso permite que os desenvolvedores resolvam tarefas mais rapidamente e impressionem os colegas com sua produtividade e, ao mesmo tempo, os incentivam a aderir às regras básicas que já estão protegidas no código.

Por um lado, aplicações semelhantes no final dão um aumento significativo na velocidade de desenvolvimento devido ao acúmulo de experiência, soluções prontas, uma revisão mais profunda e a capacidade de alternar de projeto para projeto. Por outro lado, cada projeto tem suas próprias peculiaridades, portanto, também é importante aqui não exagerar na padronização.

O que você precisa colocar no modelo de aplicativo

Ao iniciar novos projetos, os desenvolvedores geralmente resolvem as seguintes tarefas típicas:

definição de arquitetura, seleção de tecnologias / ferramentas;
criação de framework de aplicação, montagem;
criação e configuração de mecanismos comuns: tratamento de erros, janelas modais, notificações, roteamento, solicitações de servidor;
definição de um conjunto de elementos de interface;
pesquisa / criação, customização, estilização de componentes de interface com as funções necessárias;
processamento de formulários, validação;
layout;
implementação de funcionalidade por ordem de um cliente (lógica de negócios);
revisão de código;
gerenciamento de registros.

Quais dessas tarefas seus desenvolvedores podem resolver em alguns minutos?

O modelo de aplicativo que desenvolvemos fecha os três primeiros itens desta lista. Neste modelo, expressamos não apenas nossos desejos de uma única pilha para desenvolvimento, mas também as regras básicas da arquitetura do aplicativo.
Comparado às soluções populares que são de domínio público (por exemplo, create-react-app), nosso modelo já contém:

estrutura de pastas prontas;
roteador configurado (rotas);
Armazenamento redux configurado
módulo de solicitação do servidor;
mecanismos prontos para exibir vários tipos de carregadores, notificações e janelas modais através do redux;
módulo de processamento de erros (servidor e usuário) com a saída de mensagens para o usuário;
páginas de modelo;

módulos de modelo de lógica de negócios aos quais estão conectados manipuladores de erro, carregador e notificação.

Em essência, este é um aplicativo pronto para produção com uma página que diz olá mundo. Começando com o café da manhã, na hora do almoço, o desenvolvedor pode mostrar a primeira página de um projeto em funcionamento.

Mas, então, um grande número de outras tarefas interessantes (e não tão) aguardam o desenvolvedor.

Seleção da biblioteca de componentes

Tudo o que diz respeito a layout, componentes de interface (listas suspensas, calendários etc.), formulários e validação, decidimos usar nossa própria biblioteca. Foi a parte mais difícil.

Em 2017, a biblioteca principal da empresa era a biblioteca de componentes Kendo paga, que fornecia soluções de interface do usuário para várias tecnologias, começando com o jQuery. Por várias razões, isso não nos convinha e decidimos considerar bibliotecas alternativas, incluindo a opção de criar nossa própria.

Este é um ponto muito importante no qual você precisa fazer a escolha certa: encontre outra biblioteca que seja melhor para nós ou crie a sua própria. A distribuição adicional dos recursos de desenvolvimento e o tempo que as equipes gastam na criação e finalização dos elementos da interface dependem dessa opção. Em nossa escolha, procedemos das seguintes considerações.

;
;
.

( , , );
;
, . ;
, . .

;
;
.

;
, / ( ..);
( , , , ).

De fato, soluções prontas não são tão prontas. Quase todas as bibliotecas precisam estar preparadas em um grau ou outro. Se você precisar criar um projeto pequeno, poderá não encontrar essa necessidade, mas se estiver realizando algum tipo de projeto grande, ou muitos projetos pequenos e diferentes, o custo das melhorias poderá acabar acima do custo da criação de sua própria biblioteca, que atende plenamente às suas necessidades.

Acontece que você precisa escolher entre instalar a funcionalidade pronta imediatamente com várias limitações e desenvolver suas próprias soluções com a necessidade de esperar e gastar recursos adicionais no desenvolvimento.

Nenhuma das opções nos convinha completamente e encontramos outra solução.

Decidimos fazer nosso complemento para a biblioteca finalizada.

Deixe-me lembrá-lo de que na época já usamos a biblioteca do Kendo em sua forma pura, uma alternativa da qual queríamos encontrar. Foi isso que decidimos tomar como base da nossa principal biblioteca de componentes para aplicativos no React. E a nossa nova biblioteca era uma fachada sobre o Kendo. Omitirei os detalhes técnicos, apenas direi que essa solução nos permitiu obter imediatamente toda a funcionalidade do Kendo e fizemos o que nos faltava, incluindo a correção rápida de bugs, na camada entre a API do cliente da biblioteca e o Kendo.

Essa arquitetura nos permitiu expandir rapidamente o número de componentes devido a outras bibliotecas e módulos, simplesmente incorporando-os em nossa camada. Para clientes da biblioteca (para desenvolvedores de aplicativos), isso parecia um rápido aumento na funcionalidade de uma biblioteca (discutirei isso em detalhes em um artigo separado).

Com o tempo, substituímos todos os componentes por nossas próprias implementações e lançamos a segunda versão da biblioteca, onde levamos em conta toda a experiência anterior, revisamos a API e fizemos nossa própria documentação.

Decidimos colocar nossas realizações em domínio público, em breve elas poderão ser baixadas e usadas em nossos projetos, siga os anúncios.

O que conseguimos no final?

Agora, temos mais de 10 desenvolvedores front-end em várias equipes trabalhando na mesma pilha e com um conjunto de tecnologias. Em uma pilha, já criamos cerca de vinte projetos.

As estatísticas mostram que a eficiência do trabalho mais do que triplicou em dois anos. Os projetos em que costumávamos passar 4-6 meses, agora fazemos em 1-2 meses (estamos falando da parte do front-end).

Começamos a reduzir o tempo de desenvolvimento alterando a estrutura das tarefas dos programadores. Vamos ver como eles mudaram.

Eu já dei uma lista de tarefas que os desenvolvedores resolveram há dois anos:

definição de arquitetura, seleção de tecnologias / ferramentas;
criação de framework de aplicação, montagem;
criação e configuração de mecanismos comuns: tratamento de erros, janelas modais, notificações, roteamento, solicitações de servidor;
definição de um conjunto de elementos de interface;
pesquisa / criação, customização, estilização de componentes de interface com as funções necessárias;
processamento de formulários, validação;
layout;
implementação de funcionalidade por ordem de um cliente (lógica de negócios);
revisão de código;
gerenciamento de registros.

Destes, em nossa empresa hoje, os desenvolvedores estão envolvidos apenas nos três últimos:

implementação de funcionalidade por ordem de um cliente (lógica de negócios);
revisão de código;
manutenção da documentação do projeto.

O restante já está decidido no modelo de aplicativo e na biblioteca de componentes.

Isso afetou não apenas a velocidade do trabalho, mas também, em geral, o humor dos desenvolvedores. De qualquer forma, a implementação da lógica de negócios é muito mais interessante do que configurar listas suspensas. Também é muito mais fácil para o gerente de projeto explicar ao cliente que uma semana de tempo de trabalho foi gasta no desenvolvimento de importantes recursos de negócios, e não no fato de exigir a conclusão de um pequeno elemento de interface, embora eles possam ser bastante equivalentes em termos de custos de mão-de-obra.

Continuamos a trabalhar na direção escolhida e uma das principais tarefas para o futuro próximo é aumentar a motivação dos desenvolvedores para aprofundar suas competências na pilha selecionada e procurar novas soluções eficazes. Agora é fácil dimensionar essas soluções em toda a empresa, graças a uma biblioteca e modelo de aplicativo comuns.

Com votos de eficiência e até breve!

Desenvolvimento de front-end na empresa: o que é e como torná-lo eficaz