Desenvolvimento

2 out, 2013

Design patterns após o design estar pronto

Publicidade

Design patterns são uma ferramenta útil quando você está projetando um sistema, um atalho eficaz para comunicar e compartilhar ideias de design e uma forma de construir a consistência no código – se as pessoas entendem e seguem padrões corretamente.

Eu não estou interessado em discussões sobre se os design patterns são bons ou não, ou quais padrões são bons e quais não são – embora essas sejam questões importantes.

O que eu quero entender é como design patterns são úteis ao longo do tempo. Será que eles ainda são importantes após o projeto inicial estar pronto?

À procura de padrões no código

A primeira coisa a fazer é ver se os desenvolvedores que trabalham com o código são capazes de reconhecer os design patterns que foram utilizados, e quão útil os padrões são para eles.

Em Design Patterns for Maintenance, Joshua Engel afirma que, quando alguém da manutenção do código reconhece um padrão, ele instantaneamente obtém mais contexto, o que significa que ele pode se mover mais rápido e com mais confiança:

Quando o mantenedor reconhece um padrão em um pedaço de código que está sendo mantido, ele entende um pouco mais sobre o código. O mantenedor bate em uma riqueza de material de histórico: a experiência pessoal, bem como o que se lê em livros como Design Patterns. Esse histórico pode te dar pistas para armadilhas potenciais, limitações e a maneira destinada para a evolução do código. Ou, se o código não corresponde completamente aos padrões, você tem um guia sobre o que precisa ser adicionado para obter os benefícios desse padrão.

Isso é apoiado por pesquisa. Em Making Software, o capítulo 22, “The Evidence for Design Patterns”, revisa dois estudos do Prof. Walter Tichy, mostrando que os design patterns podem ser úteis para desenvolvedores manterem o código, desde que as pessoas que mantêm o código reconheçam e compreendam os padrões. Um estudo de estudantes de ciência da computação que tiveram alguma formação em design patterns descobriu que os estudantes cometiam menos erros e eram mais rápidos em alterar o código se seguissem design patterns conhecidos e de fácil compreensão, e se os design patterns utilizados no código fossem claramente documentados nos comentários. Em outro estudo, os programadores experientes também foram capazes de fazer as mudanças mais rápido e com menos bugs se o código seguisse os design patterns com que eles estavam familiarizados.

Mas outro estudo sobre pdesign patterns em código legado explica como é difícil “minerar design patterns” em código:

  • reconhecer design patterns em código requer um bom entendimento do código, bem como dos padrões comuns;
  • alguns padrões são mais fáceis de reconhecer do que outros – e alguns padrões simplesmente não serão reconhecidos.

Compreensão e reconhecimento de padrões no código

Os padrões só são valiosos se eles são imediatamente reconhecíveis por quem está trabalhando no código e podem ser facilmente seguidos. O que significa que, em primeiro lugar, eles têm de ser implementados corretamente e sustentados ao longo do tempo.

Além do GoF catálogo de design patterns, do qual a maioria dos desenvolvedores já deve ter ouvido falar, e talvez Patterns of Enterprise Application Architecture de Martin Fowler, há muitas outras coleções de padrões menos conhecidas – não ligue para os padrões proprietários que foram inventados pela equipe que escreveu o software.

Você não pode esperar que um desenvolvedor reconheça esses padrões, muito menos que os compreenda, ao olhar o código, a menos que eles estejam explícitos de outra forma no código por meio de convenções de nomenclatura e comentários (incluindo, para os padrões mais obscuros, links ao vivo para definição do padrão). Os estudos acima provam que esse tipo de documentação é especialmente importante para os desenvolvedores menos experientes.

Mas só porque alguma coisa tem “Factory” ou “Strategy” no nome, ou comentários explicando que o código está seguindo um padrão, não significa que ele realmente segue esse padrão corretamente, pelo menos não mais.

Refatoração para padrões

Outro lugar onde os padrões podem entrar no jogo é na refatoração. Ao limpar a estrutura do código, é natural (para alguns desenvolvedores pelo menos) pensar sobre onde os padrões podem ser aplicados.

Refatoração para padrões leva a refatoração para um nível superior, e não apenas corrige os problemas óbvios e as inconsistências no código. Ele descreve como trazer design inline com os padrões comuns (não todos eles a partir do livro GoF), utilizando várias etapas de refatoração.

Alguns padrões são simples de entender, simples de aplicar, não necessitam de uma série de mudanças para implementar, e resultam em código mais simples: Factories e Prototypes. Refatoração para outros padrões requer muito mais trabalho para entender e alterar o código, e pode não valer a pena o esforço: Strategies and State, Observer, Visitor.

Qual é o retorno real para refatoração de código ou reescrever a padrões para o bem dos padrões? Muitas vezes não há um.

Você não quer refatorar para padrões, a menos que:

  1. você tenha uma boa razão para refatorar o código em primeiro lugar – o código é difícil de compreender e mudar, e
  2. você sabe como refatorar corretamente e com segurança;
  3. você precisa de maior flexibilidade que a maioria dos padrões oferece, e
  4. você tem a experiência e o discernimento para saber quais padrões são necessários e como usá-los corretamente, e
  5. as pessoas que trabalham com você também entendem os padrões bem o suficiente para acompanharem as mudanças que você deseja fazer.

Como diz o livro GoF:

Design patterns não devem ser aplicados de forma indiscriminada. Muitas vezes, eles alcançam flexibilidade e variabilidade através da introdução de níveis adicionais de engano, o que pode complicar um projeto e/ou custar-lhe algum desempenho. Um design pattern só deve ser aplicado quando a flexibilidade que ele oferece é realmente necessária.

O valor dos padrões com o passar do tempo

Refatoração para padrões incentiva uma refatoração mais ambiciosa e em maior escala – o que pode ser perigoso, porque quanto mais você refatora, mais chances existem de cometer erros e introduzir bugs – e implementar padrões nem sempre torna o código mais fácil de manter e fácil de entender, o que destrói o propósito de refatoração.

Um estudo sobre design patterns e qualidade de software da Universidade de Montreal (2008) descobriu que design patterns na prática nem sempre melhoram a qualidade do código, reutilização e expansão, e muitas vezes tornam o código mais difícil de entender. Alguns padrões são melhores do que os outros: Composite torna o código mais fácil de seguir e mais fácil de mudar. Abstract Factory torna o código mais modular e reutilizável, mas à custa de entendimento. Flyweight torna o código menos expansível e reutilizável, e muito mais difícil de seguir. A maioria dos desenvolvedores não reconhece ou entende o Visitor Pattern. Observer também pode ser difícil de entender, embora não torne o código mais flexível e extensível. Chain of Responsibility torna o código mais difícil de seguir e mais difícil de alterar ou corrigir de forma segura. E Singleton, é claro, embora seja simples de reconhecer e compreender, pode tornar o código mais difícil de mudar.

Para manutenção e entendimento, é mais importante reconhecer e manter as convenções de codificação para que a base de código seja consistente no que implementa padrões. E para entender refatorações comuns e como usar ferramentas de refatoração de sua IDE, bem como padrões para limpeza de legado de código de Michael Feathers.

Se você está projetando e escrevendo um código novo, ou alterando código, ou refatorando código, o melhor conselho é:

  • Não use padrões, a menos que você precise.
  • Não use padrões que você não entende completamente.
  • Não espere que quem vai trabalhar no código, no futuro, reconheça e compreenda os padrões que você usou – atenha-se a padrões comuns e torne-os explícitos nos comentários onde você acha que é importante ou necessário.
  • Quando você alterar o código, leve algum tempo para procurar e entender os padrões que podem estar em vigor e decidir se vale a pena conservá-los (ou restaurá-los): se, fazendo isso, o código realmente vai se tornar melhor e mais compreensível.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/06/design-patterns-after-design-is-done.html