Programação por coincidência: 6 dicas para iniciantes evitarem este erro
O livro "Programador Pragmático" escrito por David Thomas e Andrew Hunt trás um conceito chave que eu acho essencial passar para frente, especialmente para quem está iniciando: a programação por coincidência.
Eu não recomendo ler e confiar neste livro cegamente, tenho várias ressalvas sobre o conteúdo e, sinceramente, acho que o pouco conteúdo útil do livro é explicado de forma burra. Talvez num futuro eu faça uma resenha sobre este livro especificamente.
Colocando isto de lado, o conceito de programação por coincidência que o livro trás é muito bom e é algo que eu recomendo a todas pessoas iniciando na área de desenvolvimento de software a aprender sobre.
O que é programar por coincidência?
Já passou por esta situação onde você se envolveu tanto com o código que já tem trocentas abas abertas no seu editor de texto, perdeu a noção de o que o arquivo atual faz e então resolve colocar o famoso echo e rodar o programa de novo pra entender onde está.
Atitudes como "deixa eu trocar esta linha por aquela" ou "deixa eu ver se isso aqui funciona" são claros sintomas de que você está programando por coincidência.
Programar por coincidência é alterar algum código ou configuração sem ter a menor ideia de o que aquilo vai causar. Em outras palavras:
Programar por coincidência é escrever código sem uma intenção concreta.
Programar com intenção, saber exatamente o que você quer alcançar com aquelas linhas de código, é o primeiro passo para escrever para humanos, como pessoas mais experientes fazem.
Mas se eu entreguei a tarefa, qual o problema?
O problema de programar por coincidência, ou sem intenção, é que isto gasta muito tempo e energia desnecessariamente. Para a empresa funciona bem, mas para você é uma porcaria!
Alguns dos problemas que eu vejo em programar por coincidência, especialmente para quem tem menos experiência:
- muito esforço e energia desperdiçados;
- dificuldade no aprendizado no longo prazo;
- falta de confiança na solução final;
- dificuldade na hora de pedir ajuda ou justificar suas decisões numa revisão de código
Em geral, programar por coincidência só tende a te fazer mal. O único benefício que eu vejo é que, depois de sofrer tantas horas pra resolver um problema, a vitória é doce.
Mas cuidado, este é um caminho perigoso e pode te custar muito tempo e saúde mental.
Como programar por intenção e não por coincidência?
Existe algumas técnicas que podem te ajudar a programar com maior intencionalidade em vez de por coincidência e palpites. Eu vou mostrar 6 delas aqui.
Lembre-se que quase toda verdade em desenvolvimento de software nunca é absoluta, e pode ser respondida com um belo "depende".
Então não tome este texto como uma série de dogmas a serem seguidos, mas eu garanto que ao adotar ao menos uma destas dicas você já vai conseguir evoluir melhor na sua carreira.
1 - Entenda os seu requisitos antes de aplicar uma solução
Para muita gente isso parece óbvio, mas é muito comum entre iniciantes ler uma tarefa/problema/bug e já sair marretando o código pra tentar resolver.
Como já disse o Rei do Kuduro, neum fésse eisso!
Assim que você identificar o problema, a primeira coisa que você precisa entender é: quais são os sinais que me dizem se eu atingi meu objetivo ou não?
Por exemplo, um problema que o codamos.com.br tem atualmente é que nós não oferecemos uma Newsletter. A solução para este problema não é adotar um servidor, pagar um serviço de disparo de e-mails e nem escrever a newsletter. A solução é oferecer uma newsletter.
Note nuance da resposta! Ela deixa explícito o que precisa ser feito, não o como precisa ser feito.
E este é o primeiro e mais importante passo de todos. Você precisa entender qual resultado desejado. Enquanto este resultado não for verdade, a sua solução não resolve o problema.
O próximo passo é quebrar a sua solução em vários pedacinhos independentes.
2 - Quebre sua tarefa em várias partes menores
Isto também deve acontecer antes de escrever qualquer linha de código. É ideal planejar o que você vai fazer antes de começar a codificar.
O plano nem sempre vai ser executado 100% como você imaginou, mas saber por onde começar é essencial!
A metáfora do lenhador se encaixa bem aqui: você pode cortar uma árvore em 6 horas de esforço com o machado do jeito que está, ou investir 2 horas afiando o machado e cortar a árvore em apenas 1 hora.
Não corte árvores, tá? O ponto aqui é: coloque mais esforço no seu plano antes de agir e isso vai te salvar tempo, energia e saúde mental!
Pegue um bloco de notas, notas adesivas ou um programa de tarefas e escreva o seu plano de ação. Dê uma olhada no código e anote quais partes do código você vai precisar alterar. Isso ajuda muito a executar a correção depois.
Abaixo eu mostro uma tarefa que eu executei recentemente na minha empresa, olha como eu preparei antes de codificar qualquer coisa. Eu basicamente olhei os requisitos, procurei no código o que eu preciso fazer, onde e anotei lá:
Problema:
Os posts de "press release" ficam dentro do Wordpress e não são disponíveis no nosso site.
Solução:
Disponibilizar os posts de "press release" no nosso site.
Requisitos:
- Adicionar uma rota "/press/{slug}" que mostra o mesmo conteúdo de "/blog/post/{slug}" no Wordpress, mostrar apenas posts na categoria "press release"
- Redirecionar para "/press" se o post não existir ou não pertencer à categoria "press release"
- Adicionar uma rota "/press-releases" que mostra o mesmo conteúdo de "/blog/category/press-release" no Wordpress
Como executar:
- Adicionar rota "/press/{slug}". Ver BlogDetail.php:36
- Adicionar rota "/press-releases". Ver BlogOverview.php:31
- Adicionar redirecionamento para posts fora de "press release". Ver BlogDetail.php:197
- Modificar links canônicos. Ver BlogDetail.php:169
Preparar uma lista desta leva cerca de 20 minutos, e vai guiar o seu desenvolvimento como uma flecha em direção ao centro do alvo 🎯 !
Note que simplesmente por saber "como executar" uma coisa você já não precisa abrir trocentos mil arquivos. Sabemos exatamente quais arquivos abrir e onde olhar.
Siga esta lista item a item, em ordem e sem misturar. Você vai ver como seu fluxo de desenvolvimento vai ficar bem menos confuso! 😉
3 - Refatoração em primeiro lugar!
Refatorar é alterar um código sem mudar seu resultado. Eu escrevi aqui um artigo bem detalhado sobre o livro que original o termo: Refactoring, por Martin Fowler.
Por exemplo, transformar este código (que não faz o menor sentido):
function sum(int a, int b): int {
for (int i = 0; i < b; i++) {
a++;
}
return a;
}Neste código:
function sum(int a, int b): int {
return a + b;
}Isto é uma refatoração. Porque mudamos o corpo da função, mas não mudamos os parâmetros e nem o resultado. (Quem tá prestando atenção sabe que a gente quebrou uma lógica aí, mas vou deixar em aberto)
Note como o primeiro snippet de código é bem mais confuso e, de certa forma, desnecessário.
Às vezes nós escrevemos código assim sem perceber. Coisas que poderiam ser muito mais simples acabam sendo feitas de forma complicada. E é normal, não significa que você seja um mau profissional por escrever código assim.
Mas é exatamente por conta deste comportamento que nós precisamos programar sempre de forma defensiva e preparar o ambiente antes de trabalhar.
Chefs de cozinha têm um nome especial para esta preparação antes do trabalho. É o tal do mise en place.
O nome é chatinho, mas a prática faz todo sentido. Se você for cortar e limpar tudo na hora que precisar, sua cozinha vai ficar um caos.
Mas se tudo estiver preparadinho e antes de montar o prato, a execução em si vai ser simples e rápida e você vai poder focar no que importa.
Nós, que trabalhamos com desenvolvimento de software, também precisamos de um mise en place. O nosso se chama refatoração!
É claro que metáforas são imprecisas em certos pontos, mas esta aqui vai te ajudar a criar uma imagem sobre refatoração que é importantíssima: não é algo "a mais" que você faz mas sim algo essencial pra começar a trabalhar.
Refatoração é o mise en place da pessoa programadora.
A minha dica aqui é: antes de trabalhar numa determinada classe, função ou pedaço da aplicação, faça uma refatoração de leve na intenção de entender melhor aquele código.
Desta forma você vai entender melhor o código antes de escrever alguma coisa, vai ter um ambiente pronto pra trabalhar e, de quebra, vai deixar o código num estado melhor para a próxima pessoa que o visitar. Provavelmente será você mesmo, então refatore pelo seu próprio bem 😉
4 - Refatoração sem testes não é refatoração
Essa ideia de preparar o ambiente é linda, mas o fato é que as vezes nós mudamos uma determinada lógica, uma vírgula e o sistema todo pode entrar em colapso.
Como eu disse antes, refatorar é alterar um código sem mudar seu resultado. Como provar que a mudança que fizemos no código não alterou seu resultado?
Com testes!
De preferência, com testes automatizados. Vamos retomar o exemplo anterior e escrever alguns testes:
Teste 01: positivos
Ao chamar a função sum() com os valores 10 e 20, meu retorno deverá ser 30.
Teste 02: negativos
Ao chamar a função sum() com os valores -10 e -5, meu retorno deverá ser -15.
Teste 03: positivos e negativos
Ao chamar a função sum() com os valores 10 e -5, meu retorno deverá ser 5.
Note que eu não preciso de uma ferramenta específica para escrever testes. O foco é entender que dado algum tipo de entrada, eu espero que a minha função faça algum processamento e gere algum tipo de saída.
Se antes de começar a refatorar os testes estavam passando, ao terminar de refatorar eles devem continuar passando.
O ideal, é claro, é que você utilize uma ferramenta de automação de testes como o PHPUnit ou Jest.
Se você já possui testes, refatore. Se não possui, crie testes primeiro e depois refatore.
5 - Testes são sua melhor ferramenta de apoio
Eu já escrevi alguns artigos sobre como testes podem te ajudar em diferentes aspectos da sua carreira. Desde como aprender linguagens de programação novas usando TDL até como escrever código de forma segura e assertiva com TDD.
O principal ponto aqui é que quando a gente escreve um teste, nos forçamos a pensar sobre o resultado antes mesmo da implementação.
Quanto mais você praticar e escrever testes, mais natural vai ser programar por intenção em vez de por coincidência.
Além disso, um teste bem escrito também serve como guia para a próxima pessoa que precisar entender aquele pedaço de código ou como usar aquela função.
6 - Refatore após terminar de codificar sua funcionalidade
Se você já fez uma refatoração antes de codificar, deve entender bem o que o código faz.
Se ao fazer a refatoração e implementar a funcionalidade do jeito que precisava os testes continuam passando, sua tarefa está quase pronta para ser entregue: precisa ser finalizada com uma bela refatoração!
Lembre-se: pessoas programadoras mais experientes escrevem código para pessoas, não para computadores.
Agora que seus testes estão passando, dê aquela polida no código para que fique mais fácil entender. A próxima pessoa que ler seu código vai ficar agradecida. Lembre-se que esta pessoa provavelmente será você mesmo 😉
Ao finalizar uma entrega, refatore o seu código para facilitar a vida de quem vai fazer a revisão.
Se você refatorar o código pensando em quem vai revisar, com total certeza vai fazer com que seja mais fácil de ser lido por um humano.
Conclusão
Caso não tenha ficado claro, deixemos claro aqui: programar por coincidência é ruim! Isto vai atrasar a sua vida, a sua carreira e o seu time.
Adote as 6 dicas que mencionei no texto e vai notar como programar vai ficar bem mais fácil pra ti!
Sempre que escrever algum trecho de código, faça o máximo esforço possível para entender a intenção do código que quer escrever.
Comentários