Restavam quinze minutos. Eu sabia que não conseguiria.

Passei dois meses estudando para minha primeira entrevista técnica.

Achei que estava preparada, mas, quando a entrevista estava chegando ao fim, percebi: eu não tinha a menor ideia de como resolver os problemas de programação.

Entre todos os tutoriais que vi quando estava aprendendo a programar, nenhum deles incluía uma abordagem para resolver problemas de programação.

Eu tinha que encontrar um método para resolver problemas – minha carreira como desenvolvedora dependia disso.

Imediatamente, comecei a pesquisar métodos. Encontrei um. De fato, o que descobri foi uma estratégia inestimável. Era um método em quatro etapas testado pelo tempo que, de algum modo, estava fora do radar no ecossistema de desenvolvedores.

Neste artigo, abordarei esse método de solução de problemas em quatro etapas que você pode usar para começar a resolver problemas de programação com confiança.

A solução de problemas de programação não é apenas parte do processo de entrevista de emprego para desenvolvedores – é o que um desenvolvedor faz o dia todo. Afinal de contas, escrever código é resolver problemas.

Um método para solucionar problemas

Esse método foi extraído do livro How to Solve It, de George Pólya. Ele foi lançado originalmente em 1945 e já vendeu mais de um milhão de cópias.

Seu método de solução de problemas tem sido usado e ensinado por muitos programadores, desde professores de ciência da computação (veja o curso Intro to CS, da Udacity, ministrado pelo professor David Evans) até professores modernos de desenvolvimento da Web, como Colt Steele.

Vamos solucionar um problema simples de programação usando o método de solução de problemas em quatro etapas. Isso nos permite ver o método em ação à medida que aprendemos. Usaremos JavaScript como nossa linguagem de escolha. O problema é o seguinte:

Crie uma função que some dois números e retorne esse valor.

Há quatro etapas no método de solução de problemas:

1. Compreender o problema.
2. Elaborar um plano.
3. Executar o plano.
4. Olhar para trás.

Vamos começar com a primeira etapa.

Etapa 1: entender o problema

Ao receber um problema de codificação em uma entrevista, é tentador se apressar em programar. Isso é difícil de evitar, especialmente se você tiver um limite de tempo.

Entretanto, tente resistir a esse impulso. Certifique-se de que você realmente entendeu o problema antes de começar a resolvê-lo.

Leia o problema. Se estiver em uma entrevista, você pode ler o problema em voz alta, se isso o ajudar a se acalmar.

Ao ler o problema, esclareça qualquer parte dele que você não tenha entendido. Se estiver em uma entrevista, você pode fazer isso perguntando ao entrevistador sobre a descrição do problema. Se estiver sozinho, pense e/ou pesquise no Google partes da pergunta que talvez não tenha compreendido.

Essa primeira etapa é fundamental, pois, muitas vezes, não dedicamos tempo para entender completamente o problema. Se você não entender completamente o problema, será muito mais difícil resolvê-lo.

Para ajudá-lo a entender melhor o problema, pergunte a si mesmo:

Quais são as entradas?

Que tipos de entradas serão usadas nesse problema? Neste exemplo, as entradas são os argumentos que nossa função receberá.

Só de ler a descrição do problema até agora, sabemos que as entradas serão números. Porém, para sermos mais específicos sobre quais serão as entradas, podemos perguntar:

"As entradas serão sempre apenas dois números? O que deve acontecer se nossa função receber como entrada três números?"

Aqui, poderíamos pedir esclarecimentos ao entrevistador ou analisar melhor a descrição do problema.

O problema de progamação pode ter uma nota dizendo: "Você só deve esperar duas entradas para a função". Se for esse o caso, você sabe como proceder. Você pode ser mais específico, pois, provavelmente, perceberá que precisa fazer mais perguntas sobre os tipos de entradas que pode estar recebendo.

As entradas serão sempre números? O que a nossa função deve fazer se recebermos as entradas "a" e "b"? Esclareça se nossa função sempre receberá números ou não.

Opcionalmente, você pode anotar as possíveis entradas em um comentário de código para ter uma ideia de como elas serão:

//entradas: 2, 4

Depois, pergunte:

Quais são as saídas?

O que essa função retornará? Nesse caso, a saída será um número que é o resultado das duas entradas de números. Certifique-se de entender quais serão seus resultados.

Crie exemplos.

Depois de entender o problema e conhecer as possíveis entradas e saídas, você pode começar a trabalhar em alguns exemplos concretos.

Os exemplos também podem ser usados como verificações de integridade para testar seu eventual problema. A maioria dos editores de desafios de código em que você trabalhará (seja em uma entrevista ou apenas usando um site como o Codewars ou o HackerRank) tem exemplos ou casos de teste já escritos para você. Mesmo assim, escrever seus próprios exemplos pode ajudá-lo a consolidar sua compreensão do problema.

Comece com um ou dois exemplos simples de possíveis entradas e saídas. Vamos voltar à nossa função de adição.

Vamos chamar nossa função de "add" (em português, adicionar ou somar).

O que é um exemplo de entrada? Um exemplo de entrada pode ser:

// add(2, 3)

Qual é a saída para isso? Para escrever o exemplo de saída, podemos escrever:

// add(2, 3) ---> 5

Isso indica que nossa função receberá uma entrada de 2 e 3 e retornará 5 como saída.

Crie exemplos complexos.

Ao analisar exemplos mais complexos, você pode reservar um tempo para procurar casos extremos que talvez precisem ser considerados.

Por exemplo, o que devemos fazer se nossas entradas forem strings em vez de números? Se tivermos como entrada duas strings, por exemplo, add('a', 'b'), como proceder?

Seu entrevistador talvez diga para retornar uma mensagem de erro se houver entradas que não sejam números. Nesse caso, você pode adicionar um comentário de código para lidar com a questão, se ajudar a lembrar que isso é algo necessário.

// retornar erro se as entradas não forem números.

Seu entrevistador também pode dizer a você para presumir que suas entradas serão sempre números e, nesse caso, você não precisará escrever nenhum código adicional para lidar com esse caso extremo de entrada específico.

Se você não tem um entrevistador e está apenas resolvendo esse problema, o problema pode dizer o que acontece quando você insere dados inválidos.

Por exemplo, alguns problemas dirão: "Se houver zero entradas, retorne indefinido". Para casos como esse, você pode, opcionalmente, escrever um comentário.

// Verifique se não há entradas.

// Se não houver entradas, retorne indefinido.

Para nossos propósitos, assumiremos que nossas entradas serão sempre números. Porém, em geral, é bom pensar em casos extremos.

O professor de ciência da computação David Evans recomenda escrever o que os desenvolvedores chamam de código defensivo. Pense no que poderia dar errado e em como seu código poderia se defender contra possíveis erros.

Antes de passarmos para a etapa 2, vamos resumir a etapa 1: entender o problema:

- Leia o problema.

- Quais são as entradas?

- Quais são as saídas?

- Crie exemplos simples. Em seguida, crie exemplos mais complexos.

Etapa 2: elaborar um plano para solucionar o problema

Em seguida, elabore um plano de como resolverá o problema. Ao elaborar um plano, escreva-o em pseudocódigo.

Pseudocódigo é uma descrição em linguagem simples das etapas de um algoritmo. Em outras palavras, o pseudocódigo é o plano passo a passo de como resolver o problema.

Escreva as etapas que você precisa seguir para resolver o problema. Para um problema mais complicado, você teria mais etapas. Para esse problema, você poderia escrever:

// Crie uma variável de soma.

// Adicione a primeira entrada à segunda entrada usando o operador de adição.

// Armazene o valor de ambas as entradas na variável de soma.

// Retorne como saída a variável de soma.

Agora, você tem seu plano passo a passo para resolver o problema.

Para problemas mais complexos, o professor Evans observa: "Considere sistematicamente como um ser humano resolve o problema". Ou seja, esqueça por um momento como seu código pode resolver o problema e pense em como você o resolveria como um ser humano. Isso pode ajudá-lo a ver as etapas com mais clareza.

Etapa 3: executar o plano (resolver o problema)

A próxima etapa da estratégia de solução de problemas é resolver o problema. Usando seu pseudocódigo como guia, escreva seu código real.

O professor Evans sugere que você se concentre em uma solução simples e mecânica. Quanto mais fácil e simples for a solução, maior a probabilidade de você programá-la corretamente.

Usando nosso pseudocódigo, poderíamos escrever o seguinte:

function add(a, b) {
 const sum = a + b;
 return sum;
}

O professor Evans acrescenta: lembre-se de não otimizar prematuramente. Ou seja, você pode ficar tentado a começar a dizer: "Espere, estou fazendo isso e o código será ineficiente!"

Primeiro, pegue sua solução simples e mecânica.

Se você não conseguir resolver todo o problema, o que fazer? Caso haja uma parte dele que você ainda não sabe como resolver, como proceder?

Colt Steele dá um ótimo conselho aqui: se você não conseguir resolver parte do problema, ignore a parte difícil que está atrapalhando. Em vez disso, concentre-se em tudo o mais que você pode começar a escrever.

Ignore temporariamente a parte difícil do problema que você não está entendendo bem e escreva as outras partes. Depois de fazer isso, volte à parte mais difícil.

Isso permite que você termine pelo menos uma parte do problema. Muitas vezes, você perceberá como lidar com a parte mais difícil do problema quando voltar a ela.

Etapa 4: analisar o que você fez

Quando sua solução estiver funcionando, reserve um tempo para refletir sobre ela e descobrir como fazer melhorias. Esse pode ser o momento de refatorar sua solução para torná-la mais eficiente.

Ao analisar seu trabalho, aqui estão algumas perguntas que Colt Steele sugere que você faça a si mesmo para descobrir como pode melhorar sua solução:

• Você pode obter o resultado de modo diferente? Que outras abordagens são viáveis?
• Você consegue entendê-lo em uma olhada rápida? Faz sentido?
• Você pode usar o resultado ou o método em outro problema?
• Você pode melhorar o desempenho de sua solução?
• Você consegue pensar em outras maneiras de refatorar?
• Como outras pessoas resolveram esse problema?

Uma maneira de refatorar nosso problema para tornar nosso código mais conciso é remover nossa variável e usar um retorno implícito:

function add(a, b) {
 return a + b;
}

Com a etapa 4, seu problema pode nunca parecer concluído. Até mesmo os grandes desenvolvedores ainda escrevem códigos que, mais tarde, olham e querem mudar. Essas são perguntas de orientação que podem ajudá-lo.

Se ainda tiver tempo em uma entrevista, você pode passar por essa etapa e melhorar sua solução. Se estiver programando por conta própria, reserve um tempo para revisar essas etapas.

Quando estou praticando programar por minha conta, quase sempre observo as soluções existentes que são mais elegantes ou eficazes do que as que eu criei.

Conclusão

Neste artigo, examinamos a estratégia de solução de problemas em quatro etapas para resolver problemas de programação.

Vamos analisá-las aqui:

• Etapa 1: entender o problema
• Etapa 2: criar um plano passo a passo de como você resolverá o problema
• Etapa 3: executar o plano e escrever o código real
• Etapa 4: analisar o que foi feito e, possivelmente, refatorar sua solução se ela puder ser melhor.

Praticar esse método de resolução de problemas me ajudou imensamente em minhas entrevistas técnicas e em meu trabalho como desenvolvedora.

Se você não se sentir confiante quando se trata de resolver problemas de programação, lembre-se de que a solução de problemas é uma habilidade que qualquer pessoa pode aprimorar com o tempo e a prática.

Boa sorte!

Se você gostou deste artigo, participe do clube de programação da autora, onde os participantes enfrentam desafios de programação juntos todos os domingos e apoiam uns aos outros à medida que aprendem novas tecnologias.

Se você tiver comentários ou perguntas sobre esta publicação, sinta-se à vontade para enviar um tweet para a autora.