Que atire o primeiro mouse o programador que nunca contou uma mentirinha durante sua carreira. Seja para enganar a si mesmo, seja para ganhar tempo, seja para ficar bem na rodinha, todo mundo já exagerou um pouco, já cometeu uma gafe. Obviamente, estamos falando de pequenas lorotas. Escrever no currículo que tem dez anos de experiência em Swift ou que manja de Assembly, C, COBOL e Pascal quando não sabe nem fazer um “hello world” em JavaScript não merecem perdão. Está feio isso, pode parar, está todo mundo comentando.
Mas não considere essa lista de pequenas lorotas como uma lista a preencher para platinar o grande jogo da Programação. Muito pelo contrário: queremos que você ponha a mão na consciência e pare de repetir estas falsidades por aí e queimar o filme da classe toda!
1) “Meu código não precisa de comentários”
Você se acha o último biscoito (ou bolacha) do pacote. Sua mente é perfeita e à prova de falhas e sua memória daria inveja em um elefante. Comentários? Para os fracos e inseguros que não conseguem bater o olho em um código e adivinhar em fração de segundos o que uma função executa. Você é especial, seu estilo de codificar nunca vai mudar porque já é perfeito. Todo mundo é capaz de entender que AltNoUsu() é uma função para Alternar Nozes do Urso “Sussegado”. Ou será que não?
Tome um chá de realidade e perceba que seu código não é “seu” código, ele pertence à empresa, ao projeto, e amanhã uma pessoa completamente diferente pode ser obrigada a dar manutenção naquilo que você fez e essa pessoa irá xingar sua querida mamãe de nomes pavorosos se você não foi claro sobre o que cada parte do código realiza. Essa pessoa completamente diferente pode inclusive ser você mesmo, cinco anos depois, com outra cabeça, outra forma de programar e aí você não terá nem mesmo alguém para xingar.
2) “Isso não deve demorar”
O chefe pede para corrigir um “buguezinho” na aplicação, coisa pequena e você manda na lata: “isso não deve demorar, deixa comigo”. Você calcula mentalmente que antes do almoço está tudo pronto e o resto da tarde vai ser dedicado a vídeos de fails no YouTube. Três dias depois, uma força-tarefa de cinco programadores ainda está afundada no problema, sem previsão de solução, sem hora extra, sem café.
O que aconteceu? Um erro de avaliação? Vontade de agradar o chefe? Excesso de confiança? Um bug mutante maldito jamais visto na História da Ciência da Computação? Arrogância? Seja o que for, da próxima vez respire fundo, encare o problema de frente e diga bem alto: “preciso de tempo para analisar”. Você irá ouvir do seu chefe: “isso não deve demorar”. Três dias depois…
Mas, pelo menos nesse cenário, não será você quem terá falado a mentira.
3) “Eu posso fazer melhor eu mesmo”
Existem frameworks, templates, tutoriais, best practices, APIs e toda sorte de conteúdo já disponível na Internet. Mas você enfia na cabeça que sua roda é melhor que a de todo mundo e decide reinventá-la. Vai compilar melhor, você pensa. Vai melhorar a performance, você pensa. Vai ser mais leve para o usuário, você pensa. E lá está você usando códigos obscuros, funcionalidades não documentadas, loops excessivos, vazando memória feito uma caixa d’água furada e todo mundo ao redor te perguntando quando você vai entregar sua parte no projeto.
Como um cientista louco, você estende suas mãos em garra para o céu e responde que sua invenção irá revolucionar o mundo! O mundo! Que meros mortais podem saber sobre o trabalho de um gênio? Em breve todos conhecerão o mais perfeito “hello world” jamais feito!
4) “Eu conserto depois”
Correria do deadline estourando e não dá tempo de fazer tudo certinho como manda o figurino? Hora da gambiarra, de colocar chiclete no código pra colar, bater na madeira três vezes e mandar compilar. Funcionou? O prédio não explodiu? Embala e entrega e a gente conserta depois, bate aqui.
Mas o depois nunca chega, outro projeto aparece, outra demanda e o bug fica adormecido ali só esperando o momento mais inconveniente para se manifestar, geralmente na presença do cliente ranzinza. A vida corre, você devia ter pedido um pouco mais de prazo, explicado a situação.
Agora são duas da manhã, você está virado no escritório porque descobriram um caso de uso que acorda o bug. E você infelizmente também caiu na primeira mentira e está coçando a cabeça para entender como AltNoUsu() funciona (ou deveria funcionar).
5) “É só uma pequena mudança”
O programa está lá funcionando direitinho conforme as especificações, o usuário está até feliz, vejam vocês. Mais um projeto bem-sucedido. Ou será que não? Será que se você acrescentar aquela funcionalidade descartada anteriormente o sistema não fica mais ágil? É só uma linha de código, certo? Que mal pode fazer, não vai nem se comunicar com o banco de dados, é puramente cosmético e…
… e aí quebra tudo, por que está tudo integrado, por que você acordou o bug escondido, por que alguém em algum ponto esqueceu de comentar “não mexa aqui, se você tem amor à vida”. Existem dependências inesperadas, consequências imprevistas e quando você se dá conta não consegue localizar a cópia de backup, o telefone está tocando sem parar e seu perfil no Linkedin está desatualizado.
6) “Funciona na minha máquina”
Você sabe que a penicilina, um dos primeiros antibióticos, foi descoberto por mero acaso? Às vezes, soluções fantásticas aparecem de situações inesperadas. Não é o caso do seu código, lamento dizer. Ele está quebrado mesmo.
Você testou (ou acha que testou), você escreveu tudo direitinho (ou acha que escreveu), você viu que funciona (ou acha que viu) e então o cliente liga reclamando, falando em feridos e que a Saúde Pública interditou o perímetro. Por quê? Porque seu ambiente de desenvolvimento não é o mesmo que o ambiente de produção, porque você não considerou as necessidades do projeto e porque o lixo de um homem é o tesouro de outro e vice-versa. Uma vez que você não pode dar sua máquina para o cliente rodar o sistema, o jeito é colocar a viola no saco e aceitar que tem algo errado no código.
7) “Eu sei o que estou fazendo”
Especificações são para perdedores. Reuniões são para inseguros. Regras? Normas? Muletas patéticas para a escória de script kiddies que sai das faculdades da esquina com um pedaço de papel embaixo do braço. Você, e apenas você, sabe o que é o melhor para o projeto, para o cliente, para a vida. Pra que servem design, arquitetura, planejamento se é o código que faz tudo acontecer? Você senta na mesa e começa a teclar com olhos apenas na meta e ouvidos tampados. Só você trabalha nessa firma!
Nesse momento, você acorda. O projeto foi para um lado, você foi para outro, suas partes não se interconectam mais e tem um estagiário encarregado de refazer seu código, perguntando o que AltNoUsu() faz.
8) “Eu posso pular o teste”
Se existe uma coisa que os programadores odeiam mais do que escrever comentários é fazer testes. Geralmente mecânicos e repetitivos, são tão divertidos quanto ver a grama crescendo. Se o código está todo certinho, para que testar? É óbvio que vai funcionar, certo?
Mas se não houvesse testes na indústria automobilística as estradas seriam um matadouro sem fim. Se não houvesse testes na indústria alimentícia, imagine o que você estaria colocando na sua barriga agora. Por melhor que seja a metodologia, por mais formal que seja o código, é preciso testar, testar sempre, testar contra todos os cenários, testar contra milhões de usuários simultâneos, testar para aquela sua tia velhinha do interior que enxerga mal e ganhou um PC ontem, testar hipóteses, testar o previsível e o impossível.
E, quando tudo terminar, testar de novo.
9) “Eu estou usando _________, então tudo vai dar certo”
Você ri daqueles malucos brigando por causa de time de futebol, condena o fanatismo religioso, bloqueia gente no Facebook que se exalta em época de eleição. “Radicais, todos eles”, você pensa. Mas vira uma fera se alguém fala mal daquela linguagem de programação que você usa todo dia. Você pula na mesa de quem não curte Java, põe sal no café de quem critica o .NET, usa uma camisa onde está escrito “PHP or Die”, para de falar com quem ousar reclamar da performance do Python.
Você foi às principais palestras e tem até uma ou duas certificações na linguagem. Consequentemente, essa sua linguagem de coração é a resposta para todos os problemas, a cura do câncer, o caminho e a vida. Pequenos projetos, grandes projetos, web, desktop, qualquer cenário ela resolve. Se fosse possível, você passava ela no pão e comia, casava com ela e tinha filhos.
Se a especificação do projeto determina o uso de outra linguagem, você será o chato que ficará do primeiro minuto até o dia de entrega reclamando e jurando que tudo teria sido melhor com ___________. Se o projeto é feito com a linguagem que você curte? Ela é perfeita, não tem defeitos e tudo se resolverá. Fiquem tranquilos, estamos salvos. Aleluia!
Confira a versão em vídeo das “nossas” mentirinhas!
Esse e muitos outros temas estão lá no nosso canal youtube.com/codigofontetv!
