Cover

Ruby é uma linguagem de programação projetada para ser simples e fácil de aprender, e essa simplicidade se estende à sua estrutura de framework, o Ruby on Rails. Ao contrário de outras linguagens de programação, onde a complexidade muitas vezes domina, Ruby on Rails incentiva a escrita de código limpo e fácil de entender. Uma das maneiras pelas quais isso é alcançado é através da extração de regras de negócio em POROs. Ao usar POROs, o desenvolvedor podem manter a lógica do negócio em um local separado do restante do código, tornando-o mais fácil de gerenciar e manter. Neste post, irei explorar a simplicidade do Ruby e como ela se traduz em boas práticas de programação em Ruby on Rails.

Fotografia de Jupiter

👉🏻 Fiz essa foto com meu celular durante minhas férias em Viçosa-CE.

class PersonForm
  attr_accessor :age, :name, :birthday, :favorit_color

  def initialize(params = {})
    @age = params[:age]
    @name = params[:name]
    @birthday = params[:birthday]
    @favorit_color = params[:favorit_color]
  end

  def call!
    # Do some cool stuff
  end
end

person = PersonForm.new(age: "92", name: "Buzz Aldrin", birthday: "20-01-1930")

person.age
# => "92"

person.birthday
# => "20-01-2930"

person.favorit_color
# => nil

Com isso, já seria possível isolar coisas como: validações personalizadas; definir atributos padrões; normalizar parâmetros e etc.

Agora, perceba que o atributo age e birthday retornam strings. Uma forma de melhorar isso seria fazer algo como:

require 'date'

class PersonForm
  attr_accessor :age, :name, :birthday, :favorit_color

  def initialize(params = {})
    @age = params[:age].to_i
    @name = params[:name]
    @birthday = Date.parse(params[:birthday])
    @favorit_color = params[:favorit_color]&.strip || 'red'
  end

  def call!
    # Do some cool stuff
  end
end

person = PersonForm.new(age: '92', name: ' Buzz Aldrin ', birthday: '20-01-1930')

person.age
# => 92

person.birthday
# => <Date: 1930-01-20 ((2425997j,0s,0n),+0s,2299161j)>

person.favorit_color
# => "red"

Muito bom! Agora, se você estiver usando Rails, pode ficar ainda melhor.

ActiveModel::Attributes

Se você usa Ruby on Rails, então você usa o AvtiveModel::Attributes a todo momento. Isso, porque toda vez que você usa o ActiveRecord ele, internamente, faz uso do módulo Attributes para fazer cast de dados como Date, Float, DateTime.

Um exemplo do outro código seria algo como:

class PersonForm
  include ActiveModel::Model
  include ActiveModel::Attributes

  validates :name, presence: true

  attribute :age, :integer
  attribute :name, :string
  attribute :birthday, :date, default: -> { Date.new }
  attribute :favorit_color, :string, default: 'red'

  def call!
    # Do some cool stuff
  end
end

person = PersonForm.new(age: '92', name: 'Buzz Aldrin', birthday: '20-01-1930')

person.age
# => 92

person.birthday
# => <Date: 1930-01-20 ((2425997j,0s,0n),+0s,2299161j)>

person.favorit_color
# => "red"

person = PersonForm.new(age: '92', name: nil, birthday: '20-01-1930')

person.valid?
# => false

person.errors.full_messages
# => ["Name can't be blank"]

Como disse antes, simples e elegante.

A cereja do bolo 🍒

Eu diria que, uma tendência, principalmente em desenvolvedores com poucas horas de voo, é cair na armadilha de criar abstrações muito prematuramente, e isso não é nenhum segredo. Há, só pra lemnbrar o ActiveModel::Attributes não é algo “novo”.

  • Cuidados com Gemas(libs) externas

    Tem um framework no meu framework

    Amarrar toda sua codebase em bibliotecas externas também é algo perigoso. O Ruby on Rails já entrega uma gama extraordinária de implementações de alto nível e mantido por desenvolvedores muito bons/experientes.

  • Evite soluções ouver enginer

    Fique atento para não criar uma sobrecarga desnecessária e transformar algo simples em algo complexo.

    Overengineering (ou over-engineering),[1] é o ato de projetar um produto ou fornecer uma solução para um problema de maneira elaborada ou complicada, onde uma solução mais simples pode ser demonstrada com a mesma eficiência e eficácia que a de o projeto original.[2]

  • Faça funcionar primeiro

    Foque no simples, faça funcionar primeiro. Algo importante, e que é necessário ficar atento, é que não há problemas em, inicialmente, manter duplicidade de código. Lembre-se de que abstrações prematuras, ou mal elaboradas, podem acabar se transformando em armadilhas.

Conclusão

Embora seja tentador adicionar mais tecnologias e frameworks aos nossos projetos, é importante lembrar que a simplicidade é muitas vezes a chave para escrever e manter um bom código. Ao se concentrar no negócio em si e pensar de forma simples, podemos evitar a armadilha de sobrecarregar nossos projetos com tecnologias desnecessárias. Em vez disso, devemos focar em escrever código limpo e fácil de entender, usando ferramentas como POROs para extrair a lógica de negócios em um local separado. Ao fazer isso, podemos criar projetos mais gerenciáveis e sustentáveis a longo prazo. Lembre-se sempre de pensar simples e manter o foco no negócio em si.

Referências