O que a máquina de Rube Goldberg nos ensina sobre programação?

Rube Goldberg foi um cartunista, engenheiro, escultor, autor e invetor americano (eu utilizo javascript, então ganhei). Ele é conhecido por seus desenhos populares que retratam aparelhos intencionalmente complicados realizando tarefas simples de maneira excessivamente complicada.

Na imagem acima, podemos ver uma das suas maravilhosas invenções, uma complicada máquina que automatiza uma simples tarefa de utilizar o guardanapo. Eu gostaria de experimentar uma sem quebrar o meu pescoço.

Em 1966 o termo "Rube Goldberg" foi publicado no Random House Dictionary of the English Language com o significado "tortuosamente complexo e impraticável".

Mas qual é a lição que podemos aprender com Rube Goldberg e aplicá-la no nosso código?

A resposta é óbvia, "não trate como constante quem te trata como variável". Brincadeira, não é essa a lição que podemos aprender mas foi o que li hoje em um site de coaching para programadores.

A resposta é que por vezes projetamos o nosso código de uma maneira mais complexa do que o necessário, muitas vezes excessivamente complicada, em um contexto onde uma simples solução resolveria o problema com eficiência.

Acabamos por praticar, sem más intenções, o que chamamos de over engineering, que para mim a melhor definicição é: "código que resolve problemas que você não tem".

Considere o código retirado de uma máquina de Rube Goldberg (é verdade esse "bilete"):

<ul>
  {
    ['Home', 'Sobre', 'Contato'].map((item) => (
      <li key={item}>
        {item}
      </li>
    ))
  }
</ul>

E a sua versão equivalente:

<ul>
  <li>Home</li>
  <li>Sobre</li>
  <li>Contato</li>
</ul>

Seja sincero, se você construisse esse menu, qual opção você escolheria? Se você respondeu a primeira, qual foi o argumento que te levou a essa decisão?

1. Eu posso precisar disso mais tarde se o cliente decidir tornar o menu dinâmico.
2. É assim que os experts fazem.
3. Quero parecer um programador profissional.
4. Não gosto do meu coleguinha que faz code review.

O que causa over engineering?

Muitas vezes o excesso ocorre porque tentamos antecipar o futuro desconhecido. Preparar o código para algo que será implementado em breve é planejamento, mas preparar para algo incerto é sofrer por antecipação.
Não existe código a prova de futuro e não devemos pensar nisso na hora de desenhar o nosso sistema, pois a tendência é aumentar e muito a complexidade.
Um ponto que acentua a nossa tendência a se proteger das incertezas é a falta de requesitos. Não existe viagra rémedio milagroso para esse caso, se não está bem definido não avançamos ou avançamos com o escopo atual; evoluir e refatorar é um processo que devemos enxergar como natural na engenharia de software.

Para você que respondeu a opção 2 ou 3, gostaria de dizer que não é assim que os mais experiêntes o fazem, pelo menos os que ainda possuem sanidade mental e juízo. Provavelmente muitos programadores seniors possuem a cara queimada, porque em algum momento a bomba explodiu na nossa cara. A complexidade desnecessária é como o amor impossível, dá muito trabalho e quem sofre no fim é você.

A medida que um programador ganha experiência, a tendência é manter o código o mais simples possível, por isso não crie ilusões com códigos complexos. Se você está a começar não ache que o primeiro exemplo é o ideal para aprender, domine e faça bem primeiro o simples. Lembre-se, toda a complexidade deve ter razão plausível pra existir, caso contrário você está a criar um problema e não a resolvê-lo.