The Hooker Design Pattern

Uma vez que estava revisando um patch de um colega de equipe, tudo estava mais ou menos bem, exceto por uma aula particular feia, longa e misteriosa.

– “Oh, sim. Da ‘Hooker”.
-“O que!?”
-Sim, a prostituta. Esse é o apelido que demos na equipe. É a classe que todos nós tocamos em algum momento.

Cenário

As aulas de prostitutas são estudos de caso interessantes. Para psicólogos. Eles produzem medo, respeito, depressão e, de vez em quando, catástrofes.

Mas o que é um HC? Bem, basicamente é uma classe ubber (centenas ou mesmo milhares de LOC) onde muitas, muitas coisas acontecem. Um HC tende a centralizar várias responsabilidades: transformações, lógica de negócios, métodos de utilidade, manipuladores, métodos de mistério mágico. Tanto faz. Pior ainda. O HC geralmente não tem testes decentes, então tentar refatorá-lo é, no mínimo, perigoso.

…tão? Alguma ideia?

Deixe-me resumir alguns pontos:

  1. NÃO TENTE SER UM HERÓI . Não tente consertar “de uma vez por todas”. É perigoso. E suas boas intenções podem acabar com seu chefe chutando sua bunda.

  2. O HC tem muitos testes? Se for esse o caso, você tem sorte. Se não, analise quem está usando HC. Tente identificar as responsabilidades. E finalmente comece a criar testes para o HC.

  3. Somente quando você tiver uma boa quantidade de testes, comece a refatorá-lo.

  4. Solicite várias revisões de código. Especialmente de desenvolvedores que deram um toque e vão com ele.

  5. Deixe seu gerente, líder técnico, proprietário do produto, etc. saber o que você deseja fazer. Peça permissão. Peça uma história de usuário para lidar com a “dívida técnica”. Evite o desenvolvimento da sombra. É arriscado e as pessoas vão culpar você se algo der errado.