Cobertura InterCon18: Construindo aplicações mais confiantes

Na sala Dennis Ritchie, a desenvolvedora de software e organizadora do Ruby↳Ruby3 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019Refatoração em RubyDev (Back & Front) · mai 20197 exemplos de linguagens de programação server-sideGestão Dev & TI · jun 2024Ver tudo em Dev (Back & Front) → Ladies, Carolina Karklis subiu ao palco para demonstrar a refatoração de um sistema frágil e apresentar estratégias dentro do paradigma de orientação objetos para escrever código de forma mais simples e confiante.

Para começar a apresentação, Carolina explicou que a sua motivação para dar a palestra veio do livro Confident Ruby, de Avdi Grimm e mostrou uma lista de códigos não considerados confiantes, exploradas por ela ao longo da apresentação.

Code Smells

• Método MacGyver
• Excesso de condicionais
• Excesso de type checking
• Nil driven development

O primeiro exemplo foi o MacGyver, descrito por ela como um método que começa com cinco linhas, depois vai pra sete e acaba ficando maior.

Ela apresentou o problema desse método e a solução:

Problema: métodos longos que fazem muita coisa
Solução: identificar mensagens e pepéis, separando o código em partes menores

Em seguida, a desenvolvedora falou sobre um sistema legado de registro de compras.

Ela explica que, em resumo, precisamos de um método para migrar os dados de um sistema legado para um novo. Um bom método pode ser separado em quatro partes para que um método conte uma boa história. Primeiro você coleta input, realiza o trabalho, entrega o output e por fim lida com as falhas.

Na metade de sua apresentação ela explicou o conceito de Mensagens = Ações e quais são as responsabilidades das mensagens.

“É importante saber que cada mensagem precisa de um responsável para que ela seja entregue. Podemos ter o mesmo papel em classes diferentes, mas sabemos onde está o domínio dessa responsabilidade”.

Excesso de condicionais e type checkings traz os seguintes problemas:

• Causa desordem e remove a linearidade no código
• Torna-se difícil de testar e manter
• Embute responsabilidades e conhecimentos desnecessários

A palestrante também apresentou três soluções divididas em estratégias específicas:

• Coagir objetos para que façam o que precisa ser feito
• Rejeitar valores inesperados de maneira mais eficiente
• Substituir inputs por valores válidos

Nil Driven Development

Ao falar de nil driven development, Carolina afirmou que criamos cenários de que tudo é possível e reforçou a diferença de programar em funcionais.

Para encerrar sua apresentação, ela apresentou seis dicas finais:

• Converta de maneira implícita
• Use conversões do módulo Kernel para outros tipos
• Defina suas próprias conversões para tipos definidos
• Não pergunte pelo tipo de objeto, peça a permissão
• Aprenda a usar structs e crie um padrão para seu sistema
• Não use nil e não passe nil