A ideia deste artigo é apresentar um assunto bastante interessante e que tem sido objeto de estudo por muitos anos: Refatoração Arquitetural (RA). Para isto, é feito uma breve introdução para contextualizar melhor o assunto.
A primeira etapa no desenvolvimento de um software é o projeto arquitetural, que se preocupa como o sistema deve ser organizado e sua estrutura em geral. Uma boa arquitetura explora as vantagens e os recursos técnicos do ambiente de destino, enquanto satisfaz os requisitos funcionais e não funcionais do sistema. Softwares podem ser projetados com diferentes padrões e estilos arquiteturais (por exemplo, REST) e deve-se considerar o contexto da aplicação.
Sistemas de softwares utilizados na indústria geralmente são complexos e possuem longo tempo de vida. O software deve evoluir para atender às necessidades de mudança dos clientes. No entanto, se os arquitetos de software sempre se concentrarem em adicionar novos recursos, eles estenderão e aumentarão continuamente o sistema até que eventualmente se torne difícil realizar manutenção. Portanto, a necessidade de uma evolução contínua sob a pressão de novos requisitos técnicos e de negócio e a correção de defeitos levam ao aumento da complexidade e a deterioração do sistema. Uma das consequências dessa deterioração durante o envelhecimento do software é a Erosão Arquitetural, que gera uma lacuna entre a arquitetura planejada, definida durante a fase de projeto arquitetural, e a arquitetura concreta, definida pela implementação atual do software.
Quando o sistema atual já não atende às expectativas de qualidade e descartar o software recomeçando um novo projeto não é o mais oportuno em decorrer de fatores como custo, tempo e conhecimento sobre o negócio, então uma refatoração arquitetural pode ser a solução. É discutido por Zimmermann (2017) que sistemas de software geralmente precisam sofrer reengenharia em razão de alterações imprevisíveis de contexto e inovações tecnológicas que ocorrem durante sua vida útil. Muitas atividades de reengenharia afetam a arquitetura desses sistemas.
Alguns estudos sugerem que Smells Arquiteturais (SA) são bons indicadores para identificar oportunidades de refatoração. Os smells de arquitetura abrangem vários componentes e têm um impacto a nível de sistema, sinalizando que algo não é mais adequado sob os requisitos e restrições da arquitetura atual. As Violações Arquiteturais, por exemplo, apesar de não serem consideradas como SAs, também indicam que regras da arquitetura do software foram violadas. Existem diversas técnicas automatizadas que identificam violações arquiteturais através da divergência entre a arquitetura planejada e a arquitetura atual. Um exemplo simples de violação arquitetural, por exemplo, seria um acesso indevido à uma camada restrita do software.
A refatoração arquitetural leva o sistema em direção a uma melhoria em atributos de qualidade, como a manutenibilidade e reusabilidade. Segundo Martin Fowler, uma referência na área de Engenharia de Software, Refatoração é o processo de mudar um sistema de software melhorando sua estrutura interna, sem que seja alterado seu comportamento externo. Pode-se aplicar a refatoração em diferentes níveis, como: código, design e arquitetura. Considerando esse contexto, pesquisas têm sido conduzidas para dar apoio aos engenheiros de software na aplicação de refatoração arquitetural, sendo possível identificar diversos trabalhos na literatura.
Refatoração arquitetural (Architectural Refactoring) é um termo bastante amplo e com diferentes definições. Neste artigo, entenderemos como um processo menor de reengenharia de software que visa eliminar um smell arquitetural ou violação arquitetural por meio de refatorações de código. Uma refatoração arquitetural deve melhorar ao menos um atributo de qualidade do sistema, ao mesmo tempo que mantém inalterado o seu comportamento. Alguns atributos de qualidade, são: manutenibilidade, funcionalidade, desempenho, compatibilidade, etc. A refatoração arquitetural pode conter uma ou mais etapas, geralmente exigindo um grande esforço de manutenção e tempo. Além disso, é preciso identificar uma sequência correta para aplicação destas etapas de refatoração, já que geralmente envolve muitas alternativas. Isso pelo fato de que ao aplicar um conjunto de refatorações menores numa sequência incorreta, poderá implicar em resultados indesejados ou incorretos.
Para melhor entendimento, pode-se observar na figura abaixo um exemplo de smell arquitetural conhecido como dependência cíclica. Esse é um problema bastante estudado e pode ser solucionado de diversas formas. A dependência cíclica, ilustrada no lado esquerdo da imagem, deve ser removida, pois sua implementação reduz a capacidade de gerenciamento, testabilidade e modificabilidade do software. Ao lado direito da imagem, é exibida uma a refatoração arquitetural que soluciona o problema removendo uma das dependências. Em um próximo artigo buscarei falar um pouco mais sobre refatoração arquitetural, mostrando outros exemplos e uma proposta de template para apoio bastante interessante. Além disso, também quero deixar em aberto uma outra perspectiva das RAs, que são refatorações mais complexas, envolvendo sistemas inteiros.
Refatoração Arquitetural para resolução de SA de dependência ciclica (STAL, 2014).