Por que (e como) escrevo código com lápis e papel

Se a ideia de escrever código à mão parece boba, pode surpreendê-lo saber que é inevitável. Se você não tiver certeza, pense na última entrevista de emprego que você fez e lembre-se de como não havia computador na sala de entrevista - apenas seus entrevistadores, uma folha de papel em branco e uma caneta esferográfica azul.

Para os alunos entre vocês, é um negócio ainda maior, pois suas notas ficam pelas linhas de código que você espremeu estrategicamente no espaço disponível em sua folha de respostas.

E não apenas isso, programadores experientes podem indicar o pacote de folhas A4 que eles removeram da copiadora do escritório para rabiscar um algoritmo particularmente complexo no qual estavam trabalhando.

Portanto, se você é um estudante de exame, um potencial entrevistado de emprego ou alguém que deseja resolver seus becos sem saída de programação, espero que este artigo o ajude quando você colocar sua caneta no papel para codificar.

Embora eu me concentre no aspecto analógico da escrita de código, você pode aplicar essas etapas à codificação em qualquer forma ou linguagem. Portanto, considere isso também como uma diretriz de codificação genérica que funciona especificamente para mim, mas também pode ser muito útil para você em seu trabalho.

Por que anotá-lo?

Antes de começarmos, é essencial entender que ninguém espera que você anote código pronto para produção em um notebook. Não é como se você pudesse colocar isso em um editor de código e compilá-lo sem erros. Se produzir um código perfeito fosse o objetivo, você estaria sentado na frente de um computador nas salas de entrevista e salas de exames.

O objetivo do código manuscrito é trabalhar com a lógica antecipadamente. Existe o desejo de “entrar no navegador” o mais rápido possível no design, mas existe a sabedoria convencional em esboçar designs à mão. Um meio de baixa fidelidade incentiva a experimentação rápida e erros baratos.

O mesmo pode ser verdade para o código, principalmente ao trabalhar a sintaxe e a semântica. Dito isso, obter a sintaxe e a semântica corretas é sempre um ponto positivo, embora não seja o único foco de todo o exercício de caligrafia.

Vamos ver por onde podemos começar quando se trata de código de escrita à mão.

Conheça sua pergunta

Durante meu último ano na faculdade, não pude fazer um estágio ou mesmo participar de entrevistas no campus por motivos de saúde. Como resultado, minha primeira entrevista de emprego foi bastante literal, com altos riscos.

Quando olho para trás agora, a entrevista foi bem fácil. Mas, nunca tendo assistido a um antes, eu estava ansioso além da razão. A primeira coisa que os entrevistadores perguntaram sobre programação foi se eu poderia produzir um triângulo invertido feito de asteriscos. Como eu disse, foi fácil - nada for loop não pode lidar, certo? Mas como eu disse, minha ansiedade estava no teto também.

Respirei fundo, pressionei a palma da mão contra a folha de papel em branco que eles tinham colocado para mim, deslizei o mais devagar possível em minha direção sobre a mesa (ganhando tempo, é claro), cliquei a caneta e então fiz algo certo.

Primeiro desenhei um triângulo invertido feito de asteriscos. Foi assim que encontrei meus pés no chão para começar a responder à pergunta deles.

Já vi desenvolvedores brilhantes errarem em algo simplesmente porque nunca entendem completamente o que estão resolvendo.

As questões com as quais trabalhamos não são como as questões que os físicos ou matemáticos resolvem. Eles obtêm um conjunto de parâmetros e encontram os que faltam; nossas perguntas são também nossos resultados. Já nos disseram quais são nossos resultados – temos que descobrir como alcançá-los. É por isso que é imperativo conhecer bem a pergunta, porque você verá o resultado.

Escrever ou desenhar o que você deseja produzir é uma das melhores maneiras de iniciar sua codificação. Eu entendo que em nossa indústria de ritmo acelerado, a expectativa é que tenhamos que pular direto para a programação executando uma demonstração “hello world”. E isso é ótimo para se familiarizar com uma sintaxe desconhecida e se livrar da ansiedade de tentar algo novo.

Mas quando alguém lhe faz uma pergunta e lhe dá um resultado para trabalhar, não seria melhor colocar isso primeiro? Essa pergunta/resultado não é apenas seu ponto de partida, mas também seu ponto de referência. Em qualquer etapa da sua codificação, você pode examiná-la para garantir que está trabalhando para ela e que está no caminho certo.

Então, seja em suas folhas de respostas ou naquele papel A4 em branco que você está prestes a escrever, comece por um segundo e escreva o que você está tentando imprimir. Você pode colocá-lo nas margens ou em um canto se não quiser que ele faça parte da sua resposta. Apenas certifique-se de que esteja em algum lugar onde você possa continuar referenciando-o.

Descreva seu código

Este passo é como uma faca de dois gumes. Pode obter um roteiro para o seu programa ou desperdiçar seu tempo. Meu trabalho é ter certeza de que é o primeiro.

Então, antes de tudo, eu gosto de dizer: delinear o código é desnecessário se o escopo do seu problema ou pergunta for pequeno. Novamente, essa prática não é prescritiva nem universal para todos os projetos ou situações. Imagine que eu sou seu entrevistador e peço que você escreva como centralizar um elemento em uma página da web usando CSS de todas as maneiras possíveis. Você não vai precisar exatamente de um esboço para isso. Os trechos de código são relativamente pequenos para cada método.

Mas agora, digamos que eu designe você para escrever um aplicativo da Web que capture assinaturas de usuários por meio de uma interface de tela sensível ao toque e salve a assinatura no servidor. Não tão direto, certo? Você tem mais de uma coisa para descobrir. Talvez, um pequeno esboço possa ajudar.

1. UI para captura de assinatura — HTML Canvas? WebGL?
2. Desativar eventos de ponteiro no restante da página da Web quando o usuário estiver assinando
3. Converta e salve a imagem capturada em um arquivo PNG — JS
4. Em seguida, converta-o em blob (talvez) e salve-o na tabela de dados de log do visitante.

Escrevi uma sequência aproximada de ações que acho que devo codificar. Poderia ter sido mais curto ou mais longo, dependendo do que eu queria dele.

Eu recomendo esboçar código para projetos de clientes. Escreva o esboço junto com os requisitos do usuário ou no verso dos wireframes que você imprimiu.

Seu instantâneo rápido de marcadores fornece um mapa, uma lista de tarefas e uma lista de verificação para verificar quando você chegar ao final do projeto - praticamente o resumo de todo o projeto em uma lista de baixa fidelidade. Também pode se tornar um modelo para iniciar seu próximo projeto semelhante.

Mas como eu disse antes, este passo é como uma faca de dois gumes. Você terá que manter isso curto para examinandos e entrevistados quando houver restrições de tempo.

Se você não sabe por onde começar, anote apenas três funções essenciais que você terá que codificar em seu aplicativo e, se tiver tempo, faça cinco.

Mas é isso aí. Gaste o mínimo de tempo possível com isso e não se preocupe com os detalhes. O esboço não vai marcar pontos extras. Ele está lá apenas para ajudá-lo a garantir que tudo esteja coberto. Ele captura sua reação inicial e mantém você honesto ao longo da vida do projeto.

Longhand vs. taquigrafia

Hora de começar a codificar. Então, o que você escreve? “Bds” ou “border-radius"; "div -> pou<div><p></div></p>"; "pl()ouprintln()"; "q()ouquerySelector()"?

Se outra pessoa está avaliando seu código, não há escolha. Deixe de fora abreviações, pseudocódigos, atalhos do Emmet e qualquer outra forma de taquigrafia. Caso contrário, não há razão para supor que qualquer pessoa que esteja lendo isso saiba o que suas abreviações significam.

Depende muito de você.

Se você perdeu o contato com a escrita à mão – e muitos de nós temos – é melhor não exagerar nas anotações à mão, pois elas se tornam tediosas. Ao mesmo tempo, não existe isso de ser muito frugal com sua escrita. Não se você quiser ser capaz de olhar para trás um dia e entender o que você escreveu.

Eu tenho um arquivo aberto no meu aplicativo de anotações e um bloco de notas alinhado na minha mesa onde anoto trechos de código que quero salvar para referência posterior. Eles são desorganizados, apenas um longo fluxo de trechos. É por isso que, quando folheio as notas mais antigas, não saberia o que pretendia escrever se não as tivesse escrito claramente.

Eu esqueço sintaxes o tempo todo. Por exemplo, tenho usado a notação de seta para funções JavaScript desde que foi introduzida (porque é mais curta) e tenho certeza se alguém de repente me pede para definir uma função usando o function palavra-chave, posso até perder os parênteses ou o nome da função, incitando um erro de sintaxe.

Não é incomum esquecermos sintaxes que não usamos há algum tempo. É por isso que é melhor escrever suas anotações com clareza quando você sabe que precisa delas para referência futura.

O fluxo não sequencial de código

Ao contrário do último passo, que não se aplica a vocês, entrevistados e examinandos, este é feito especialmente para você.

A maioria das linguagens de programação são interpretadas, compiladas e executadas para que, às vezes, o código pré-escrito na fonte seja executado posteriormente quando chamado. Fazemos isso em JavaScript, por exemplo, com chamada de função — as funções podem ser definidas inicialmente e executadas posteriormente. Examinados e entrevistados podem usar isso para começar a trabalhar primeiro no ponto crítico de sua resposta.

Como eu disse desde o início, o propósito do código manuscrito é trabalhar ou testar a lógica de tudo o que você programa. É melhor quando você se concentra em resolver isso primeiro.

Vamos dar um exemplo clássico de livro didático - um programa para encontrar o enésimo Número de Fibonacci. Se eu fosse escrever um esboço simples para ele, seria algo assim:

1. Obtenha a entrada.
2. Calcule o número de Fibonacci.
3. Resuma a saída.
4. Imprima a saída.

Todos os passos nesse esboço são essenciais; no entanto, 1, 3 e 4 são mais obrigatórios. Eles são necessários, mas não são importantes o suficiente para se concentrar imediatamente.

É melhor começar a escrever o código para calcular o número de Fibonacci em vez de buscar a entrada. Envolva-o em uma função, então vá em frente e escreva o código sequencialmente e escreva uma linha para chamar essa função quando apropriado.

Gaste seu tempo escrevendo código que se concentre no cerne do problema.

Profissionais de verdade podem pular adiante. Digamos que eu tenha um projeto de cliente e tenha que trabalhar com alguma geometria de triângulo – tenho dois lados, ângulos opostos e preciso encontrar o comprimento do terceiro lado. E decidi rabiscar no papel para começar em vez de abrir meu IDE.

Primeiro, eu desenharia o triângulo, é claro (é algo com o qual tenho muita experiência, como você pode ver). Eu anotaria alguns comprimentos e ângulos de amostra. Então eu escreveria a fórmula (complementos da pesquisa online, com certeza), e então pularia direto para o código da função.

Não faz sentido eu anotar as etapas obrigatórias, mesmo que eu precise delas no código pronto para produção. Mas seria diferente se eu tivesse que escrever isso em uma folha de respostas em um exame. Não posso pular as outras etapas; no entanto, ainda posso começar com o código da fórmula.

Pseudo-código

Chris já escreveu um artigo útil sobre pseudo-código que eu recomendo que você dê uma leitura sólida.

Para todos aqueles profissionais que acham que a coisa toda do código de caligrafia não parece ser sua xícara de chá, mas ainda podem estar curiosos se isso pode ajudá-lo, então pseudo-código pode ser o equilíbrio que você procura.

É semelhante a delinear o código, como mencionei em uma das etapas anteriores. No entanto, é mais breve e parece mais uma codificação abreviada. Às vezes, também é chamado de “código esqueleto”.

Aqui está um pseudo-código rápido para um layout de grade CSS:

Grid
5 60px rows
6 100px columns

Não há muito o que escrever! Portanto, mesmo que colocar um lápis no papel seja excelente para esse tipo de coisa, é igualmente eficaz, rápido e barato anotar algum pseudocódigo em qualquer programa que você esteja usando.

Espaço e comentários

Eu acredito que o código é 90% palavras-chave e 10% abas. Sem espaços, a legibilidade das palavras diminui. Os recuos também são necessários para o código manuscrito. No entanto, não o use para todos os níveis, pois a largura do papel o limitará. Use os espaços criteriosamente, mas use-os.

Se você estiver escrevendo código para seu uso, também acredito que, se você seguiu tudo o que mencionei até agora e já escreveu sua saída e um esboço na página, talvez nem precise incluir comentários. Os comentários informam rapidamente o que o conjunto de código a seguir faz. Se você já escreveu e leu um esboço do código, os comentários são notas redundantes.

No entanto, se o seu julgamento diz para derrubar um, então faça-o. Adicione-o ao lado direito do código (já que você não poderá inseri-lo entre as linhas já escritas da maneira que faria, digamos, no VS Code). Use barras, colchetes ou setas para indicar que são comentários.

Para examinandos que não confiam em uma certa sintaxe, anote os comentários. Dessa forma, pelo menos, você está deixando a pessoa que está avaliando seu trabalho saber sua intenção com esse código formatado incorretamente. E use apenas os delimitadores corretos para denotar comentários — por exemplo, seriam as barras para JavaScript.

Analógico vs. digital

Como mencionei anteriormente, tudo o que estou fornecendo aqui pode ser um conselho genérico de codificação. Se você não quiser tentar isso com papel físico, qualquer aplicativo de anotações também funciona.

Mas se você for tentar a rota digital, minha recomendação é tentar usar algo diferente de um aplicativo de anotações simples. Trabalhe com ferramentas digitais mais visuais — diagramas de fluxo, mapas mentais, wireframes, etc. Eles podem ajudá-lo a visualizar seu resultado, os contornos e o próprio código.

Não sou muito um cidadão digital (exceto por trabalhar na web e recentemente converter para leitura de e-books), então me atenho aos notebooks físicos.

Minhas ferramentas favoritas para código manuscrito

Qualquer lápis e papel serve! Mas existem muitas opções por aí, e estas são algumas ferramentas de escolha que eu uso:

Não existe uma maneira de “escrever” para codificar

Espero, no mínimo, que meu jeitinho de escrever código à mão com lápis e papel faça você avaliar a maneira como você já planeja e escreve código. Gosto de saber como outros desenvolvedores abordam seu trabalho, e esta é a minha maneira de dar uma olhada na maneira como faço as coisas.

Novamente, nada aqui é científico ou uma arte exata. Mas se você quiser experimentar o planejamento de código manuscrito, aqui está tudo o que abordamos em uma boa lista ordenada:

1. Comece anotando (com dados de exemplo, se necessário) a saída do seu código.
2. Escreva um esboço para o código. Por favor, mantenha-o em três etapas para projetos pequenos ou menos complexos.
3. Use notações à mão. Os desenvolvedores que escrevem para si mesmos podem usar notações abreviadas, desde que a escrita seja legível e faça sentido para você quando você se referir a ela posteriormente.
4. Quando estiver sob restrição de tempo, considere escrever primeiro o código que aborda o cerne do problema. Mais tarde, anote uma chamada para esse código no lugar certo em seu código sequencial.
5. Se você se sentir confiante, tente escrever pseudocódigo abordando a ideia principal.
6. Use recuos e espaços adequados — e esteja atento à largura do papel.

É isso! Quando você estiver pronto para tentar escrever código à mão, espero que este artigo facilite o início. E se você estiver sentado para um exame ou uma entrevista, espero que isso ajude você a se concentrar em acertar as perguntas.