— Se você está procurando uma discussão sobre Big-O e Big-Ω, veja esse post AQUI

Suponha que você chega para uma consulta médica (médico nunca te atende no horário) e tem apenas você e mais uma pessoa na sala de espera. Suponha também que você achou essa pessoa linda e gostaria MUITO de descobrir o nome dessa pessoa. Eis portanto meu desafio para você:

Como que você descobre o nome dessa pessoa?

Existem inúmeras maneiras de fazer isso. Você pode tentar achar a ficha médica da pessoa pela foto e achar o nome.

Você pode ver se a pessoa fez check-in no Facebook no consultório médico (acreditem, pessoas fazem isso).

Também seria possível ir até a recepcionista e perguntar quem aquela pessoa é.

Ou ainda você pegar a carteira da pessoa enquanto ela não está olhando, achar um documento de identificação e encontrar o nome - bem bacana e bem criminoso.

Ou você pode, veja só que loucura, ir até a pessoa e perguntar o nome dela (recomendo iniciar começar uma conversa antes para quebrar o gelo mas se você pensou seriamente em roubar a carteira dela para pegar um RG, isso é de menos).

Todos esses "métodos", ignorando sua plausibilidade e/ou ilegalidade, possuem o mesmo objetivo - descobrir o nome da pessoa. Ou seja, o que você está procurando fazer em todos os casos é a mesma coisa, chegar na mesma resposta.

O que difere um método do outro, além dos potenciais anos de prisão, é a dificuldade de executar cada um deles. Para cada exemplo e considerando que todos dariam "certo" (i.e. descobrir o nome), você teria mais ou menos trabalho para chegar no mesmo resultado desejado.

Portanto a pergunta que você pode se fazer é por que você faria mais trabalho se eu vou chegar exatamente no mesmo lugar?

Quando falamos de software e o produto criado a partir do uso dele, a aplicação (ou na nossa fala vulgar, o programa), o que estamos fazendo sempre é criando algo que tem um objetivo específico. Mas o interessante é que para chegar nesse objetivo desejado, existe mais que uma maneira. Aliás, arrisco dizer que não existem apenas duas ou três ou dez formas de chegar lá. Geralmente, existem infinitas maneiras diferentes de chegar na solução.

Muitas pessoas se assustam com o mundo do software porque ele é um mundo de abstração. Você não pega nada, não toca nada e não existem limites óbvios, portanto usar ele como ferramenta te abre um mundo infinito de possibilidades e é sua responsabilidade procurar um caminho, dentre esses inúmeros caminhos, que vão te levar à solução.

Então isso te leva logicamente à próxima pergunta:

Se existem infinitas caminhos para chegar numa solução, qual que eu devo escolher?

Uma possível resposta para isso seria escolher o caminho com o melhor desempenho. Desempenho nesse contexto vai significar algo como performance, velocidade e tempo de execução (i.e. quanto tempo demora para "rodar" e chegar na solução) e essa não é uma resposta ruim mas existem alguns problemas com a busca por essa solução otimizada:

1. Como ter certeza que nossa solução é a solução com maior desempenho? Existe uma forma de comprovar isso?
2. Quando você foca em desempenho, geralmente você pensa no processo de otimização mais do que na resolução do problema que originalmente se propôs a resolver.

Porra! Mas então o que que você sugere, Professor?

Talvez o mais interessante desse questionamento é que ele tem uma resposta empírica e normalmente quem já está nessa área faz algum tempo vai concordar com isso. Dentre duas possíveis soluções, que geram o mesmo resultado e com desempenho comparáveis, escolha sempre a que for mais simples.

Dada duas ou mais opções, escolha a mais simples.

Eu não posso enfatizar esse ponto suficiente - ESCOLHA O SIMPLES.

Soluções simples tem inúmeras vantagens, algumas óbvias e outras nem tanto. Uma solução simples vai te dar valor:

1. Na implementação: raciocinar e criar código para algo simples é mais fácil e consequentemente mais rápido;
2. Na manutenção: aceite isso antes que seja tarde demais - você VAI PRECISAR voltar e mexer no seu código um dia. Se não você, o coitado do próximo desenvolvedor. Quanto mais simples um código é, mais simples é sua manutenção porque demora muito menos para alguém compreender e poder começar a mexer;
3. No commit: fazer review de PR pode ser divertido e poder ser um porre. Revisar um PR simples e limpo é extremamente mais agradável e rápido;
4. Na refatoração, nos testes, na expansão, etc.

Enfim, a lista pode ir longe. Portanto, na sua próxima decisão sobre desenvolvimento e como prosseguir com um pedaço pequeno, médio ou gigantesco do seu projeto, carregue sempre com você essa bússola lógica de escolher os caminhos mais simples de progressão e durma melhor de noite 🌚