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…
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.
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.
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?
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ê?
É 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!
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:
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 :)
Fontes:
https://robsoncamargo.com.br/blog/Manifesto-Agil-entenda-como-surgiu-e-conheca-os-12-principios
