Guia de Desenvolvimento Baseado em Componentes

A modularidade tem sido um dos princípios fundamentais do desenvolvimento de software desde a década de 1960. A aplicação desse princípio traz muita utilidade à programação. A modularidade contribui para o uso efetivo do princípio da separação de responsabilidades, o que leva a uma melhoria na capacidade de criar, reutilizar e criar código.

Atualmente, a aplicação do princípio da modularidade no design de software assumiu uma nova forma, incorporada nos componentes. Este é o CDD (Component Driven Development). Bibliotecas e estruturas modernas para o desenvolvimento de interfaces de usuário, como React , Vue e Angular , bem como ferramentas orientadas a CDD como Bit , permitem criar aplicativos baseados em componentes modulares. O programador tem à sua disposição os padrões e ferramentas necessárias para desenvolver componentes isoladamente e criar composições de componentes.


Um componente é um fragmento independente claramente definido da interface do aplicativo. Como exemplos de componentes, você pode citar entidades como botões, controles deslizantes e janelas para exibir mensagens de bate-papo. Entendendo os recursos do CDD e sabendo como aplicar essa abordagem ao desenvolvimento, podemos usar componentes como base de aplicativos. Isso, ao criar projetos de software, fornece tudo o que é útil, o que significa aplicar os princípios da programação modular.

Se você observar atentamente o que está acontecendo agora no campo de componentes da Web , notará que o CDD está se tornando uma abordagem padronizada para o desenvolvimento de front-end.

O material, que publicamos na tradução de hoje, é um guia de desenvolvimento baseado em componentes.

CDD no desenvolvimento da interface do usuário

Trabalhar no Bit: criar, isolar, reutilizar e colaborar em componentes

Simplificando, o desenvolvimento baseado em componentes está projetando aplicativos, criando blocos de código independentes de baixo acoplamento. Cada um deles possui uma interface projetada para organizar a interação com outras partes do sistema. Muitos componentes, combinados entre si através da composição, formam um aplicativo modular.

Por exemplo, o uso do CDD na criação de aplicativos React significa que eles primeiro criam os componentes que formam a base do aplicativo e, em seguida, procedem à montagem a partir deles de partes maiores do aplicativo, como páginas inteiras e grandes blocos de funcionalidade.

O CDD está relacionado ao design atômico ( aqui é um material útil sobre esse tópico) e à abordagem para o desenvolvimento de partes de projetos da Web do lado do cliente, conhecidas como “ micro frontend ”.

O CDD ajuda a dividir o processo de desenvolvimento de um grande projeto em processos de desenvolvimento menores para componentes individuais. Cada componente é projetado independentemente do restante do aplicativo e é criado levando em consideração a possibilidade de interação com outras partes do sistema. Projetar cada componente como uma entidade independente fornece ao desenvolvedor muitos recursos úteis.

Eddie Osmani destacou alguns dos principais benefícios do uso do CDD. Ele os projetou em um conjunto de princípios chamado PRIMEIRO .

Esses princípios são:

• Aceleração do desenvolvimento (desenvolvimento mais rápido). O fato de os esforços dos desenvolvedores terem como objetivo criar componentes separados permite a criação de partes modulares do aplicativo com APIs altamente especializadas. Isso significa que os componentes podem, por um lado, ser desenvolvidos rapidamente e, por outro, que é mais fácil trazê-los ao nível de qualidade exigido pelo projeto durante seu desenvolvimento.
• Simplificação do suporte (manutenção mais simples). Quando você precisar modificar ou atualizar uma parte de um aplicativo, poderá expandir ou atualizar um componente, em vez de refatorar grande parte do aplicativo. Isso pode ser comparado a um procedimento médico, com uma operação em um órgão separado, substituindo uma operação que envolve intervenção em quase todas as partes do corpo.
• Melhores recursos de reutilização de código. Devido ao uso do princípio de separação de responsabilidades, os componentes, durante a criação de um aplicativo finalizado, podem ser reutilizados ou expandidos. Isso é muito melhor do que a necessidade de reescrevê-los repetidamente ( aqui está o material sobre este tópico).
• Melhorar a capacidade de aplicar a metodologia TDD (Better TDD). Durante o desenvolvimento de componentes modulares, é muito mais fácil do que usar outras abordagens para implementar testes de unidade destinados a verificar a funcionalidade restrita de um componente. Como resultado, é mais fácil testar grandes sistemas montados a partir de componentes. O fato é que, ao usar uma abordagem modular, é mais fácil para um desenvolvedor entender pelo que exatamente uma ou outra parte do sistema é responsável.
• Encurtando curvas de aprendizado (Curvas de aprendizado mais curtas). Quando um desenvolvedor precisa lidar com um novo projeto para ele, fica muito mais fácil entender a essência e a estrutura dos componentes individuais do que se aprofundar nas complexidades de todo o projeto.
• Melhorando os recursos dos sistemas de modelagem (melhor modelagem do sistema). Quando o sistema é criado a partir de componentes modulares, fica mais fácil para o desenvolvedor entender a estrutura geral do sistema, entendê-lo e aprender como influenciá-lo.

Ferramentas CDD

Se o desenvolvimento for baseado em componentes, isso significa que o programador precisa de ferramentas especializadas. Essas ferramentas têm como objetivo criar componentes, testá-los, organizar o acesso geral a eles e apoiar a colaboração neles.

Em particular, é importante projetar e testar componentes isoladamente. Isso permite que eles trabalhem na forma de unidades independentes que podem ser usadas no aplicativo. Além disso, o suporte à reutilização de componentes e a capacidade de compartilhá-los são importantes. Isso permite que quem trabalha como parte de uma equipe em um projeto importante não reinvente a roda, que, na forma de um componente, já foi inventada por um dos membros da equipe.

Aqui estão algumas ferramentas úteis para ajudá-lo a organizar seu trabalho em projetos no estilo CDD. Em uma das seções a seguir, falaremos sobre arquiteturas de projetos recomendadas para a implementação prática dos princípios do CDD.

ItBit: desenvolvimento individual e em equipe de componentes

Bit é uma ferramenta de código aberto , criada essencialmente para apoiar a aplicação prática da metodologia CDD. Aqui está um vídeo sobre o Bit. Essa ferramenta ajuda a desenvolver componentes, colaborar com eles e criar projetos da web usando-os.

O ponto é que com Bit significa que você pode isolar componentes que estão sendo desenvolvidos como parte de um projeto. Diga - dentro de um aplicativo ou biblioteca. O Bit suporta ferramentas de linha de comando, ajuda a organizar o encapsulamento de componentes com todos os seus arquivos e dependências. Bit permite desenvolver e testar representações virtuais de componentes encapsulados isoladamente.

Isso significa que o componente criado dentro do aplicativo pode ser equipado com todas as suas dependências, encapsulado e transformado em uma entidade que pode ser usada e testada fora do aplicativo.

Além disso, o Bit permite que você empacote componentes encapsulados independentes e organize seu compartilhamento usando as ferramentas da nuvem . Isso permite que as equipes que trabalham nos projetos usem todos os componentes que são compartilhados. A comunidade Bit tem cerca de 50.000 desenvolvedores. Seus esforços criaram milhares de componentes de código aberto disponíveis para todos.


Desenvolvimento de projetos usando componentes encapsulados

Graças aos recursos da plataforma em nuvem, as equipes de desenvolvimento podem instalar componentes de código aberto em seus aplicativos. Os membros da equipe também podem oferecer idéias aos autores dos componentes para melhorar os componentes, fazendo isso diretamente de seu ambiente de trabalho. O Bit estende a capacidade do Git de rastrear e sincronizar as alterações no código-fonte do componente entre os projetos. Isso oferece aos desenvolvedores a capacidade de gerenciar alterações e atualizações de componentes.

Bit armazena uma árvore completa de dependências de componentes. Isso dá ao desenvolvedor a oportunidade de aprender sobre como a atualização de um componente pode afetar os componentes dependentes, sobre o que pode ser "quebrado" em um projeto quando são feitas alterações em um componente. Isso significa que, graças a Bit, o programador tem à sua disposição um ambiente completo para organizar o desenvolvimento com base em componentes, permitindo criar componentes, testá-los e organizar trabalho conjunto sobre eles e seu uso conjunto.


Recursos de nuvem no CDD

Outro recurso útil do Bit é que essa plataforma permite que as equipes de desenvolvimento não apenas trabalhem com seus componentes usando uma única interface, mas também usem outros componentes dispostos em domínio público e interajam com os autores desses componentes.

Designers de interface, representantes de clientes do projeto e programadores podem, no decorrer do trabalho conjunto em projetos, usar ferramentas visuais comuns. Isso preenche a lacuna entre designers e programadores. Além disso, deve-se observar que, nessa situação, não apenas os designers e programadores se beneficiam, mas também os usuários finais de aplicativos que encontram menos heterogeneidades e erros. Aqui , aqui e aqui estão alguns materiais sobre vários aspectos do uso do Bit.

EvelDesenvolvimento e pesquisa de componentes de interface do usuário: StoryBook e Styleguidist

O StoryBook e o Styleguidist são ambientes para o desenvolvimento rápido de elementos da interface do usuário usando o React. Ambos os projetos são ótimas ferramentas para acelerar o desenvolvimento de componentes.

Livro de histórias

O StoryBook é um ambiente para o desenvolvimento rápido de componentes da interface do usuário. Ele permite que você trabalhe com a biblioteca de componentes, visualize os vários estados dos componentes, participe do desenvolvimento interativo e teste de componentes.


Trabalhar no StoryBook

O StoryBook ajuda a projetar componentes isoladamente do aplicativo. Isso ajuda a melhorar a reutilização dos componentes e melhora a testabilidade dos componentes.

Usando o StoryBook, você pode visualizar os componentes armazenados na biblioteca e experimentar suas propriedades online. As alterações feitas no componente imediatamente, sem recarregar a página, são visualizadas. Aqui estão alguns exemplos de componentes criados no StoryBook.

Existem vários plugins que podem acelerar o desenvolvimento de componentes usando o StoryBook. Isso permite reduzir o tempo decorrido entre a alteração do código do componente e a formação de sua representação visual. Note-se que o StoryBook, além de React, também suporta React Native e Vue.js.

React styleguidist

O React Styleguidist é um ambiente de desenvolvimento de componentes. Este ambiente contém um servidor de desenvolvimento que suporta uma inicialização a quente. Ele também possui um sistema de gerenciamento de estilo interativo que exibe propTypes componentes e fornece aos desenvolvedores exemplos editáveis ​​do uso de componentes com base em arquivos .md.


React styleguidist

Essa plataforma suporta JavaScript ES6, Flow e TypeScript. Ela é capaz, sem configurações adicionais, de trabalhar com o aplicativo Create React. O Styleguidist tem a capacidade de criar automaticamente a documentação do componente. Isso permite que esse sistema desempenhe o papel de um portal de documentação visual para componentes nos quais alguma equipe está trabalhando.

Se você estiver interessado em projetos como o StoryBook e o Styleguidist, poderá dar uma olhada no projeto React Live , que está sendo desenvolvido pela Formidable.

Diferença entre StoryBook e Styleguidist

Enquanto trabalhava com um StoryBook, um programador escreve "histórias" em arquivos JavaScript. Ao trabalhar com o Stuleguidist, ele escreve "exemplos" nos arquivos do Markdown. Enquanto um StoryBook mostra apenas uma variação de um componente por vez, o Styleguidist pode exibir várias variações de componentes diferentes. O StoryBook é ótimo para analisar os vários estados dos componentes, e o Styleguidist é ótimo para gerar documentação de componentes e demonstrar recursos.

Decisões arquitetônicas usadas usando a metodologia CDD

O trabalho no estilo do CDD significa que, ao desenvolver aplicativos, os componentes são criados primeiro. Além disso, esses componentes devem ser o mais independentes possível. Isso significa que o desenvolvedor não cria apenas um "conjunto de componentes". Ele também implementa o chamado sistema de design dos componentes da interface do usuário.

Os componentes podem ser criados dentro da estrutura do próprio aplicativo (ou seja, no mesmo projeto, repositórios) e no formato de um projeto separado (repositório) - na forma de uma biblioteca de componentes.

Ferramentas como o Bit permitem isolar e encapsular componentes. Isso oferece ao desenvolvedor ampla oportunidade de criar, testar, reutilizar componentes e permite que eles sejam finalizados em qualquer lugar - independentemente de onde foram criados.

Se dissermos que o uso do CDD prevê o desenvolvimento de componentes na forma da primeira etapa do trabalho em um projeto, isso também implica que os componentes tendem a torná-los adequados para uso repetido. Isso permite que você os aplique ao criar vários aplicativos. Portanto, o desenvolvedor precisa descobrir exatamente como ele precisa fazer para criar esses componentes. Não há nada pior do que gastar seis meses para criar uma biblioteca que, no final, ninguém usará. Infelizmente, isso acontece com muitas equipes.

Por que criar uma biblioteca de componentes?

Serei sincero com você: os repositórios Git não foram concebidos levando em consideração a possibilidade de armazenar códigos de componentes atômicos neles, planejados para serem compartilhados em vários projetos. Para resolver esse problema, os gerenciadores de pacotes não são adequados. Ambos foram criados, o que é compreensível, para suportar repositórios de código. Componentes não são repositórios.


Compartilhando um componente em vários projetos

É por isso que, caso você precise pegar um componente de um aplicativo e usá-lo em outro aplicativo, é necessário criar um novo repositório. Para se salvar do trabalho desnecessário de criar um repositório separado para cada componente similar, a maioria das equipes cria um repositório compartilhado projetado para armazenar de 20 a 30 componentes.

Ao usar uma ferramenta como Bit, a biblioteca de componentes, como tal, não precisa. Essas ferramentas permitem baixar um componente do aplicativo para a nuvem e implementar esse componente em outros projetos. Se compararmos esse esquema de trabalho com os repositórios tradicionais, podemos dizer que isso é algo como comparar um CD de música e o Spotify. É verdade que, se você estiver próximo da idéia de desenvolver e usar bibliotecas de componentes, os recursos de plataformas como Bit e StoryBook permitirão que você trabalhe com bibliotecas.

Ao projetar uma biblioteca, você precisa tomar várias decisões importantes. Abaixo serão considerados alguns princípios importantes que ajudarão você com isso. O ponto principal desses princípios é que sua tarefa é criar componentes independentes. As demais etapas do trabalho se assemelham à montagem da Lego. Se o princípio de desenvolver componentes independentes não for respeitado, um dia você poderá ter problemas. Os problemas começarão quando alguém precisar de algo diferente do que está na biblioteca. De fato, quando isso acontece, as equipes param de usar as bibliotecas de componentes.

Suponha que você decida criar uma biblioteca de componentes. Nesse caso, oferecemos algumas dicas que ajudarão você com isso.

7 princípios para o desenvolvimento de bibliotecas de qualidade orientadas a CDD

1. Padrões Quais padrões de desenvolvimento você adere ao criar sua biblioteca? Onde estão localizados os componentes? Onde estão localizados os testes? E os estilos? Qual pilha de tecnologia você está usando? Por exemplo - você planeja usar o TypeScript? Como os componentes são divididos? O componente "Tabela", por exemplo, consiste em "Linhas" e "Células"? O painel com guias consiste em guias separadas (as mesmas perguntas podem ser feitas em relação a outras entidades semelhantes)? Suponho que você já tenha entendido o significado desta recomendação. Também é muito importante incluir designers no processo de formação de padrões. Isso garantirá que a biblioteca seja flexível o suficiente e atenda aos requisitos de design que possam aparecer no futuro.
2. Estilização. Como você planeja estilizar os componentes? Você vinculará o código CSS correspondente a cada componente? Se sim, o que acontece quando um designer precisa alterar algo apenas para um aplicativo separado que usa um componente? Talvez para melhorar a separação de componentes de estilos, vale a pena usar bibliotecas que implementam CSS na tecnologia JS ? Talvez valha a pena procurar alguma outra abordagem para estilizar? Por exemplo, usando Bit, você pode destacar tópicos como componentes separados. Esses tópicos podem ser aplicados a componentes que implementam algum tipo de lógica. Isso permite criar aplicativos nos quais o design e a lógica são combinados exatamente como o desenvolvedor precisa. Aqui está um exemplo da extrema flexibilidade de sistemas construídos usando o princípio da modularidade.
3. Teste. Como você vai testar os componentes incluídos na biblioteca? Usando Jest e enzima? A seleção de uma boa combinação de ferramentas de teste de componentes deve ser abordada com toda a responsabilidade. Isso permitirá que essas ferramentas o ajudem a implementar a metodologia CDD. A má escolha de ferramentas interferirá no trabalho. Os testes de unidade são bons. Mas eles devem verificar as APIs funcionais dos componentes, não os detalhes de sua implementação. Os testes de integração e de ponta a ponta são tão importantes quanto os testes de unidade. A metodologia TDD funciona bem quando aplicada em projetos usando CDD.
4. Processo de montagem de código. O código precisa ser compilado. Como você vai organizar o processo de criação de código para sua biblioteca? Como os lançamentos serão implementados? Você está planejando simplesmente copiar o código do aplicativo e colá-lo na biblioteca (provavelmente modificando-o um pouco)? Você definirá configurações de montagem para cada componente (Lerna) e aplicará os mecanismos apropriados ao código antes de publicá-lo? Você planeja usar, digamos, o já mencionado Bit mais de uma vez, a fim de personalizar os processos de construção que se aplicam a todos (ou a componentes individuais)? Se você complicar demais o processo de montagem, será mais difícil se envolver no desenvolvimento, a modularidade do projeto se deteriorará. A curva de aprendizado necessária para participar do desenvolvimento se tornará muito íngreme.
5. Gerenciamento de código. Quem é o dono da biblioteca? Em organizações razoavelmente grandes, geralmente existem equipes de desenvolvedores front-end e, às vezes, arquitetos. Eles estão criando um produto chamado "biblioteca compartilhada". Outras equipes de desenvolvimento front-end criam aplicativos usando bibliotecas semelhantes. Com esse esquema de interação, é muito importante usar um sistema que permita encontrar convenientemente os componentes necessários (Bit, Storybook). Mais importante, talvez, é o mecanismo pelo qual os usuários de componentes podem propor melhorias de componentes. Se não houver tais mecanismos na organização, as equipes de usuários do componente não desejarão associar seus aplicativos à biblioteca e aguardar a aceitação do seu PR, o que talvez não esperem. Não é necessário forçar os programadores a fazerem nada. É necessário estabelecer uma cooperação saudável. Se você não se esforçar para isso, ninguém usará a biblioteca. Os programadores simplesmente copiam e colam o código, e ninguém fará nada a respeito. Além disso, este será o seu erro. Se você trabalha em uma equipe pequena, determine claramente quem está gerenciando o código. Mesmo se ninguém estiver envolvido na base de código o tempo todo, selecione alguns especialistas que darão suporte a esse código. O resto fará PR - exatamente como no GitHub.
6. Localizando componentes. A biblioteca não trará muitos benefícios se os programadores não encontrarem os componentes de que precisam, não puderem aprender como esses componentes funcionam e não poderão usá-los em seu código. Bit possui os recursos internos que ajudam os desenvolvedores a encontrar componentes. Além desta plataforma (ou em vez dela), você pode usar os recursos do StoryBook ou algum tipo de solução própria. A plataforma Codesandbox pode fornecer alguns benefícios na resolução de problemas relacionados à seleção de componentes e ao trabalhar com a documentação para eles.
7. Organização de colaboração em componentes. O que acontece quando um desenvolvedor (talvez de outra equipe ou mesmo de outro país) precisa alterar algo relacionado a um componente da sua biblioteca? Ele precisa se aprofundar na criação de um PR para sua biblioteca e, cruzando os dedos, aguarde os resultados. Para muitos desenvolvedores, isso é muito complicado, eles não farão isso, mesmo se você tentar influenciá-los. Será muito melhor se você usar uma certa plataforma que simplifique a colaboração em projetos.

Lembre-se de que uma biblioteca é apenas um repositório que existe para facilitar o compartilhamento de componentes em vários projetos. As bibliotecas não escalam muito bem, o código nelas se torna obsoleto, elas sofrem de vários problemas. Talvez seja melhor simplesmente fornecer acesso direto aos componentes destinados ao compartilhamento, usando algum tipo de plataforma em nuvem.

Benefícios da equipe CDD

As equipes que usam o princípio CDD se beneficiam do desenvolvimento acelerado, maior reutilização do código, TDD aprimorado e uma interface consistente do sistema de design.

Os programadores podem escrever código com acesso a componentes já gravados e trabalhar juntos para fazer alterações nos componentes. O desenvolvimento de novos recursos ou aplicativos se resume à personalização e expansão dos componentes básicos. Além disso, isso ajuda a evitar erros encontrados apenas na produção.

Compartilhar código significa, entre outras coisas, reduzir a quantidade de código que precisa ser suportada. Isso permite que os programadores se concentrem em criar algo novo. Quando os aplicativos são desenvolvidos com base em componentes, isso padroniza o trabalho devido ao fato de todos usarem uma única base de blocos de aplicativos. A abordagem de componentes também contribui para a flexibilidade do trabalho.

Algumas equipes relatam que seus fluxos de trabalho se tornaram até 60% mais rápidos, graças ao uso de componentes modulares baseados em sistemas de design implementados como conjuntos de componentes do React. Algumas organizações descobriram que, com a introdução dos CDDs, eles podem remover aproximadamente 30% do código de suas bases de código.

Empresas como Uber, Airbnb, Shopify e outras estão introduzindo uma abordagem de componentes.

Sumário

Pessoalmente, não estou surpreso que o uso do CDD melhore a eficiência do desenvolvimento de software. De acordo com Brad Frost, autor do livro sobre design atômico, modularidade e composição são os conceitos mais importantes em biologia, economia e em muitas outras áreas. A modularidade na aplicação ao desenvolvimento de software fornece velocidade, confiabilidade e facilidade de desenvolvimento. Promove a reutilização de entidades, melhora a testabilidade e a extensibilidade do código. A modularidade oferece ao desenvolvedor a capacidade de usar a composição ao criar sistemas complexos. Tudo isso afeta muito bem o processo e os resultados do desenvolvimento de aplicativos.

Caros leitores! Você usa a metodologia CDD ao trabalhar em seus projetos?