DEV Community

Cover image for Documentando e testando sua arquitetura Java com Archunit— Parte 1: Porque testar minha arquitetura?
Bárbara Rossalli
Bárbara Rossalli

Posted on

Documentando e testando sua arquitetura Java com Archunit— Parte 1: Porque testar minha arquitetura?

Antes de falar sobre o ArchUnit e como utilizá-lo é importante voltar um passo atrás e responder a seguinte questão:

Por que testar minha arquitetura?

E para responder essa questão é necessário olhar para o software e sua evolução ao longo dos anos.

Então bora lá?! Senta que lá vem história…

Menino deitado no sofa comendo maça, levanta e senta de pernas cruzadas prestando atenção

Com o passar do tempo e a evolução das tecnologias (e da própria economia, sociedade, etc) construir software se tornou mais rápido na mesma proporção que mais complexo.
E isso se deve a dois fatores principais:

  • A mudança do papel do software ao longo do tempo
  • A natureza do software em si

A mudança do papel do software

Quando pensamos no fator de mudança do papel do software é nítido como seu uso e importância foi se modificando ao longo do tempo.

Linha do Tempo da Evolução do Software

No inicio o software era usado somente para processamento de dados. O hardware era um fator determinante, o que tornava a tecnologia pouco acessível. As informações eram processadas e relatórios eram gerados de acordo com a necessidade.

Com a evolução da tecnologia surgiram os sistemas de informações, onde esse processamento de dados passou a ser utilizado de forma mais eficiente. O hardware já não era um fator dominante, o acesso a essa tecnologia se tornou mais acessível e o software passou a ser utilizado como um auxiliador nas tarefas da empresa.

As mudanças tecnológicas e econômicas continuaram a ocorrer e o software passou a ser utilizado de forma massiva, se tornando um fator de inovação e responsável pela vantagem competitiva da empresa que o utilizava (alô transformação digital).

Com essa evolução gradativa da tecnologia e a necessidade de processamento e uso das informações de forma mais ágil e estratégica a importância do software para o negócio aumentou, fazendo com que ele se tornasse essencial para a estruturação do negócio.

Hoje ele se tornou um meio para atingir um objetivo. Ele é peça chave para a evolução e continuidade do negócio. Essa mudança fez com que o modo de se fazer software fosse necessário ser revisto. Com isso ocorreu o surgimento das metodologias ágeis com o propósito de acelerar e facilitar as entregas e mudanças durante o desenvolvimento de um software, pois era necessário que as coisas funcionassem rápido e de forma consistente, e que as mudanças não impactassem negativamente a entrega.

A natureza do software

E alinhado a essa evolução nós temos as características do software em si.

Um software por isso só é complexo. Ele envolve tecnologia, pessoas, processos e negócios.

Um software é efêmero. Tecnologias vem e vão todos os dias. Uma funcionalidade ou um software inteiro pode se tornar inviável/obsoleto de uma hora para outra.

Um software é mutável. Por conta da complexidade e efemeridade a mutabilidade se torna imprescindível para que o software se mantenha funcionando.

A tendência das coisas a se desordenarem espontaneamente é uma característica fundamental da natureza

Quando juntamos essas duas variáveis: a mudança do papel do software + natureza do software nós temos uma enorme tendência ao caos.

Frase: Software é um lugar onde sonhos são plantados e pesadelos são colhidos, um pântano abstrato e místico onde demônios terríveis competem com mágicas panaceias, um mundo de lobisomens e balas de prata - Brad J. Cox

Em um projeto de software nós temos pessoas, tecnologias, negócios e mudanças constantes se relacionando a todo momento. Isso é uma receita perfeita para o caos. Se não tomarmos cuidado o que era para ser uma solução acaba se tornando um problema.

Mas como como evitar o caos?

Não existe segredo, para se evitar o caos é necessário gerar previsibilidade.

E como geramos previsibilidade?

Através de informação e feedback.

Informação
Com informação temos o histórico e o conhecimento do que aconteceu e como aconteceu.

Feedback
Com feedback temos a informação constantemente atualizada.
Utilizando essas duas variáveis passamos a ser capazes de antever problemas do futuro, baseado em problemas do passado.

OK… MAS PORQUE TESTAR E DOCUMENTAR MINHA ARQUITETURA?

Gif de homem falando But... Why?

As metodologias ágeis deram um grande passo na busca da previsibilidade, as mudanças deixaram de ser um problema no ciclo de vida do software e passaram a ser esperadas. Essa busca por reação rápida a mudança e capacidade de adaptação nada mais é que gerar previsibilidade.

Quando pensamos nisso a nível de negócio/requisitos é mais facilmente gerenciável, mas quando falamos a nível de código as coisas complicam.

A arquitetura é alicerce o do software, se as coisas começam a fugir do controle ali, tudo tende a ruir; e a tendência é que a manutenção/evolução do software se torne inviável.

Existe uma teoria de cunho social chamada Teoria das Janelas Quebradas, ela foi desenvolvida na escola de Chicago por James Q. Wilson e George Kelling. Essa teoria diz que se uma janela de um edifício for quebrada e não for reparada a tendência é que vândalos passem a arremessar pedras nas outras janelas e posteriormente passem a ocupar o edifício e destruí-lo.

Por quê?

Janela quebrada e frase: desordem gera desordem

É inato do ser humano a tendência a desordem e ao caos. Quando trazemos isso para o âmbito do desenvolvimento de software faz todo sentido também (até porque software são construídos e utilizados por pessoas).

Agora imagine essa questão de desordem gera desordem a nível da arquitetura do software:

Uns fazem injeção pelo construtor outros pela propriedade. Um desenvolvedor novo entra, não enxerga nenhum padrão resolve seguir o seu. Outro desenvolvedor entra e tem o mesmo pensamento e segue um padrão diferente.

E por ai vai…

Quando nos damos conta a manutenção/evolução do projeto se tornou insustentável.

E além dessa facilidade de manutenção/evolução, quando geramos previsibilidade a nível de arquitetura ganhamos muito mais:

  • Facilita a manutenção do conhecimento
  • Auxilia na tomada de decisão
  • Ajuda a evitar problemas

E com isso uma outra questão surge:

Como gerar essa previsibilidade a nível de arquitetura?

Não existe segredo: DOCUMENTANDO!

Homem jovem de terno escrevendo e revisando pilha de pápeis

Um ponto de atenção aqui:

A metodologia ágil não se opõe a documentação, ela se opõe a documentação sem valor. Ou seja, aquela documentação que não vai ser útil para projeto depois de realizada.

Mas você deve estar se perguntando: “Onde o Archunit entra nessa? Ele é só uma ferramenta de teste não?”

Para responder isso vamos ver o conceito de duas palavras:

Imagem com definição da palavra Documento: Qualquer elemento com valor documental (fotos, filmes, papéis, peças, fitas de gravações, construções, objetos de arte etc.) capaz de provar, elucidar, instruir um processo, comprovar a veracidade de algum fato, acontecimento, teoria, declaração etc.

Imagem com definição da palavra Documentação:Ato, processo ou efeito de documentar; conjunto de documentos destinado à comprovação ou esclarecimento de algo.

Percebam pelas definições que dependendo de como é o nosso teste é construindo ele pode muito bem ser considerado uma documentação (e agregar valor ao projeto).

E é ai que o ArchUnit entra! 😉

Na segunda parte desse artigo irei apresentar a ferramenta e como ela pode nos ajudar a documentar nossa arquitetura. Fiquem ligados! Ate a próxima :)

Gif do Isso é tudo pessoal

Fontes:
https://siteantigo.portaleducacao.com.br/conteudo/artigos/estetica/a-evolucao-do-ti-ate-os-dias-atuais/5611

http://www.justificando.com/2015/05/26/a-desordem-gera-desordem-conheca-a-teoria-das-janelas-quebradas/

https://robsoncamargo.com.br/blog/Manifesto-Agil-entenda-como-surgiu-e-conheca-os-12-principios

Top comments (0)