BT

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

Contribuir

Tópicos

Escolha a região

Início Notícias Arquitetura, tecnologia e o anti-pattern Lava Layer

Arquitetura, tecnologia e o anti-pattern Lava Layer

As sucessivas mudanças na arquitetura e tecnologia em todo o ciclo de vida de uma aplicação podem levar a uma base de código frágil e fragmentada que é difícil de entender e de manter, um anti-pattern conhecido pelo nome de Lava Flow ou Lava Layer. Mike Hadlow explica compartilhando suas experiências de como e porque esse anti-pattern às vezes surge.

Hadlow, um engenheiro de software freelancer, tem frequentemente experimentado esse anti-pattern em softwares corporativos, especialmente em projetos grandes, de missão critica e de longa duração em conexão com organizações com alta rotatividade profissional. Ele também descobriu que isso geralmente surge a partir da necessidade de aprimorar o software. Para ilustrar como esse anti-pattern surge foi criado uma história fictícia sobre uma aplicação, baseada em suas experiências de inúmeros projetos.

O desenvolvimento da nova aplicação começou quando a plataforma .NET era relativamente nova e a decisão foi tomada para construir uma aplicação web na plataforma ASP.NET e para adaptar as diretrizes da Microsoft para a construção de uma Camada de Acesso a Dados (Data Access Layer - DAL) baseada no ADO.NET RecordSet e expondo Datasets diretamente para a camada de UI.

A aplicação foi lançada e depois de um certo tempo em uso novas exigências chegaram e foi atribuído um orçamento para uma nova versão. Com o novo líder de desenvolvimento criticando a implementação da DAL e o uso de Datasets um novo design foi decidido. Para as novas partes do sistema foi escolhida uma abordagem orientado a objetos com classes representando tabelas e com código gerado a partir do banco relacional.

Depois de alguns anos, com novos desenvolvedores trabalhando na aplicação sem realmente entender os diferentes modelos usados, um usando Datasets e outro usando um tipo de padrão Active Record, um outro design foi decidido para a terceira versão, dessa vez usando um domain model e um Mapeamento Objeto Relacional, ORM. Uma sugestão para uma reescrita completa foi rejeitada, resultando em uma aplicação com três diferentes soluções de acesso a dados implementadas para o mesmo tipo de funções dependendo da época que a implementação foi gerada.

Embora esse seja um projeto fictício, Hadlow frequentemente vê o mesmo problema em projetos reais. Em projetos sem uma estrategia arquitetural consistente e filosofia de design clara, permitindo assim para novas escolhas em design e tecnologias, essas novas escolhas raramente substituem completamente as antigas, resultando em um sistema com camadas arqueológicas revelando a sua história e diferentes modismos tecnológicos usados. Ele acredita que os desenvolvedores agem de boa fé em querer melhorar o sistema, mas sem os recursos necessários para uma reescrita, acabam terminando em um sistema implementando o anti-pattern Lava Flow.

Hadlow aconselha ter cuidado ao avaliar qualquer mudança tecnológica ou arquitetural significativa em uma aplicação existente, às vezes é melhor favorecer uma tecnologia consistente mesmo que ela seja considerada antiquada ou legado.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT