DEV Community: Diego Linhares

O dia em que descobri meu impacto: pequenas contribuições, grandes revelações

Diego Linhares — Tue, 08 Apr 2025 00:46:56 +0000

Uma das experiências mais marcantes que vivi na Tropical on Rails? Não, não foi conhecer pessoalmente o Chris Oliver, a nossa Taylor Swift dos devs Rails. Foi algo muito mais inesperado: quando uma pessoa iniciante na carreira se aproximou e perguntou se eu era o Diego Linhares, contando o quanto curtia meus comentários nos grupos de Ruby/Rails.

Sempre me considerei uma pessoa discreta. Talvez isso venha da infância – sendo mais alto que a maioria, inevitavelmente chamava atenção por onde passava, algo que me deixava desconfortável. Com o tempo, desenvolvi esse jeito mais reservado, preferindo observar a ser observado.

Essa tendência à discrição explica por que nunca me interessei em dar palestras ou escrever artigos; além da minha natural aversão aos holofotes, carrego aquela sensação persistente de que não tenho nada extraordinário para compartilhar. Em vez disso, prefiro fazer pequenas contribuições através de trocadilhos e comentários divertidos nos grupos – um jeito mais leve de participar sem me expor demais.

Como muitos de nós na área tech, convivo diariamente com a Síndrome do Impostor martelando na mente, aquela voz que insiste que não sou bom o suficiente, por mais que as evidências mostrem o contrário. É justamente essa síndrome que me faz hesitar antes de cada comentário nos grupos, questionando se realmente vale a pena compartilhar meu pensamento ou se estou só "poluindo" a discussão. Talvez tenha sido justamente essa combinação – minha natural discrição e a constante autodúvida – que tornou aquele simples reconhecimento algo tão impactante para mim.

Esta jornada entre a insegurança e a contribuição é o que tornava ainda mais surpreendente o fato de que, durante nossa conversa, essa pessoa me contou que costuma acompanhar os comentários nos grupos e aprender com eles — exatamente como eu fazia anos atrás, quando estava expandindo meus conhecimentos. Mesmo quando os assuntos eram complexos e eu entendia pouco, continuava observando, lendo e, aos poucos, as conexões iam acontecendo na minha mente. Esse contato constante foi essencial para meu crescimento profissional. Saber que hoje meus próprios comentários podem estar inspirando alguém do mesmo jeito me traz uma alegria imensa.

Essa dinâmica de aprendizado contínuo e compartilhamento levou a outra questão durante nossa conversa. Ela também me perguntou algo que frequentemente escuto: como consigo acompanhar os grupos, ter paciência para participar, ajudar outras pessoas e ainda dar conta das tarefas do dia a dia? (Hoje só participo ativamente do grupo ADA.rb, pois tenho dedicado tempo a outras prioridades). Essa dúvida não é incomum e surge bastante em conversas com quem me conhece melhor.

Minha resposta a esse questionamento vem de um valor que trago desde cedo, muito influenciado pelos meus pais: se consigo fazer alguém se sentir melhor ou ajudar essa pessoa a melhorar só 1% no dia, já sinto que cumpri meu papel. Este princípio do "1% melhor" é o que me manteve participando daqueles grupos mesmo quando o tempo era escasso, porque entendi que um pequeno comentário poderia ser exatamente o que alguém precisava para superar um obstáculo – assim como tantos comentários me ajudaram no passado. Para mim, essas pequenas contribuições são como semear mudanças que crescem além da nossa visão.

Como dizia Jobs: "As pessoas loucas o suficiente para achar que podem mudar o mundo são as que o fazem." Não é preciso ser extraordinário ou buscar holofotes para fazer diferença – isso eu aprendi claramente naquela ocasião na Tropical. Cada pequena contribuição – seja um comentário esclarecedor, uma dica técnica ou um simples incentivo – tem poder multiplicador. É gratificante ver como essas ações diárias impulsionam o crescimento alheio. Nos momentos difíceis, quando seria mais fácil ficar calado ou guardar conhecimento para mim, lembro: estamos construindo pontes, não muros. Escolher compartilhar em vez de reter, conectar em vez de isolar, é o que realmente faz a diferença em nossa comunidade.

Recapitulando esse ciclo de contribuição, foi com essa filosofia em mente que aquele momento na Tropical ganhou um significado especial. Percebi algo que nunca havia considerado: sem pretensão alguma, eu me tornara parte daquele mesmo ciclo que sempre admirei. O mais surpreendente não foi apenas ver alguém valorizando meus comentários, mas me ver do outro lado – não apenas como quem aprende, mas também como quem inspira. Nunca esperei ser fonte de aprendizado para alguém, e essa realização me ensinou algo valioso sobre nossa comunidade. Nesse dia, pelo menos por algumas horas, minha Síndrome do Impostor dormiu um pouco.

Essas reflexões me levam a duas conclusões importantes: Para quem está começando, suas dúvidas de hoje serão as respostas que você compartilhará amanhã. E para quem, como eu, às vezes subestima seu próprio impacto, aquele comentário que você fez sem pensar muito pode ser exatamente a centelha que alguém precisava para avançar.

Afinal, o que construímos juntos, muitas vezes sem sequer perceber, transcende qualquer linha de código que escrevemos. Quando olho para trás, para aquele garoto que ficava horas tentando entender o que era um yield em Ruby, nunca imaginaria que um dia estaria do outro lado da moeda. E essa jornada cíclica – aprender hoje, compartilhar amanhã, inspirar sempre – mais que qualquer PR aprovado ou feature entregue, é o que realmente importa.

PS: Texto escrito após 5 xícaras de café enquanto esperava meu voo na madrugada. Se encontrarem algum bug, podem abrir uma issue.

Open Closed Principle (OCP) - Flexível como os Vingadores

Diego Linhares — Sun, 10 Sep 2023 03:43:54 +0000

Introdução

O Princípio Aberto/Fechado (OCP, na sigla em inglês) é uma das regras fundamentais para escrever um código sólido. Este princípio estabelece que as classes de software devem ser abertas para extensão, mas fechadas para modificação.

Imagine que cada Vingador tenha sua própria missão e habilidade especial. Quando um novo Vingador se junta à equipe, ele não muda a forma como os outros funcionam; ele simplesmente traz algo novo.

Assemble!

Se você tiver uma classe que determina o que cada Vingador faz ao atacar e essa classe precisar ser alterada sempre que um novo Vingador chegar, você está descumprindo o OCP:

class Vingador
  def initialize(tipo)
    @tipo = tipo
  end

  def atacar
    if @tipo == "CapitaoAmerica"
      puts "Lançando o escudo!"
    elsif @tipo == "Thor"
      puts "Lançando o martelo!"
    end
  end
end

Para corrigir isso, você pode usar herança ou composição.

# Usando herança
class Vingador
  def atacar
    puts "Cada Vingador ataca de um jeito!"
  end
end

class CapitaoAmerica < Vingador
  def atacar
    puts "Lançando o escudo!"
  end
end

class Thor < Vingador
  def atacar
    puts "Lançando o martelo!"
  end
end

# Usando composição
class AtaqueComEscudo
  def executar
    puts "Lançando o escudo!"
  end
end

class AtaqueComMartelo
  def executar
    puts "Lançando o martelo!"
  end
end

class Vingador
  def initialize(ataque)
    @ataque = ataque
  end

  def atacar
    @ataque.executar
  end
end

capitao_america = Vingador.new(AtaqueComEscudo.new)
thor = Vingador.new(AtaqueComMartelo.new)

capitao_america.atacar  # Saída: "Lançando o escudo!"
thor.atacar  # Saída: "Lançando o martelo!"

Vamos analisar o que podemos aprender com duas diferentes equipes de Vingadores.

#TeamHerança: A Equipe Rígida

Nessa equipe os Vingadores possuem uma regra estrita: todo novo membro deve ser capaz de voar e disparar lasers. Todo novo Vingador herda certas habilidades, mas também limitações. Se o Hulk entra para a equipe, teremos um problema: ele não voa nem dispara lasers. Ele tem suas próprias habilidades únicas. Cada herói está "preso" às regras da equipe.

Acoplamento Forte: As classes filhas estão intimamente ligadas à classe pai. Qualquer mudança na classe pai pode ter efeitos indesejados nas classes filhas.
Hierarquia Complexa: À medida que o projeto cresce, manter uma hierarquia de classes coerente pode se tornar um desafio.
Rigidez: A herança torna difícil adicionar funcionalidades que não se encaixam na estrutura existente.

#TeamComposição: A Equipe Flexível

Imagine se os Vingadores aceitassem heróis com todo tipo de habilidade. Precisa de alguém que seja bom em espionagem? Chame a Viúva Negra. Precisa de alguém que possa manipular o tempo? Chame o Doutor Estranho. Cada herói pode ser adicionado à equipe com suas habilidades únicas.

Você pode adicionar novas "peças" (classes ou métodos) ao seu projeto, dependendo do que você precisa. Cada herói pode ser ele mesmo, e a equipe pode se adaptar facilmente a novos desafios.

Baixo Acoplamento: Cada classe ou componente é uma unidade independente que pode ser facilmente substituída ou atualizada.
Alta Coesão: Cada classe tem uma única responsabilidade, tornando o código mais legível e manutenível.
Flexibilidade Extrema: Novas funcionalidades podem ser adicionadas facilmente como novos componentes, sem afetar o sistema existente.

Reflexões

A composição oferece mais flexibilidade do que sistemas com regras estritas. Se surgir uma nova ameaça, uma equipe flexível pode rapidamente incorporar um novo membro com habilidades específicas, evitando a necessidade de reavaliar todas as regras existentes.

Muitos desenvolvedores, incluindo eu, preferem a composição à herança para implementar o OCP. A composição promove baixo acoplamento, tornando mais fácil e menos arriscado adicionar novas funcionalidades. Em sistemas pouco acoplados, mudanças em uma parte não afetam as demais, facilitando o entendimento, o teste e a manutenção do código.

Essa modularidade é semelhante à forma como os Vingadores operam: cada herói pode funcionar de forma independente, mas também em conjunto quando necessário. Isso evita a complexidade e os riscos associados a sistemas fortemente acoplados, onde mudanças em uma parte afetam todo o sistema.

Ah vida real

A herança permite estender classes de forma clara, mas cria acoplamento forte entre a classe base e suas subclasses, tornando o sistema menos adaptável e mais complexo para novos desenvolvedores.

Em contraste, a composição oferece grande flexibilidade. Em um sistema de pagamento online, por exemplo, você pode começar com uma API como o Stripe e facilmente adicionar outras como o PayPal. Isso é feito simplesmente criando uma nova classe com a mesma interface de pagamento (pense na "interface de pagamento" como um conjunto de regras ou instruções que todos os métodos de pagamento devem seguir, como "aceitar pagamento" ou "dar troco").

Embora a flexibilidade nem sempre seja necessária, ela se torna valiosa em um mundo imprevisível, permitindo que o sistema se adapte facilmente a novas circunstâncias.

Conclusão

O OCP não é apenas uma regra técnica, mas uma filosofia de design que encoraja a preparação para o imprevisível. Ele nos ensina a construir sistemas tão flexíveis e independentes quanto os Vingadores, prontos para se adaptar a novas situações e desafios sem reestruturar o que já funciona bem.

A escolha entre herança e composição não é apenas uma questão técnica, mas também uma decisão estratégica que pode determinar o quão ágil e adaptável seu sistema será. Enquanto a herança nos aprisiona em uma estrutura predefinida, a composição nos dá as ferramentas para construir sistemas verdadeiramente modulares e de fácil manutenção.

Então, da próxima vez que você se encontrar diante de um desafio de programação, pergunte-se: "Como posso tornar esse sistema mais flexível e menos acoplado?" A resposta pode não apenas melhorar o seu código, mas também prepará-lo para um futuro cheio de possibilidades desconhecidas.

Single Responsibility Principle (SRP) - Pense como um vingador

Diego Linhares — Thu, 07 Sep 2023 20:49:30 +0000

Introdução

O Princípio da Responsabilidade Única (SRP) é um dos princípios SOLID do design de software orientado a objetos. Popularizado por Robert C. Martin, ou Uncle Bob, o SRP nos diz que cada classe deve ter apenas uma "razão para mudar". Vamos explorar esse conceito usando o exemplo dos Vingadores.

Cada herói dos Vingadores tem uma habilidade única que define sua "especialidade". O Homem de Ferro é um gênio da tecnologia, Thor é um deus com poderes mágicos, e a Viúva Negra é uma espiã habilidosa.

Todas as ações de cada herói estão alinhadas com essa especialidade única:

# Homem de Ferro e sua especialidade em tecnologia
class HomemDeFerro
  def disparar_misseis
    puts "Disparando mísseis!"
  end

  def voar
    puts "Voando alto!"
  end
end

# Thor e seus poderes Asgardianos
class Thor
  def usar_martelo
    puts "Martelo lançado!"
  end

  def convocar_raio
    puts "Convocando um raio!"
  end
end

# Viúva Negra e sua habilidade em espionagem
class ViuvaNegra
  def espionar
    puts "Coletando informações secretas."
  end

  def lutar
    puts "Lutando habilmente."
  end
end

Coesão no design de software e domínio de negócios

O design de software não é uma ciência exata onde você pode simplesmente contar "responsabilidades". O que importa é a coesão, que se refere a quão bem as partes de um sistema trabalham juntas para formar um todo unificado. Em um código coeso, cada classe ou módulo tem uma responsabilidade claramente definida e todas as suas funções e variáveis contribuem para essa responsabilidade.

A coesão também deve ser entendida no contexto do domínio de negócios. Por exemplo, todas as habilidades do Homem de Ferro fazem sentido dentro do contexto de ser um gênio da tecnologia. Se esse contexto mudar, o que era coeso pode de repente não ser mais.

class HomemDeFerro
  # ...
  # Adicionando uma nova habilidade defensiva :)
  def ativar_escudo
    puts "Ativando escudo de energia!"
  end
end

Quando a coesão é perdida

Suponha que o Homem de Ferro ganhe a habilidade de prever o futuro. Isso seria uma violação do SRP, pois essa nova habilidade não tem relação com sua especialidade em tecnologia.

# Homem de Ferro perdendo a coesão
class HomemDeFerro
  # Aí ta troll. Isso é papel do Dr. Estranho :(
  def prever_o_futuro
    puts "Prevendo o futuro!"
  end
end

Conclusão

O SRP serve como uma orientação para criar sistemas mais robustos e confiáveis. Adicionar habilidades ou tarefas não alinhadas com a responsabilidade única pode tornar o sistema menos coeso e mais difícil de gerenciar.

Ao refatorar seu código, pense como um Vingador: qual é a sua "especialidade", e como você pode tornar seu código mais coeso dentro desse contexto?