Hábitos ruins são difíceis de quebrar e ainda mais difíceis se você não perceber que o que você está fazendo está minando o seu trabalho. Se você sabe mas não se importa – isso seria o pior. Mas você está aqui, não está?
Como programador, tenho visto muitas práticas ruins, não só em torno do código, mas também em torno das habilidades de trabalho em equipe. Eu próprio tenho sido culpado de praticar muitos destes maus hábitos. Aqui estão os meus 35 principais maus hábitos de programação, organizados em quatro categorias: organização do código, trabalho em equipe, escrita de código e testes e manutenção.
Organização do código
1. Dizendo: “Eu vou corrigir mais tarde”
O hábito de adiar correções de código não é apenas um problema de prioridades. Organizar o seu rastreador de problemas pode gerar algum progresso, mas você também precisa ter uma forma de rastrear problemas menores que surjam. Adicionar comentários “TODO” é uma forma rápida de garantir que não perde nada.
2. Insistir numa solução de uma linha
Ser obsessivo sobre escrever peças de código eficientes e elegantes é uma característica comum dos programadores. É como resolver um puzzle – você encontra uma combinação de funções e expressões regulares que transformam 20 linhas de código em 2 ou 3. Infelizmente, nem sempre resulta em código legível, e esse é geralmente o resultado muito mais importante. Faça o seu código acessível primeiro, depois inteligente.
3. Fazer optimizações sem sentido
Outro lugar onde muitas vezes nos desviamos dos nossos esforços são as optimizações. Parece óptimo reduzir o tamanho do seu website em alguns bytes, mas o gzip não vai compensar de qualquer forma? E os pedidos não são mais importantes? Optimizações de endereços no final de um projecto, porque na maioria das vezes, os requisitos mudam, e o seu tempo terá sido desperdiçado.
“A optimização prematura é a raiz de todo o mal.”
-Donald Knuth
4. Convencer-se de que as questões de estilo não são tão importantes
Se aprendi alguma coisa ao longo de anos a olhar para o código de outras pessoas, é que lidar com questões de estilo de código é o que os programadores mais provavelmente adiam. Talvez seja difícil para codificadores inexperientes ver o bem que sairá da abordagem de problemas de estilo, mas com o tempo ficará evidente que uma vez que a qualidade do código descarrile, um efeito bola de neve transformará qualquer projeto em uma bagunça completa. Seja rigoroso quanto às melhores práticas, mesmo que elas pareçam insignificantes. Configure ferramentas de checagem de código e de impressão para dar a si mesmo espaço para se preocupar com as coisas mais importantes.
5. Varrer coisas por baixo do tapete
Evite as excepções, ou usando bibliotecas que não reportam erros (como jQuery), há muitas maneiras de varrer coisas por baixo do tapete. Mas quando um desses erros se torna uma prioridade, o desafio de corrigi-lo será muitas vezes maior, considerando que você não terá uma pista de onde começar. Uma maneira fácil de evitar isso é registrando esses erros ignorados para que você possa estudá-los mais tarde.
6. Usar nomes que não adicionam informação
Naming é difícil, mas há uma maneira fácil de se certificar que os nomes das suas variáveis e funções são, pelo menos, de qualidade decente. Desde que os nomes adicionem algum tipo de informação que o resto do código não transmita, outros programadores terão mais facilidade em ler o seu código. A razão pela qual a nomeação é tão importante é que os nomes podem dar uma ideia geral do que o código faz. Leva mais tempo se você precisar escavar nos cálculos para descobrir o que o código faz, mas um bom nome pode ajudá-lo a entender o que o código faz em segundos.
7. Ignorando as melhores práticas comprovadas
Code reviews, test-driven development, quality assurance, deployment automation – essas práticas, e várias outras, têm provado seu valor em inúmeros projetos, e é por isso que os desenvolvedores blogam constantemente sobre eles. Uma grande referência para estas melhores práticas é o livro Making Software: What Really Works, and Why We Believe It (O que realmente funciona e porque acreditamos nisso). Tome um tempo para aprender a fazê-las corretamente, e seu processo de desenvolvimento irá melhorar em todos os seus projetos de forma a surpreendê-lo.
Teamwork
8. Abandonando planos muito cedo
Uma forma segura de tornar o seu sistema impenetrável é não se comprometer com um plano. Você sempre pode dizer, sempre que seu código for criticado, que o plano não está completo. No entanto, ter módulos meio feitos levará a um código bem acoplado assim que você tentar fazer esses módulos inacabados trabalharem uns com os outros. Este tipo de complicação também surge quando os papéis de liderança de um projeto mudam e os novos leads decidem que tê-lo à sua maneira é mais importante do que a consistência arquitetônica.
9. Insistir em um plano que tem poucas chances de funcionar
Apenas porque abandonar seus planos pode causar problemas, então pode se ater a um plano que não funciona. É por isso que deve partilhar as suas ideias com a sua equipa para obter feedback e conselhos quando as coisas se complicam. Às vezes uma perspectiva diferente pode fazer toda a diferença.
10. Trabalhar por conta própria o tempo todo
Você deve esforçar-se para compartilhar seu progresso e suas idéias com a equipe. Às vezes você pensa que está construindo algo da maneira certa, mas não está, então a comunicação constante é muito valiosa. Também é benéfico para as outras pessoas quando você trabalha com elas. O trabalho deles muitas vezes melhora quando você discute idéias com eles e orienta os membros menos experientes da sua equipe, que têm mais probabilidade de ficar presos.
11. Recusando-se a escrever mau código
Há um momento na vida de cada desenvolvedor em que os prazos vão forçá-lo a escrever um código terrível, e não há problema. Você tentou avisar o seu cliente ou gerente sobre as consequências, mas eles insistem em cumprir o prazo, por isso agora é hora de codificar. Ou talvez haja um bug urgente que mal pode esperar para que você encontre uma solução limpa. É por isso que é importante ser versátil como programador e ser capaz de escrever código pobre muito rapidamente, assim como código bom. Esperamos que você possa revisitar o código e pagar a dívida técnica.
12. Culpando outros
Não é segredo que a arrogância é uma característica muito comum entre os programadores e outros profissionais técnicos. Assumir a responsabilidade pelos seus erros é uma virtude que o fará brilhar entre os seus pares. Não tenha medo de admitir que você cometeu um erro. Uma vez que você esteja de acordo com isso, você será livre para se concentrar em aprender porque você cometeu esse erro e como evitá-lo. Se você não for dono disso, aprender torna-se impossível.
13. Não compartilhar com sua equipe o que você aprendeu
Seu valor como desenvolvedor não é colocado apenas no código que você escreve, mas também no que você aprende ao escrevê-lo. Partilhe as suas experiências, escreva comentários sobre isso, informe os outros porque as coisas são como são, e ajude-os a aprender coisas novas sobre o projecto e as suas complexidades.
14. Ser demasiado lento a dar feedback aos gestores/clientes
Um dos traços mais valiosos de qualquer artesão é ter a certeza de que todos estão na mesma página sobre o trabalho, na medida do possível. A razão para isso não é para que seu gerente possa preencher as planilhas. É para o seu próprio ganho também: Você terá menos inseguranças e reduzirá a incerteza sobre a vida e o futuro do projeto.
15. Não usar o Google o suficiente
A melhor maneira de resolver um problema complexo rapidamente é não ter de o resolver de todo. Em caso de dúvida, Google. Claro que pode incomodar o engenheiro ao seu lado, mas raramente ele será capaz de dar uma resposta tão detalhada como o Stack Overflow, para não mencionar que também estará a interromper o seu trabalho.
16. Overvaluing your personal style
Always aim to coordinate your working style and environment setup with your team. Idealmente, todos na sua equipa devem trabalhar em condições semelhantes e seguir o mesmo estilo de codificação. Fazer as coisas à sua maneira pode ser mais divertido, mas os colegas de trabalho podem não estar habituados ao seu estilo de codificação, e se for invulgar, será mais difícil para o próximo programador trabalhar no que você construiu.
17. Ter um anexo pessoal ao seu código
Quando alguém comentar o seu código, não o leve para o lado pessoal. Seu código deve ficar em terra firme; isto é, você deve ser capaz de explicar porque você o escreveu dessa maneira. Se precisa de melhorias, isso é apenas um reflexo da correcção do código, não de si mesmo.
Escrever código
18. Não saber como otimizar
Uma boa estratégia de otimização requer alguma experiência para ser correta. É preciso explorar, analisar e conhecer cada sistema envolvido em um processo. Informe-se sobre estas coisas. Aprenda sobre complexidade algorítmica, avaliação de consultas de banco de dados, protocolos e como medir o desempenho em geral.
19. Usando a ferramenta errada para o trabalho
Você só pode saber tanto, mas a razão pela qual você tem que continuar aprendendo é que cada novo problema traz um contexto diferente e requer uma ferramenta diferente – uma mais aplicável à tarefa em questão. Esteja aberto a novas bibliotecas e idiomas. Não tome decisões baseadas estritamente no que você sabe.
20. Não se preocupe em dominar suas ferramentas e IDE
Cada nova tecla de atalho, atalho ou parâmetro que você aprender enquanto utiliza as ferramentas com as quais você trabalha todos os dias terá um efeito mais positivo na sua velocidade de codificação do que você imagina. Não se trata de poupar alguns segundos utilizando uma tecla de atalho; trata-se de reduzir a mudança de contexto. Quanto mais tempo você gastar em cada pequena ação, menos tempo você terá disponível para pensar sobre o porquê de você estar fazendo isso e sobre o que vem em seguida. Dominar atalhos irá libertar a sua mente.
21. Ignorando mensagens de erro
Não assuma que sabe o que está errado com o seu código sem sequer ler uma mensagem de erro, ou que o vai descobrir rapidamente. Ter mais informação sobre um problema é sempre melhor, e tirar tempo para recolher essa informação irá poupar mais tempo a longo prazo.
22. Romanticizing your developer toolkit
Someadamente o seu editor preferido ou ferramenta de linha de comando não é a melhor ferramenta para o trabalho em questão. Visual Studio é ótimo para escrever IDEs, Sublime é ótimo para linguagens dinâmicas, Eclipse é ótimo para Java, e assim por diante. Você pode adorar vim ou emacs, mas isso não significa que seja a ferramenta certa para cada trabalho.
23. Valores hardcoding em vez de os tornar configuráveis
Sempre pense no que as mudanças podem vir e como lidar com elas. O débito técnico irá crescer a uma taxa monstruosa se não separar as peças em movimento do resto do seu trabalho. Use constantes e arquivos de configuração onde apropriado.
24. Reinventando a roda o tempo todo
Não escreva código que não seja necessário. Talvez outra pessoa já tenha gasto muito tempo com o seu problema, e ele ou ela pode ter uma solução bem testada que você pode reutilizar. Poupe-se a alguns problemas.
25. Copie/colar cegamente o código
Código de compreensão antes de reutilizá-lo. Por vezes não repara imediatamente em tudo o que o código está a fazer, à primeira vista. Também aprenderá mais sobre um problema quando tiver tempo para ler o código em detalhe.
26. Não tendo tempo para aprender como as coisas realmente funcionam
Tempre aproveite a oportunidade para expandir seu conhecimento pensando em como as coisas funcionam e lendo sobre seus problemas subjacentes. Pode poupar tempo ao não se preocupar agora, mas o que aprender num projecto será mais importante a longo prazo do que realmente fazê-lo.
27. Ter confiança excessiva em seu próprio código
É perigoso assumir que só porque você escreveu algo, deve ser ótimo. Você aprende mais sobre programação enquanto trabalha em coisas novas e ganha experiência, então dê uma olhada no seu código antigo de vez em quando e reflita sobre como você progrediu.
28. Não pense nas compensações de cada projeto, solução ou biblioteca
Todos os produtos têm seus pontos finos que você só vai aprender usando e analisando. Ver alguns exemplos de utilização de uma biblioteca não fará de si um mestre, nem significa que seja a solução perfeita para cada situação que surja no seu projecto. Seja continuamente crítico de tudo o que você usa.
29. Não obter ajuda quando está preso
A manutenção de um pequeno ciclo de feedback será sempre menos doloroso para si. Pedir ajuda não significa que você seja incompetente. As pessoas certas verão o seu esforço e admissão de ignorância como um impulso para aprender, e isso é uma grande virtude a ter.
Teste e manutenção
30. Testes de escrita para passar
Testes de escrita que você sabe que será aprovado é necessário. Eles irão tornar a refatoração e reorganização de um projeto muito mais segura. Por outro lado, você também tem que escrever testes que você sabe que não passarão. Eles são necessários para fazer avançar o projecto e manter um registo dos problemas.
31. Descartando testes de desempenho para casos críticos
Prepare uma configuração de testes de desempenho automatizados mais ou menos no ponto médio do processo de desenvolvimento de um projeto para que você possa ter certeza de que não terá problemas de desempenho crescentes.
32. Não verificar se o seu build funciona
É raro quando um build passa mas não funciona realmente, mas pode acontecer, e pode ser problemático corrigir o problema quanto mais tempo você espera para olhar para ele. Testar rapidamente cada build é um hábito importante a ter.
33. Empurrar grandes mudanças tarde, ou sair depois de fazer um grande empurrão
É aqui que o excesso de confiança o levará, e pode ser preciso queimar-se várias vezes para aprender porque não deve fazer isto, por isso siga o meu conselho agora e certifique-se que está sempre presente quando a sua compilação eventualmente se parte.
34. Desproibindo código que você escreveu
Esteja disposto a suportar o código que você escreveu. Você é a pessoa mais adequada para ajudar os outros a compreendê-lo. Você deve esforçar-se para fazer o seu código permanecer legível para si próprio e para os outros daqui a muitos anos.
35. Ignorando os requisitos não funcionais
Quando você está tentando entregar algo, pode ser fácil esquecer algumas áreas importantes, como desempenho e segurança. Mantenha uma lista de verificação para essas áreas. Você não quer que eles arruínem sua festa porque você elaborou seus prazos sem pensar nessas preocupações não-funcionais.
Quais são seus piores hábitos de programação?
Como é dito com freqüência, somos criaturas de hábitos. Melhorar a forma como você trabalha através dos hábitos é uma ótima maneira de evitar ter que pensar demais em cada situação. Uma vez que você assimilou uma boa maneira de fazer algo, torna-se sem esforço.