View on GitHub

FalandoSobre.Software

Papo sobre software, com quem entende!

(c) 2018 Cleuton Sampaio.

Aqui há monstros

a influência dos antipatterns em um projeto de software

Nos mapas antigos, da época das grandes navegações, algumas regiões eram marcadas com avisos: Aqui, há monstros! A ignorância e a demarcação de “território”, eram as principais motivações para tais avisos. Tá, e o que isso tem a ver com antipatterns? Na verdade, muita coisa. Os “antipatterns” podem bem serem encarados como os “monstros” dos mapas de antigamente, os quais, seja por ignorância ou demarcação de território, nós mantemos dentro de nosso código-fonte.

Antipatterns

O que é um antipattern? Bem, você sabe o que é um pattern, não?

Um design pattern (padrão de projeto) é uma solução reusável para um problema recorrente e comum, em um contexto determinado, no projeto de um software.

O problema é que, da mesma forma que a matéria possui a antimatéria, o “pattern” possui o “antipattern”…

Um antipattern é um padrão que diz como ir de um problema até outro pior.

Na verdade, nós conhecemos os “antipatterns” com outros nomes, como: gambiarra, marreta, bacalhau e, mais modernamente, solução de contorno. São abordagens ad-hoc, ou seja, criadas para um fim específico, que são portadas para diversos problemas, como se fossem solucioná-los.

Uma solução baseada em “antipatterns” pode até funcionar temporariamente, resolvendo um problema pontual, mas, certamente, trará consequências ruins para o ciclo de vida do software. Mais do que isto, acabará prejudicando a mesma pessoa que a implementou!

O fato preocupante é que muitos projetistas confundem agilidade com rapidez, acabando por institucionalizar antipatterns como soluções arquiteturais.

Como nascem os “antipatterns”?

Como toda boa ideia, os “antipatterns” nascem como soluções de problemas arquiteturais ou de projeto. Porém, existem alguns fatores que diferenciam um “antipattern” de uma boa solução, entre eles:

Até mesmo boas soluções podem se transformar em “antipatterns”, devido a inabilidade da equipe em aplicá-la. Só para ilustrar, temos o ditado de Robert Anthony:

Se você encontrar uma boa solução, e ficar muito ligado a ela, a solução se tornará o seu próximo problema.

É fácil identificar quando um “antipattern” está sendo aplicado por uma equipe. Basta começar a questionar a motivação ou a justificativa para seu uso, e começaremos a receber vários argumentos carregados de emoção e subjetividade.

Existe uma grande lista de “antipatterns” em um catálogo, que pode ser acessado em:

c2.com

Como evitar “antipatterns”?

Não se trata apenas de evitar os “antipatterns” tradicionais, ou seja, aqueles que estão listados no catálogo, mas também de evitar que boas soluções se transformem em “antipatterns”. Alguns apressadinhos vão dizer logo: “é só usar o bom senso!

Eu sou radicalmente contra “bom senso”. Por que? Para começar, “bom senso” é o que dizemos quando não sabemos o que devemos recomendar… Além disso, o que é “bom senso” para uns, pode ser uma porcaria para outros. E, finalmente, sempre que ouço a palavra “bom senso”, suspeito de “antipattern”.

Não existe uma fórmula para evitar “antipatterns”, mas eu diria que temos algumas boas medidas:

Entender o problema nos faz buscar uma solução eficaz, ao invés de cair em armadilhas, como “gambiarras” por exemplo. Para isto, temos que “sujar as mãos”, criar provas de conceito e documentar isso.

Antipatterns pessoais

Muitas vezes, os “antipatterns” estão dentro de nós mesmos, logo, a nossa tendência sempre será adotar soluções “discutíveis”. E esses “antipatterns” pessoais podem ser motivados por coisas como: insatisfação, preguiça (de se atualizar) e teimosia. Os principais “antipatterns” pessoais que eu observo são:

Normalmente, atrás de um “antipattern” pessoal bem sucedido, há um Chefe do tipo “se mexer, estraga”.

Antipatterns no café da manhã

Mesmo que você não queira, acaba acordando com “antipatterns” em sua cama, tomando café com eles e dando carona para o trabalho, afinal, “antipattern” é uma parte do que é ser humano. Mas, mesmo assim, temos que lutar contra eles ao invés de simplesmente colocar avisos: “aqui, há monstros!”. Vejamos comportamentos típicos de equipes, especialmente em ambientes de alta subjetividade, como os projetos ágeis:

Normalmente, “Junkyard coding” é praticado em associação com JogarParaAtorcida.

O CargoCultProgramming está mais relacionado ao uso de uma solução sem entender como ela funciona, e o VoodooChickenCoding está mais relacionado ao fato de não podermos explicar como o problema foi solucionado, por exemplo, a simples alteração da ordem de duas linhas de código-fonte resolveu o problema, só não sabemos o motivo.

Conclusão

A Engenharia de Software veio para botar ordem no galinheiro, dando um chute no trazeiro do “bom senso” e do “herói. Aliada às práticas de gestão de projetos (PMI), e de processo (CMMI), pode produzir repetidos casos de projetos bem sucedidos. Porém, tristemente, ainda existem pessoas refratárias a elas. Para estas pessoas, eu digo que não devemos temer a inovação e a crítica, pois, quanto mais nos expusermos a elas, melhor nos tornaremos.

A repetida prática de usar antipatterns é algo que deve ser combatido por todos, e não só pelos Gerentes. Deve começar por nós, Engenheiros de Software, ou seja, aqueles que estão na “frente de batalha” do dia a dia.

E tudo começa com o questionamento. Se você tiver que resvalar para a subjetividade, então, provavelmente, um monstro está nascendo. Mesmo boas soluções podem se tornar “antipatterns”, caso seu uso não seja compreendido, justificado e documentado, com base em critérios bem pensados e aliados ao valor que se deseja agregar ao projeto.