Documentando e testando sua arquitetura Java com Archunit— Parte 1: Porque testar minha arquitetura?
Tags: java, archunit, architecture, devtest
Published: 2021-04-15 20:47:20

Antes de falar sobre o [ArchUnit](https://www.archunit.org/) 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wdlpmlium7xfg9ef1kzs.gif)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uaocx232hv2aumnsl5qr.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2op2frmhn3gy9uycl22g.png)

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?](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rhwonenvjpfonu663b9z.gif)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/czcrca92dmznb63ebjdp.png)

É 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o6z0zo5o9v0fiqzhhj55.gif)

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.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2pqufvnjxqz64wlr0ruh.png)

![Imagem com definição da palavra Documentação:Ato, processo ou efeito de documentar; conjunto de documentos destinado à comprovação ou esclarecimento de algo.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0b7o8ulwau0daciv77fd.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/htfdp6z7qpkaupz7qc5y.gif)

**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