Uma das técnicas fundamentais quando se tem grandes aplicações é a componentização. Uma componentização de software distingue-se pelo fato de que a base de código é dividida em pequenas porções que fornecem comportamento por meio de interações limitadas e bem definidas com outros componentes. Usar uma abordagem de componentização geralmente é descrito em termos de incentivar reuso ou ter boas propriedades arquiteturais como baixo acoplamento. Isso é verdade, mas há outro benefício explícito: também é uma das maneiras mais eficientes de colaboração para grandes equipes.
Mas o que é componente?
Componentização
A ideia de um “componente” em software é algo que a maioria das pessoas consegue reconhecer, embora ela tenha muitas definições diferentes, e algumas vezes bem vagas. Uma declaração pouco controversa poderia ser feita da seguinte forma: “um componente é reutilizável e pode ser substituído por outra coisa que implementa a mesma API, que pode ser implantada independentemente, e que encapsula um conjunto coerente de comportamentos e responsabilidade no sistema”.
O requisito para componentes é que possam ser implantados independentemente, e classes não atendem a esse critério. Além disso, classes geralmente trabalham em grupos que entregam algum comportamento útil e são, em termos relativos, mais acopladas com seus colaboradores mais próximos.
Um componente deve ter certo nível de complexidade antes que possa ser considerado uma peça independente da aplicação. E o que dizer de um limite superior? Nosso objetivo ao dividir um sistema em componentes é aumentar a eficiência de uma equipe.
Uma característica significativa da maioria dos componentes é que eles expõem algum tipo de API. As bases técnicas da API podem ser diferentes: uso de processos de vinculação estática ou dinâmica, serviços Web, transferência de arquivos, troca de mensagens, e assim por diante. A natureza da API pode diferir, mas é importante que ela represente uma troca de informação entre colaboradores externos, e assim, o grau de acoplamento dos componentes aos seus colaboradores. Mesmo quando a interface de um componente é um formato de arquivo ou um esquema de mensagens, ele ainda representa um acoplamento de informação que, por sua vez, exige que sejam consideradas as dependências entre componentes.
Benefícios da componentização
- Eles dividem o problema em porções menores e mais expressivas.
- Componentes geralmente representam diferenças nas taxas de mudança de diferentes partes do sistema e têm ciclos de vida diferentes.
- Eles incentivam a definição e manutenção de um delineamento claro de responsabilidade, o que por sua vez limita o impacto de mudanças e torna o entendimento e a alteração da base de código mais simples.
- Eles podem dar um grau maior de liberdade na otimização do processo de compilação e implantação.
Dicas para uma boa componentização da base de códigos
Componentização
Não recomendamos criar equipes responsáveis por componentes individuais
O motivo é que requisitos funcionais geralmente não podem ser separados no âmbito de componentes. Nossa experiência tem mostrado que equipes multifuncionais que desenvolvem funcionalidade de ponta a ponta são mais eficientes. Embora uma equipe por componente pareça mais eficiente, esse não é o caso.
É difícil escrever e testar requisitos para um único componente em isolamento, já que implementar dada funcionalidade geralmente toca mais do que um componente. Se as equipes são separadas por componentes, você pode precisar de duas ou mais equipes colaborando em uma funcionalidade, o que automaticamente adiciona um custo alto e desnecessário de comunicação.
Além disso, pessoas em equipes baseadas em componentes tendem a formar silos e otimizar localmente, perdendo a capacidade de julgar o que é melhor para o projeto como um todo.
É melhor dividir a equipe de modo que cada equipe trabalhe em uma frente de histórias
Essas equipes talvez possam ter um tema em comum, que toque quaisquer componentes de que precise para completar o trabalho. Equipes com um mandado para implementar uma funcionalidade de negócio e com a liberdade de mudar qualquer componente de que precisam são muito mais eficientes. Organize equipes por áreas funcionais e não por componentes, e garanta que todos têm o direto de mudar qualquer parte do código, fazendo rotações regulares de pessoas entre as equipes e mantendo uma boa comunicação entre elas.
Management
É o porquê e o que fazer. Essas questões envolvem a visão macro da situação da arquitetura. A estrutura de gestão deve permitir compartilhar com os demais membros do time assuntos como riscos e roadmap, garantindo um melhor entendimento do contexto do projeto para todos.
A segunda abordagem tem o benefício adicional de garantir que todos tenham a responsabilidade de manter os componentes funcionando e que isso não seja trabalho de uma equipe de integração. Um dos perigos mais sérios de ter uma equipe por componente é que a aplicação como um todo pode não funcionar ao fim do projeto, porque ninguém tem o incentivo de integrar os componentes.
Não há regras estritas sobre como organizar a aplicação como uma coleção de componentes além das considerações anteriores sobre boa arquitetura. Há, entretanto, duas falhas comuns, “componentes em toda parte” e “um componente para governar todos”. A experiência nos mostra que nenhum extremo é apropriado, mas entender as fronteiras entre componentes é um julgamento específico de desenvolvedores e arquitetos, seja qual for seu nível de experiência. Esse é um dos fatores que torna a criação de software uma arte e uma ciência social tanto quanto uma disciplina de engenharia.
Finalmente, vale ressaltar a Lei de Conway, que declara que “organizações que projetam sistemas… são limitadas a produzir projetos de sistemas que são cópias da estrutura de comunicação destas organizações”. Por exemplo, projetos de código aberto em que desenvolvedores somente se comunicam por e-mail tendem a ser modulares com poucas interfaces. Um produto desenvolvido por uma equipe pequena, toda no mesmo local, tende a ser mais acoplado e pouco modular. Tenha cuidado com a maneira como configura sua equipe de desenvolvimento – isso afetará sua arquitetura. Se sua base de código já é grande e monolítica, uma boa maneira de começar a separar em componentes é usar branching por abstração.
Quer aprender a como gerenciar componentes e integrá-los no pipeline? Conheça nossa certificação internacional EXIN DevOps Master e se torne um especialista no assunto
Newsletter HNZ
Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!
