5 Lições de Design Orientado a Objetos da Sandi Metz

Por Jessie Young.

Esta é uma tradução do artigo escrito por Jessie Young e publicado em: https://18f.gsa.gov/2016/06/24/5-lessons-in-object-oriented-design-from-sandi-metz/

Foto obtida no Gratisography

1. O propósito do design é reduzir o custo da mudança

Essa lição é semelhante à ideia de refatorar o código de modo que ele possa “mudar para sempre”, mas focada no valor de negócio de tornar o código fácil de mudar. Muitas pessoas pensam na refatoração como uma etapa bônus ou algo que eles farão “depois, quando houver tempo”. Mas a refatoração constante é central para os objetivos de qualquer organização que produz software. Sem refatoração, você não consegue ter software bem-arquitetado. Software bem-arquitetado é mais fácil de mudar. Coisas que são mais fáceis de mudar consomem menos tempo. Menos tempo significa menos dinheiro gasto.

2. Busque o verde mais fácil de alcançar

No nosso primeiro exercício do curso, a Sandi nos pediu para escrever um script em Ruby para fazer com que um arquivo de testes passasse. Esse script precisava cantar qualquer verso da canção “99 bottles of beer on the wall”, dado o número do verso.

class Bottles
def verse(number)
if number - 1 == 0
next_number = "no more"
else
next_number = number - 1
end
if number - 1 == 1
next_bottle = "bottle"
else
next_bottle = "bottles"
end
if number == 1
bottle = "#{number} bottle"
elsif number == 0
bottle = "no more bottles"
else
bottle = "#{number} bottles"
end
if number == 1
pronoun = "it"
else
pronoun = "one"
end
if number == 0
second_verse = "Go to the store and buy some more, " +
"99 bottles of beer on the wall.\n"
else
second_verse = "Take #{pronoun} down and pass it around, " +
"#{next_number} #{next_bottle} of beer on the wall.\n"
end
"#{bottle.capitalize} of beer on the wall, " +
"#{bottle} of beer.\n" +
second_verse
end
end

É hora do verde desavergonhado

Quando nós terminamos este exercício, Sandi nos ensinou sobre o conceito do “verde desavergonhado”: faça a coisa mais simples possível para fazer os testes passarem (ficarem verdes). Esse estado é chamado de verde “desavergonhado” porque o seu objetivo é só fazer os testes passarem, e nada mais. Você pode estar com vergonha do código que você escreveu para fazer isso, porque ele parece simples demais para ter sido escrito por alguém do seu nível intelectual. Então, e somente então, você pode abstrair a lógica.

class Bottles
def verse(number)
case number
when 0
"No more bottles of beer on the wall, no more bottles of beer.\nGo to the store and buy some more, 99 bottles of beer on the wall.\n"
when 1
"1 bottle of beer on the wall, 1 bottle of beer.\nTake it down and pass it around, no more bottles of beer on the wall.\n"
when 2
"2 bottles of beer on the wall, 2 bottles of beer.\nTake one down and pass it around, 1 bottle of beer on the wall.\n"
else
"#{number} bottles of beer on the wall, #{number} bottles of beer.\nTake one down and pass it around, #{number-1} bottles of beer on the wall.\n"
end
end
end

3. A duplicação é muito mais barata do que a abstração errada

Um motivo pelo qual é tão difícil começar pelo verde desavergonhado é que geralmente ele inclui uma grande quantidade de duplicação. Pense da seguinte maneira: um jeito de resolver o problema das 99 garrafas seria escrever um método de 202 linhas que retorna uma string completamente diferente para cada número recebido. Na primeira vez que tentei resolver o problema, eu fui na direção completamente oposta: zero duplicação. E meu código imediatamente se tornou difícil de entender.

4. Refatorar código deveria ser seguro e chato

Todos os métodos da Sandi dependem de ter uma suíte de testes que te diz se o seu código está funcionando conforme o esperado. Muitos programadores conhecem o adágio “vermelho, verde, refatorar”. Isso significa que você começa com um teste que falha (vermelho), escreve código para fazê-lo passar (verde), então muda o código para torná-lo melhor (refatorar).

“Vermelho, verde, verde infinito”

Na aula de design orientado a objetos da Sandi, seguimos um padrão estrito ao refatorar, que eu gosto de chamar de “vermelho, verde, verde infinito”. Nesse processo, começamos com testes que falham, fazemos com que eles passem (com o verde desavergonhado), e então refatoramos. Mas durante nossa refatoração, nós rodamos os testes depois de cada . uma . das . mudanças. Isso significa que você não pode mover o código para uma nova pasta e excluir ele no lugar anterior e então rodar os testes. Primeiro você copia o código e cola ele na nova localização. Então você roda os testes. Se eles ainda estiverem passando, então você avança para a próxima mudança. Se a qualquer momento os testes falharem, você desfaz a última mudança, assegura-se de que os testes estão verdes novamente, e então faz uma alteração diferente que permite que a suíte de testes permaneça verde. Se essa mudança diferente passar, então você pode partir para a próxima. E assim por diante.

5. Escreva o melhor código possível hoje, seja completamente desapegado dele e esteja disposto a apagá-lo amanhã

É fato: os programadores gastam muito mais tempo mudando código que já existe do que escrevendo código novo. Enquanto gastamos um tempão pensando sobre novas funcionalidades excitantes, a realidade é que a maior parte do nosso trabalho envolve mudar coisas que já estão aí. Até mesmo aqueles que estão em repositórios relativamente novos raramente se veem escrevendo código que não requer mudanças no código existente. Muitas vezes, o código existente é algo que nós mesmos escrevemos. Talvez há meses. Talvez há dias. Talvez até há algumas horas.

Software development nerd. In 💙 with Ruby, PHP, JavaScript, Crystal, and other techy stuff.

Software development nerd. In 💙 with Ruby, PHP, JavaScript, Crystal, and other techy stuff.