Um erro comum quando nós programadores iniciamos com orientação a objetos é a tentativa de projetar um software 100% “à prova de futuro”. Em outras palavras, não é sabido que determinado comportamento irá variar e já criamos interfaces e classes abstratas por toda parte.

Normalmente isso ocorre por inexperiência, quando programadores aplicam certos conceitos sem entendê-los totalmente. Neste caso, levam ao pé-da-letra “programar para interfaces” ou “devemos estar preparados para mudança” e criam diversas abstrações que nunca serão usadas.

QUAL O PROBLEMA?

A extração de interfaces pura e indiscriminadamente gera complexidade desnecessária (AKA “over-engineering” ou “over-design”). Esse tipo de bad smell acaba atrapalhando a entrega do software, pois leva tempo tanto para ser implementado como para ser posteriormente compreendido pelos demais programadores.

Lembre-se que há alguém esperando pelo software e devemos entregar o mais rápido possível, com o mínimo de esforço, sem comprometer a qualidade.

ENTÃO, QUANDO?

Podemos seguir algumas dicas para identificar pontos de extensão no software:

– Nas palavras do Uncle Bob, “leve o primeiro tiro“. Isso quer dizer: espere a primeira mudança acontecer e só depois implemente as devidas abstrações para proteger o código de outras mudanças do mesmo tipo. Ou seja, não é preciso implementar de início o padrão Strategy para cálculo de impostos se o que você tem de antemão é que só existe uma forma de cálculo.

– Pratique TDD. Escrevendo testes antes, você acaba identificando abstrações que permitem que o software seja testável. De quebra, o software acaba protegido contra outras mudanças.

– Obtenha feedback do cliente o quanto antes. Entregando software aos poucos, iteração após iteração, e obtendo feedback do cliente, você acaba descobrindo quais são as mudanças mais prováveis de acontecer o mais rápido possível, podendo, então, refatorar o código para suportar as devidas abstrações. Ou seja, conversar com o cliente é fundamental!

– Procure ajuda com outros programadores que já tenham trabalhado no software e já o viram evoluir. Com certeza, eles saberão dizer quais pontos sofreram mais mudanças (mas não deixe de lado o cliente!!).

PORTANTO…

Devemos, com bom senso, identificar abstrações para partes do software com maior probabilidade de mudança. Procurar e implementar abstrações por todo o software é algo custoso tanto no processo de desenvolvimento como em manutenção.

Era isso.

Comentem, critiquem, sugiram!

Até a próxima!