DEV Community: Lucas dos Prazeres

Solucionando problemas em 5 etapas: Uma abordagem em programação.

Lucas dos Prazeres — Fri, 15 Jan 2021 17:12:51 +0000

Introdução

Chegou a hora de finalmente entender uma das frases mais famosas no mundo da programação, engenharia e em outras áreas: "Seja um solucionador de problemas". Mais do que isso, você entenderá o sentido prático disso, por meio de um fluxo de trabalho que pode te ajudar a compreender e resolver problemas de um jeito novo.

Para que isso aconteça, você precisa resistir ao impulso de sair escrevendo código assim que se depara com um desafio e passe a enxergar a solução como um conjunto de etapas que, só então, serão implementadas em uma linguagem de programação. Dessa forma, é possível fazer da sua solução mais clara e independente da ferramenta usada para implementa-lá.

Esse material é uma síntese do que aprendi em uma das seções do curso Javascript Algorithms and Data Structures Masterclass, do Colt Steele. Recomendo que você confira caso sinta a necessidade de desenvolver uma base nesse assunto, por isso vou deixar o link para acessar o curso, ao final desse post.

Quem se importa?

Você deveria. Resolver problemas de diferentes níveis é algo extremamente recorrente no dia a dia de um dev, além de ser um componente chave em muitas entrevistas de emprego na área. Por isso, é importante ter ao menos uma noção de como começar a trabalhar, caso um problema novo surja de repente. Tendo em mente o segundo exemplo, o cenário desenvolvido nesse post tem como base uma entrevista fictícia, onde os entrevistadores pedirão a você para implementar algum tipo de solução e você deve mostrá-los a sua abordagem para a situação dada.

Apresentando o cenário

Imagine que, em uma entrevista técnica para uma vaga em programação, é solicitado que você desenvolva uma solução que verifique a ocorrência de cada caractere em uma string qualquer.

Apesar de ser um desafio simples e você pode até já ter pensado em uma forma de implementar isso, resista ao impulso de disparar código no editor de texto, de imediato. Você verá que há muita coisa a ser discutida.

Fluxo de trabalho

O fluxo apresentado no curso que mencionei sugere que abordemos cada novo problema em 5 passos: Entender o problema, Explorar exemplos, Decompor em etapas, Resolver/Simplificar o problema e, finalmente, Refatorar. Isso vai garantir que você (e os entrevistadores) visualizem a sua linha de pensamento e onde você pretende chegar, antes mesmo de escrever uma única linha de código.

Passo 1: Entenda o problema

O primeiro passo é garantir que você realmente compreendeu o problema e possa esclarecer aspectos importantes sobre o que é preciso ser feito. Para fazer isso, Steele recomenda que você faça as seguintes perguntas:

Posso repetir o problema em minhas próprias palavras?
Quais entradas devem ser introduzidas?
Quais saídas são esperadas, dessa solução?
As saídas podem ser deduzidas das entradas? Ou seja, tenho informações suficientes para gerar o resultado esperado?
Como eu deveria rotular os dados presentes nessa solução?

As três primeiras podem ser feitas aos entrevistadores, caso estejam abertos a consulta, e as duas últimas devem ser seus questionamentos.

Reformulando o problema, você declara que "Devo construir uma função que analise uma string e devolva o número de vezes em que cada caractere apareceu". Confirmada a informação, seguimos adiante.

Digamos que, após tentar esclarecer o problema, você obteve as informações de que a entrada deve ser uma string simples e que a saída pode ser expressa por meio de um objeto cujas chaves são os caracteres e os valores, suas respectivas ocorrências.

Passo 2: Explore exemplos

Agora que você tem uma noção clara do que deve ser inserido e o que deve ser retornado como resultado, você pode rabiscar, em seu editor (ou quadro, se for o caso), alguns exemplos práticos do que deve ser esperado. Nesse momento, é recomendado que você busque explorar:

casos simples
casos mais complexos
casos com entradas vazias
casos com entradas inválidas

Assim, você chega a um esboço como esse

charCount("hello"); // { h: 1, e: 1, l: 2, o: 1 }
charCount("Hello World!"); // ???
charCount("My phone number is 23453"); // ???
charCount(); // ???
charCount(""); // ???
charCount(true); // ???
charCount(12345) // ???

Note que agora você tem alguns casos especiais em seu rascunho, levando aos questionamentos "Devo considerar espaços, números e caracteres especiais? E quanto aos minúsculos e maiúsculos? O que fazer em casos de entradas inválidas?"

Esclarecidas essas infomações, é definido, por exemplo, que apenas caracteres alfanuméricos devem ser considerados na contagem, todos devem ser analisados em minúsculo e entradas inválidas devem retornar um objeto vazio como resultado.

charCount("hello"); // { h: 1, e: 1, l: 2, o: 1 }
charCount("Hello World!"); // { h: 1, e: 1, l: 3, o: 2, w: 1, d:1 } 
charCount("My phone number is 23453"); // { m: 2, p: 1, ..., 2: 1, 3: 2, ... }
charCount(); // {}
charCount(""); // {}
charCount(true); // {}
charCount(12345) // {}

Passo 3: Decomponha em etapas

Definida a interface da sua solução, é preciso fazer um esboço das etapas necessárias para atingir os resultados esperados. Você pode fazer isso utilizando Pseudocódigo ou apenas comentando as etapas, de maneira clara.

function charCount(str) {
// criar o objeto de resultado
// verificar entradas inválidas e, se for o caso, retornar objeto vazio
// remover caracteres indesejados e espaços
// iterar sobre a string modificada
  // se o caractere já estiver adicinado ao objeto, incrementar 1
  // se o caractere não estiver, criar chave e adicionar o valor 1
//retornar objeto de resultado
}

Percebe-se, agora, que o processo de resolução ficou extremamente claro e, mesmo que você não implemente a solução completamente, é possível saber com clareza aonde você pretendia chegar.

Passo 4: Resolva/Simplifique

Chegou a hora de codar a solução desenvolvida e ver algumas dicas para nos prepararmos para alguns imprevistos que podem ocorrer.

function charCount(str) {
  // criar o objeto de resultado
  const result = {};
  // verificar entradas inválidas e, se for o caso, retornar objeto vazio
  if (typeof str != 'string') {
    return result;
  }
  // remover caracteres indesejados e espaços
  const sanitizedString = str.toLowerCase().replace(/[^a-z0-9]/g, '');
  // iterar sobre a string modificada
  for (let i = 0; i < sanitizedString.length; i++) {
    let char = sanitizedString[i];
    if (result[char] > 0) {
      // se o caractere já estiver adicinado ao objeto, incrementar 1
      result[char]++;
    } else {
      // se o caractere não estiver, criar chave e adicionar o valor 1
      result[char] = 1;
    }
  }
  //retornar objeto de resultado
  return result;
}

Temos aqui uma implementação que resolve o problema dado, mas nem sempre pode ser tão simples. Por exemplo, você pode acabar esquecendo a expressão regular que seleciona os caracteres que devem ser excluídos ou até mesmo o método que deixa strings em caixa baixa. Quando checar a resposta para esses pequenos problemas não for uma opção, você pode utilizar duas abordagens. A primeira consiste em identificar a dificuldade e simplificar a solução, eliminando os pontos que você não lembra como implementar e ignorando-os, temporariamente. Nesse caso, mantendo caracteres especiais e letras maiúsculas na string e prosseguindo com a solução. Em algumas situações você pode lembrar qual a "peça" que está faltando, enquanto faz outra coisa. O outro caminho é ser comunicativo a respeito a sua dificuldade, dizendo coisas como "não consigo lembrar qual método converte strings em minúsculas, nesse momento" ou qualquer outra dificuldade similar. Isso vai sinalizar que você sabe o que está fazendo e, quem sabe, fazer os entrevistadores darem pequenas dicas.

Passso 5: Volte e Refatore

A solução resolveu o problema, isso quer dizer que chegou a hora de fechar o notebook e finalizar o desafio, certo?

Nada disso.

É extremamente tentador se contentar com a solução que simplismente funciona. Em casos de demandas muito urgentes, é a única opção, mas nem sempre é assim. Agora é o momento da autoavaliação e de sermos curiosos, persistentes e julgadores do nosso próprio trabalho. Remover variáveis desnecessárias, renomear elementos e considerar soluções alternativas são boas práticas. Novamente, Steele nos deixa com uma lista de perguntas que podemos fazer a nós mesmos ou a outras pessoas, quando nos deparamos com a primeira implementação funcional:

Você pode checar os resultados?
Você desenvolveria isso de outra forma?
Consegue entender a solução de primeira?
É possível utilizar este resultado para solucionar outro problema?
Você consegue melhorar a performance da sua solução?
Consegue pensar em maneiras de refatorar isso?
Como é que outras pessoas resolveram esse mesmo problema?

Nem é preciso dizer o quanto essas perguntas podem mudar o aspecto do seu código. Com relação ao último item, é recomendado que você procure em sites como o Github ou outras plataformas, para entender as diferentes abordagens. Um detalhe importante é que nem sempre o que você procura estará implementado na linguagem que você está utilizando no momento, por isso é extremamente recomendado ver códigos feitos com outras ferramentas (desde que você se sinta confortável com isso).

Para finalizar, deixo algumas alternativas para solucionar o mesmo problema, que variam em estética, performance e até linha de raciocínio utilizada.

function charCount(str) {
  const result = {};
  if (typeof str != 'string') {
    return result;
  }
  const sanitizedString = str.toLowerCase().replace(/[^a-z0-9]/g, '');
  for (let char of sanitizedString) {
    result[char] = ++result[char] || 1;
  }
  return result;
}

function charCount(str) {
  const result = {};
  for (let char of str) {
    char = char.toLowerCase();
    if (/[a-z0-9]/.test(char)) {
      result[char] = ++result[char] || 1;
    }
  }
  return result;
}

function charCount(str) {
  const result = {};
  for (let char of str) {
    if (isAlphaNumeric(char)) {
      char = char.toLowerCase();
      result[char] = ++result[char] || 1;
    }
  }
  return result;
}

function isAlphaNumeric(char) {
  let code = char.charCodeAt(0);
  if (!(code > 47 && code < 58) && // numeric (0-9)
    !(code > 64 && code < 91) && // upper alpha (A-Z)
    !(code > 96 && code < 123)) { // lower alpha (a-z)
    return false
  }
  return true
}

Conclusão

Encarar problemas de maneira metódica e planejar seu ataque, antes de iniciá-lo, pode fazer você enxergar novas possibilidades em suas soluções atuais, ou melhorar (e muito) as próximas. Lembre-se de que a programação é sobre fazer mais gastando menos recursos, isso significa parar para analisar cuidadosamente os caminhos disponíveis e, ainda assim, saber que existem opções que ainda não foram descobertas.

Links úteis

Javascript Algorithms and Data Structures Masterclass

A sutil arte de escrever funções limpas.

Lucas dos Prazeres — Fri, 18 Sep 2020 18:07:50 +0000

Introdução.

Nos mais diversos paradigmas e linguagens utilizados hoje em dia, as funções são elementos importantíssimos e podem definir, a depender do modo como são feitas, a saúde ou precariedade de um sistema. Escrevê-las bem é um desafio de organização, compreensão de responsabilidades e até comunicação, para pessoas desenvolvedoras!

Por isso, trago a vocês o segundo artigo da série clean code (se você ainda não leu o primeiro, acesse esse link), onde vamos entender, afinal, o que são funções "limpas".

Bons programas são funções bem pequenas.

Isso não é necessariamente óbvio para pessoas com pouca experiência em programação, mas para você que já fez todo o tipo de engenhoca, sim. Funções grandes ferem boa parte das boas práticas em programação e são ótimas em colecionar bugs e estruturas estranhas e indecifráveis (e, claro, são SUPER cansativas de serem lidas). Por essa razão, é recomendado que funções tenham algo em torno de 1 a 20 linhas, o que vai soar como um exagero, até que você experimente nos seus códigos.

Vamos ver exemplo prático disso. Veja essa função "amoeba" que valida CPFs.

function validate(cpf) {
  if (!cpf) return false;

  const sanitizedCPF = cpf.replace(/\D+/g, '');

  const seq = cpf[0].repeat(sanitizedCPF.length);

  if (sanitizedCPF === seq) return false;

  if (cpf.match(/[a-zA-Z!@#$%^&*(),?":{}|<>]/g)) return false;

  let cpfWithoutPrefix = sanitizedCPF.slice(0, 9);

  let firstLastingDigitOnCPF;

  let factor = cpfWithoutPrefix.length + 1;
  let sum = 0;
  for (let i in cpfWithoutPrefix) {
    sum += cpfWithoutPrefix[i] * factor;
    factor--;
  }

  firstLastingDigitOnCPF = 11 - (sum % 11);

  let secondLastingDigitOnCPF;

  cpfWithoutPrefix += firstLastingDigitOnCPF;

  factor = cpfWithoutPrefix.length + 1;
  sum = 0;
  for (let i in cpfWithoutPrefix) {
    sum += cpfWithoutPrefix[i] * factor;
    factor--;
  }
  secondLastingDigitOnCPF = 11 - (sum % 11);

  const validCPF = cpfWithoutPrefix + secondLastingDigitOnCPF;

  return sanitizedCPF == validCPF;
};

Apesar de esse exemplo seguir uma sequência lógica de etapas, ainda é difícil definir quais são elas e quais os seus conceitos e detalhes.

Agora, veja a versão refatorada dessa mesma função, na forma de um método estático da recém criada classe CPF:

validate(cpf) {
    const sanitizedCPF = CPF.sanitize(cpf)
    if (!cpf) return false;
    if (CPF.isSenquence(sanitizedCPF)) return false;
    if (CPF.hasInvalidChars(sanitizedCPF)) return false;

    const validCPF = CPF.generateValidCpfFrom(sanitizedCPF);

    return sanitizedCPF === validCPF;
};

Vamos ver alguns conceitos que vão deixar suas funções mais parecidas com o segundo exemplo.

Nomes descritivos

Eu sei que já falamos sobre isso, antes, mas a importância da nomenclatura em funções nunca será reforçada o suficiente. O motivo disso? Bons programas devem ser lidos como uma narrativa, que conta a história daquele sistema e o seu funcionamento, de maneira lógica e fluida. Afinal,

"Programação é e sempre foi, a arte do design de linguagem"

Além dos nomes, outro importante importante recurso de comunicação com o leitor é o uso da sintaxe da linguagem de programação que você está utilizando. Um exemplo disso é o if (se, em inglês) que fica muito mais comunicativo quando o conectamos com uma função que descreve uma condição, como em:

if (CPF.hasInvalidChars(cpf)) {
  return false
}

Além do mais, nomes de funções deveriam conter informações o suficiente sobre as mesmas, para que não seja preciso consultar a sua declaração. Ou seja, o que ela faz, qual seu retorno, e quais os seus parâmetros.

O que exatamente o nome dessa função indica?

const email = getEmailAddresssFromUserObject(user);

Que o retorno dessa função é uma string contendo o email de um usuário
Que a sua função é apenas informar o email
Que ela recebe um objeto de usuário como parâmetro

Economizamos uma ida à declaração dessa função, não?

Crie pares de verbo/substantivo nas suas funções.

Quando as suas funções recebem um ou mais parâmetros, é interessante fazer com que os nomes da função e de suas entradas contem uma história. Para ilustrar essa ideia, temos o seguinte caso.

write(name)

Esses dois elementos combinam tão bem que é possível saber de cara que, seja lá o que name for, ele está sendo escrito.

Para melhorar ainda mais, poderíamos incluir

writeField(name)

Agora, sabemos que name é um campo a ser escrito!

Uma função deveria informar algo ou fazer algo. Nunca as duas coisas.

É muito comum criarmos funções com o que se chama de argumentos de saída, que alteram o valor da variável passada por parâmetro e não retornam nada. Não há problema algum em fazer isso, desde que você deixe claro que é isso o que a função faz

appendFooter(s)

você consegue me dizer, com certeza, se essa função inclui um footer na variável s, ou se ela inclui o valor de s como um footer?

Esse problema pode ser corrigido através de dois caminhos. O primeiro deles seria renomear a função para appendFooterOn(s) ou appendFooterElement(s). A segunda seria utilizar o conceito de .this, da Orientação a Objetos. Assim, a própria classe serve como identificação do retorno da função, como em:

htmlPage.appendFooter(s);

Sendo assim, é muito importante definir se a sua função vai retornar (informar) um valor, ou alterá-lo. Caso contrário, seus sistemas serão cada vez mais ambíguos e difíceis de se interpretar.

Faça uma coisa, faça-a bem e faça-a apenas.

Cada função em seu sistema deveria ter de se preocupar em fazer uma única coisa. Assim, ela pode ser a especialista nesse assunto e ser facilmente reconhecida por isso. Isso pode ser visto nos exemplos da validação de cpf. A primeira função tinha muitas tarefas e etapas, enquanto a segunda, se preocupava apenas em validar o cpf informado.

Existem algumas técnicas para sabermos quando uma função está fazendo uma única coisa ou não. Vamos conhecê-las.

Verificar o nível de abstração.

De maneira simples, o nível de abstração de um código se dá por quantos detalhes ele conhece sobre o que está fazendo e, quanto mais subirmos nesse nível, mais simples os conceitos se parecem.

Para entender isso melhor, vamos utilizar um trecho da função que valida CPF's

const sanitizedCPF = cpf.replace(/\D+/g, '');

const seq = cpf[0].repeat(sanitizedCPF.length);

if (sanitizedCPF === seq) return false;

É aqui que validamos se o cpf informado é uma sequência de números repetidos, como em 999.999.999-99, caso em que seria invalidado imediatamente.

Para fazer essa verificação, extraimos os pontos e traços do cpf, criando a string sanitizedCPF. Depois diso, criamos uma sequência com o primeiro caractere do cpf, utilizando a função repeat, do javascript, que vai gerar o valor considerado inválido.

Comparamos o valor recebido e o valor inválido e temos um resultado.

Isso é um baixo nível de abstração.

Agora, no segundo caso. Só precisamos chamar os métodos internos sanitize e isSequence e, em um passe de mágica, executamos a mesma lógica, de forma abstraída.

const sanitizedCPF = CPF.sanitize(cpf)
if (CPF.isSenquence(sanitizedCPF)) return false;

Por isso, você deve se certificar de que os elementos internos da sua função mantenham um padrão onde todos possuam o mesmo nível de detalhamento em relação ao que estão fazendo.

A regra do parágrafo.

Outra forma muito interessante de descobrir quando uma função tem apenas uma responsabilidade, é tentar expressar o que ela faz por meio de um parágrafo PARA. A exemplo disso:

CPF.isSenquence(cpf)

// PARA verificar se um cpf é uma sequência, comparamos o valor numérico do cpf informado, com uma string gerada pela repetição do primeiro caractere do mesmo e retornamos o resultado.

Caso essa sentença precise de um além de ou algo semelhante, sabemos que a função tem mais de uma responsabilidade.

Granularidade.

Fora as duas útimas regras vistas, temos, também, uma terceira opção para identificar quanta responsabilidade uma função carrega.

Se você conseguir extrair dela uma segunda função, que não seja simplesmente uma outra forma de expressar o que o código dela já diz, então ainda há tarefas demais.

Um caso em que seria possível fazer essa extração é

function generateRandomList(length) {
  const list = [];

  let cont = 0;

  while (cont < length) {
    let randomCharCode = Math.floor(Math.random() * (122 - 97) + 97);

    let randomChar = String.fromCharCode(randomCharCode);

    list.append(randomChar);
  }

  return list;
}

em que o bloco dentro da estrutura while poderia ser facilmente substituido por

function generateRandomCharList(length) {
  const list = [];

  let cont = 0;

  while (cont < length) {
    let randomChar = generateRandomChar();

    list.append(randomChar);
  }

  return list;
}

function generateRandomChar() {
  const randomCharCode = Math.floor(Math.random() * (122 - 97) + 97);

  const randomChar = String.fromCharCode(randomCharCode);

  return randomChar;
}

Ou, até mesmo

// ...

function generateRandomChar() {
  const randomCharCode = generateRandomDigitStartingAndEndingIn(97, 122);

  const randomChar = String.fromCharCode(randomCharCode);

  return randomChar;
}

function generateRandomDigitStartingAndEndingIn(min, max) {
  return Math.floor(Math.random() * (max - min) + min);
}

Com esses exemplos, é possível perceber que, quanto menor e mais específica uma função for, mais descritivo será o seu nome e mais fácil será identificar qualquer bug que possa acontecer.

A regra da descida

Como foi dito anteriormente, um código deve ser tão claro e fuido a ponto de ser lido como uma narrativa que passa por cada etapa de um processo. Por isso, é importante que você defina uma ordem vertical para as suas funções.

O JavaScript possui um recurso fantástico chamado hoisting, que, de forma resumida, te permite chamar uma função declarada com a palavra function antes mesmo de ela ser criada.

Isso nos dá a vantagem de escrever códigos que possam ser lidos de cima para baixo, de acordo com a ordem em que as funções são chamadas. Qual a vantagem disso?

Vamos pegar o exemplo criado no tópico anterior e tentar lê-lo como uma série de parágrafos.

PARA criar uma lista de caracteres aleatórios, devemos informar o tamanho dessa lista e, a cada iteração, criar um caractere aleatório e adicioná-lo à lista

PARA criar um caractere aleatório, devemos criar um dígito aleatório correspondente a um caractere e convertê-lo com a classe String

PARA criar um dígito aleatório, devemos utilizar uma expressão matemática que gera valores reais aleatórios em um intervalo e, em seguida, arredondá-los com o método Math.floor

Ao manter essa sequência lógica em seus sistemas, será uma tarefa fácil compreender seus componentes um a um, ou até mesmo com um todo.

O perigo do efeitos colaterais.

Vou começar esse tópico com um trecho de clean code, que resume o que vou dizer, em poucas palavras

"Efeitos colaterais são grandes mentirosos. Sua função promete fazer uma coisa, mas também faz outras, secretamente, o que pode gerar mal comportamento em seu sistema"

Essa é, sem sombra de dúvidas, uma das principais origens de bugs em sistemas. Você não deveria, em hipótese alguma, fazer algo que a sua função não admite que faz.

Em uma função que valida senhas, encontrar a seguinte estrutura

function checkPassword(username, password) {
  const correspondingUser = userRepository.findByUsername(username);

  if (password === correspondingUser.password) {
    session.initialize();
    return true
  }
}

É achar a prova de que as funções estão mentindo. Isso pode custar caro, pois, nesse exemplo, cada vez que a verificação de senha for chamada, uma nova sessão de usuário será iniciada e perderemos os dados da antiga.

Claro, poderiamos renomear a função para checkPasswordAndInitializeSection mas ela claramente teria mais de uma responsabilidade.

Outra forma muito comum de efeito colateral (ou side effect, como é mais conhecido) é alterar valores de atributos internos em uma classe, ao chamar um método da mesma. Assim, sempre que tivermos problemas com um valor específico, será bem mais difícil delimitar o seu escopo, já que outras funções modificam o seu valor, secretamente.

Don't Repeat Yourself (DRY)

Eu mantive o nome desse tópico em inglês porque ele é bem famoso na programação e é assim que você vai ouvir falar dele.

O DRY, ou Não Se Repita é um princípio que nos orienta a eliminar código duplicado, em nossas aplicações. Isso não quer dizer automatizar TUDO o que há nelas, mas evitar pontos em que uma única mudança teria de ser refletida em várias partes de um mesmo código.

Uma clara violação desse princípio pode ser encontrada no exemplo do CPF validator, onde a lógica para gerar um dígito ao final do CPF foi duplicada

// Primeira criação de dígito
let firstLastingDigitOnCPF;

  let factor = cpfWithoutPrefix.length + 1;
  let sum = 0;
  for (let i in cpfWithoutPrefix) {
    sum += cpfWithoutPrefix[i] * factor;
    factor--;
  }

  firstLastingDigitOnCPF = 11 - (sum % 11);

  // segunda criação de dígito
  let secondLastingDigitOnCPF;

  cpfWithoutPrefix += firstLastingDigitOnCPF;

  factor = cpfWithoutPrefix.length + 1;
  sum = 0;
  for (let i in cpfWithoutPrefix) {
    sum += cpfWithoutPrefix[i] * factor;
    factor--;
  }
  secondLastingDigitOnCPF = 11 - (sum % 11);

Isso pôde ser contornado envolvendo a lógica repetida em um método chamado createDigit, que foi chamado duas vezes

static createDigit(incompleteCpf) {
    let factor = incompleteCpf.length + 1;
    let sum = 0;
    for (let i in incompleteCpf) {
        sum += incompleteCpf[i] * factor;
        factor--;
    }
    const newDigit = 11 - (sum % 11);
    return newDigit > 9 ? 0 : String(newDigit);
  }

Você não precisa se preocupar com o que essa função faz, no momento, apenas entender que, agora, qualquer mudança feita na lógica de criação de dígito de cpf será implementada apenas nessa função e não duplicada ao longo do código.

Dito isso, busque identificar pontos onde você percebe que está "Se repetindo" e poderia facilmente fazer uma otimização segura.

Como escrever boas funções?

Agora que você tem acesso a conhecimentos privilegiados sobre boas práticas, é preciso entender uma coisa muito importante.

Escrever código é como qualquer outro tipo de escrita. O que você cria logo depois de ter uma ideia é um rascunho, não necessariamente o resultado final. Esse rascunho será desorganizado, com nomenclaturas inadequadas ou com qualquer um dos problemas citados nesse artigo.

Depois de sentar e colocar seus pensamentos no papel (ou melhor, no editor) você faz uma revisão do que foi escrito e identifica pontos fortes e fracos no resultado, faz mudanças aqui e ali, cria novas funções e/ou classes e, quando menos perceber, já terá em mãos uma função bem escrita.

Para reforçar o que foi dito, deixo aqui um último trecho de Clean Code

"No final do processo, eu acabo criando funções que obedecem às regras nesse capítulo. Eu não as escrevo assim desde o começo. Não acho que alguém conseguiria"

Fonte

Clean Code - Robert C. Martin: buy it on Amazon