BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Cinco coisas que todo desenvolvedor de software deve saber sobre Arquitetura de Software

Cinco coisas que todo desenvolvedor de software deve saber sobre Arquitetura de Software

Favoritos

Pontos Principais

  • Compreender os conceitos básicos de arquitetura de software tornou-se mais importante do que nunca, dada a natureza distribuída dos sistemas de software que atualmente estamos construindo, e a natureza distribuída das equipes que os compõem.
  • O ponto ótimo de um desenho de arquitetura inicial, entre ter tudo ou nada, deve se concentrar na compreensão das decisões e compromissos significativos que influenciam a forma de um sistema de software.
  • Bons arquitetos são membros ativos de uma equipe de desenvolvimento, colaborando com código para coaching e fornecendo liderança técnica para a equipe.
  • A comunicação sobre arquitetura de software é desafiadora. O modelo C4 pode ajudar a estruturar a comunicação, começando com um diagrama de contexto e trabalhando em aspectos mais técnicos do sistema.
  • Contrariamente à alguns pressupostos populares, o esforço para a construção de uma boa arquitetura realmente permite alcançar uma maior agilidade.

Em 2010, escrevi um artigo intitulado Are You a Software Architect? (Será que você é um Arquiteto de Software?), que analisou a diferença e a transição entre ser um desenvolvedor de software e ser um arquiteto de software. Embora a indústria tenha avançado de muitas maneiras nos últimos 8 anos, parece que as equipes de desenvolvimento de software ainda estão lutando com alguns dos conceitos básicos, especialmente aqueles relacionados à arquitetura de software. Estes são, sem dúvida, mais importantes do que nunca, dada a natureza distribuída dos sistemas de software que estamos construindo e a natureza distribuída das equipes que os constroem. Com o objetivo de dar uma breve introdução ao tópico e desmascarar alguns mitos, destacamos cinco coisas que todo desenvolvedor de software deve saber sobre arquitetura de software.

1 . Arquitetura de software não tem nada a ver com um grande desenho arquitetural inicial

A arquitetura de software tradicionalmente tem sido associada a um grande projeto de desenho de arquitetura inicial e uma entrega em cascata, onde a equipe assegura que todos os componentes necessários para um projeto de software foram considerados antes de qualquer código ser escrito.

Em 2001, o "Manifesto para desenvolvimento de software ágil" sugeriu que devêssemos valorizar "responder à mudanças ao longo de um plano", que foi mal interpretado para significar que não devemos planejar. O resultado final, e eu vi isso em primeira mão, é que algumas equipes de desenvolvimento de software deixaram de fazer grandes projetos de desenho arquitetural incial para não fazer nenhum. Ambos os extremos são insensatos, e há uma posição confortável em algum lugar que é relativamente fácil de descobrir se você estiver disposto a considerar que o desenho de arquitetura inicial não é necessariamente sobre a criação de um estado final perfeito. Em vez disso, pense no desenho de arquitetura inicial como sendo algo sobre criar um ponto de partida e definir uma direção para a equipe. Esta etapa, muitas vezes perdida, pode adicionar uma enorme quantidade de valor a uma equipe, incentivando-os a entender o que eles vão construir e se vai funcionar.

Para chegar a um desenho de projeto de software, é necessário tomar algumas decisões de design. Ao discutir a diferença entre arquitetura e design, Grady Booch nos diz que "a arquitetura representa as decisões significativas, onde o significado é medido pelo custo de mudança". Em outras palavras, quais decisões são caras para mudar em uma data posterior? Seguindo este raciocínio, uma boa maneira de pensar sobre o design inicial é assegurar que você tenha feito e entendido os trade-offs associados às "decisões importantes". Essas decisões significativas são tipicamente relacionadas a escolhas e estrutura de tecnologia (ou seja, estratégias de decomposição, modularidade, limites funcionais, etc.). Se você estiver construindo um sistema de software monolítico, a escolha da linguagem de programação provavelmente será significativa por vários motivos. A adoção de uma arquitetura de microserviços reduz potencialmente a importância das linguagens de programação que você escolhe, mas apresenta outros trade-offs que precisam ser pensados. Da mesma forma, a adoção de uma arquitetura hexagonal permite que você desacople sua lógica de negócios de suas escolhas de tecnologia, mas novamente há trade-offs que necessitam ser considerados.

O processo de desenho arquitetural inicial deve, portanto, ser sobre a compreensão das decisões significativas que influenciam a forma de um sistema de software em vez de, por exemplo, entender o comprimento de cada coluna em um banco de dados. Em termos reais, gostaria que os times realmente entendessem o que eles vão construir, como eles vão construí-lo (em um alto nível, para exemplificar) e se o que eles projetaram terá uma boa chance de realmente funcionar. Isso pode ser alcançado identificando os riscos de maior prioridade e mitigando-os conforme apropriado, escrevendo o código, se necessário. Em resumo, o desenho inicial da arquitetura deve ser sobre acumular as chances de sucesso a seu favor.

2. Todo o time de desenvolvimento precisa considerar a arquitetura do software

O que acabei de descrever aplica-se a todas as equipes de software; desde uma equipe composta por apenas uma pessoa construindo uma startup em sua garagem até uma equipe globalmente distribuída com centenas de desenvolvedores. Criar esse ponto de partida e direção fornece liderança técnica. Deixar de fazer isso tende a levar ao caos - bases de códigos inconsistentes e estruturadas de forma inadequada (a "grande bola de lama" estereotipada) que são difíceis de entender, difíceis de manter e potencialmente não satisfazem um ou mais dos atributos de qualidade importantes como desempenho, escalabilidade e segurança. Em resumo, cada equipe precisa de liderança técnica.

3. O papel da arquitetura de software é sobre codificação, treinamento e colaboração

A imagem que muitas pessoas têm de arquitetos de software é de que eles vivem em "torres de marfim" tradicionais, que ditam instruções para uma equipe de desenvolvimento desavisada, como o primeiro corredor que passaria o bastão em uma corrida de revezamento. No entanto, não precisa ser desta forma, e muitos arquitetos de software modernos preferem uma abordagem que favorece a codificação, coaching e o design colaborativo. A maioria dos bons arquitetos de software que conheci também são bons desenvolvedores que ainda gostam de codificar, e desistir disso não é necessariamente algo que eles querem fazer de qualquer jeito. Também é fácil para as pessoas perderem contato com a tecnologia, com a rapidez com que ela muda. Gosto de pensar que os arquitetos de software devem ser "construtores principais", com a implicação de que eles podem e devem codificar como parte da equipe, quando possível. Ser parte da equipe, escrever código, tende a tornar a função de arquitetura de software muito mais fácil também porque você terá uma maior compreensão do sistema que está sendo criado e outros desenvolvedores vão te ver como um par.

Também vale a pena mencionar que a função de arquitetura de software não necessariamente precisa ser realizada por uma única pessoa. Este é frequentemente um bom lugar para começar, mas o papel pode ser um esforço colaborativo que é compartilhado entre um número de pessoas. Contudo, uma palavra de cautela. Desconfie de conselhos afirmando que a liderança técnica colaborativa é fácil. Não é, os soft skills são difíceis de lidar. Executo regularmente katas de arquitetura de software onde grupos de duas a cinco pessoas são convidados a projetar um sistema de software, e testemunhei que alguns desses grupos não conseguiram chegar a um consenso sobre decisões relacionadas a escolhas de design e tecnologia. Em casos extremos, os grupos se dividiram devido a conflitos de ego e personalidade. A chave é entender a equipe no qual você está inserido e, então, certifique-se de aplicar a quantidade apropriada e o estilo de liderança técnica necessária.

4. Você não precisa usar UML

As visões tradicionais de arquitetura de software geralmente evocam imagens de modelos UML (Unified Modeling Language) enormes, que tentam capturar cada gota de detalhes. Infelizmente, a modelagem e a UML se juntaram às práticas de "grandes desenhos iniciais" da era pré-ágil, e tudo isso foi jogado fora pelas equipes nos últimos anos. Nas minhas viagens ao redor do mundo, a porcentagem de equipes de desenvolvimento de software que conheço onde ninguém na equipe conhece UML está aumentando.

O conselho comum de muitas pessoas nos dias de hoje é "usar apenas caixas e linhas em um quadro branco" como forma de comunicar idéias. Tenho gigabytes de fotos desses diagramas de minhas experiências com katas de arquitetura de software ao longo dos anos, e posso dizer com certo grau de confiança que, como indústria, perdemos a capacidade de comunicar arquitetura de software de forma adequada. Eu vi todos os diagramas possíveis que você pode imaginar; de coleções de caixas e linhas ilegíveis de cor aleatória para diagramas que literalmente não lhe dizem nada sobre a solução. Equipes incapazes de comunicar arquitetura de software de forma adequada não serão capazes de criar um ponto de partida e direção descritos anteriormente.

Minha solução é uma abordagem de comunicação abstrata para arquitetura de software que batizei de "modelo C4" - Contexto, Containers, Componentes e Código. Trata-se essencialmente em criar um conjunto de mapas hierárquicos e ajustáveis como uma função de zoom em uma câmera digital ​​para descrever um sistema de software. Para qualquer sistema de software, você cria um diagrama de contexto do sistema que descreve como o sistema se encaixa no mundo ao seu redor. Em seguida, aproxime para o limite do sistema para mostrar os contêineres dentro dele - um contêiner é um recurso executável e implementável, como um aplicativo de uma única página executado em um navegador Web, um aplicativo Web do lado do servidor, um microserviço, um esquema de banco de dados, etc. Se este container for realmente útil, é possível ampliar cada container para mostrar os componentes dentro dele. Finalmente, e, opcionalmente, você pode ampliar cada componente para mostrar os elementos de nível de código (classes, interfaces, funções, objetos, etc.). O modelo C4 é independente de notação, e embora eu tenha uma simples notação de "caixas e linhas", você certamente pode usar UML também.

Você pode encontrar mais informações, vídeos, diagramas de exemplo e links para a ferramenta no site c4model.com, e certamente vale a pena procurar se sua equipe se esforça para comunicar a arquitetura de software e os diagramas em suas páginas de whiteboards/wiki e se estes diagramas fazem algum sentido.

5. Uma boa arquitetura de software promove a agilidade

Ainda existe um equívoco comum de que "arquitetura" e "ágil" são forças concorrentes, havendo um conflito entre eles. Este não é o caso. Pelo contrário, uma boa arquitetura de software permite agilidade, ajudando você a abraçar e implementar a mudança; sejam mudanças em requisitos, processos de negócios, mergers, etc. O que é considerado uma "boa arquitetura" ainda está em debate, é claro, mas, para mim, as características principais de uma boa arquitetura se relacionam com a boa modularidade alcançada por meio de uma decomposição apropriada e estratégica. Se você experimentou a dor de fazer uma grande mudança em uma grande bola de lama existente, onde as partes aparentemente desconectadas de um código quebram, você apreciará que ter uma base de código bem estruturada (com boa modularidade) é um fator importante.

Um grande problema que vejo com os times hoje é que eles adotam, o que George Fairbanks chama no livro Just Enough Software Architecture, de "design indiferente à arquitetura". Em outras palavras, eles adotam um estilo arquitetural sem necessariamente considerar os trade-offs. No mundo de hoje, isso é comumente manifestado em equipes adotando um estilo arquitetural de microserviços simplesmente como uma reação a sua base de código monolítico existente e que é considerada uma bagunça. Piadas a parte sobre essas mesmas equipes, criando posteriormente uma "bola grande distribuída de lama" para todos os lados, verifica-se que o processo de design e decomposição de software é extremamente importante, independentemente de você estar construindo uma arquitetura monolítica ou de microserviços.

Você não possui agilidade ou uma boa arquitetura de graça. É necessário um esforço consciente de design e os compromissos precisam ser considerados. Isso, novamente, é porque criar esse ponto de partida com algum projeto inicial é crucialmente importante.

Sobre o Autor

Simon Brown é consultor independente especializado em arquitetura de software e autor do livro "Arquitetura de Software para Desenvolvedores" (um guia amigável para desenvolvedores de arquitetura de software, liderança técnica e equilíbrio com agilidade). Ele também é o criador do modelo de arquitetura de software C4, que é uma abordagem simples para criar mapas do seu código. Simon é um orador regular nas conferências internacionais de desenvolvimento de software e viaja pelo mundo para ajudar as organizações a visualizar e documentar sua arquitetura de software.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT