sexta-feira, 7 de outubro de 2011

20 dicas para programadores

Olá povo,

Conviver com pessoas mais experientes é uma coisa muito boa, pois você pode explorar o know-how dessas pessoas e crescer profissionalmente (e às vezes pessoalmente). Eu tenho a satisfação de ter trabalhado, tido aulas e ter sido orientando por Luiz Eugênio Fernandes Tenório (left), um excelente profissional de desenvolvimento de software (senão o melhor que conheço).
Em 21 de agosto de 2007, ele me mandou um email com um texto de Jonathan Danylko que a muito tempo queria postar aqui no blog. É um conjunto de boas práticas, que um desenvolvedor de software pode seguir para melhorar a produtividade e a qualidade do seu trabalho. Adotei uma boa parte dessas dicas, e notei bons resultados através de feedbacks de gestores e colegas de trabalho. E por causa disso, resolvi compartilhar com vocês.

O texto abaixo é uma tradução/adaptação minha (vixe!) do texto original em inglês disponível aqui.

  1. Defina quanto tempo você acha que deve gastar para resolver um problema. Já vi programadores sentarem na frente de um monitor por oito horas para resolver um problema e nada. Defina uma tabela de tempo para si mesmo de 1 hora, 30 minutos, ou até mesmo 15 minutos. Se você não conseguir descobrir uma solução para seu problema dentro de seu prazo, peça ajuda ou pesquise seu problema na Internet em vez de tentar ser um super-coder.
  2. As linguagens são similares. Com o tempo, você entenderá como uma linguagem funciona, então você vai notar semelhanças com outras linguagens. A linguagem que você escolher deve: te fornecer um nível de "conforto" adequado, a capacidade de produzir código eficiente (e limpo), e acima de tudo, se adequar ao projeto e vice-versa.
  3. Não exagere nos padrões de projeto. Pense duas vezes antes de usá-los, se houver uma solução mais simples (e que funcione), use-a. Um problema que necessita de um padrão de projeto como solução, será identificado naturalmente (obviamente depois de um certo tempo de experiência).
  4. Sempre faça backup do código. Quando eu era mais novo, por uma falha no disco rígido, perdi um monte de código, e me senti horrível por causa do que tinha acontecido. A única vez que você não fizer backup dos dados, pode ser o momento onde você tem um prazo restrito com um cliente, e eles precisam do que você estava fazendo para amanhã. Controle de código fonte/versão (CVS, SVN, GIT,...) também se aplica aqui.
  5. Você não é o melhor em programação. Aceite isso. Eu sempre pensei que eu sabia muito sobre programação, mas sempre há alguém lá fora (ou do seu lado), melhor que você. Sempre! Aprenda com eles.
  6. Aprenda a aprender mais. Como número cinco explicou, eu sempre tive à mão uma revista ou livro sobre computadores/programação  (pergunte aos meus amigos, eles vão confirmar). Verdade, há muita tecnologia lá fora, e manter-se com ela é um trabalho em tempo integral. E se você tem uma maneira inteligente de receber novidades, você vai aprender sobre novas tecnologias a cada dia.
  7. Mudanças são constantes. Seu conhecimento de tecnologia e/ou programação deve ser semelhante à forma como você trata investimentos: Diversifique. Não fique muito confortável com uma tecnologia particular. Se não houver suporte suficiente para aquela linguagem ou tecnologia, é bom você pode começar a atualizar o seu currículo imediatamente, e começar o seu período de treinamento. Minha regra geral: Conheça pelo menos duas ou três linguagens, assim, se uma morre, você tem outra para trabalhar enquanto você estuda uma nova para colocar no lugar.
  8. Ajude os novatos. Oriente os desenvolvedores iniciantes sobre as boas técnicas de programação. Você nunca sabe... mas você pode ganhar pontos com isso, e vai se sentir mais confiante de ter, pessoalmente, treinado e preparado uma pessoa para seu próximo trabalho.
  9. Simplifique o algoritmo. Codifique como um demônio, mas quando estiver tudo pronto, volte para otimizá-lo. Uma pequena melhoria no código aqui e ali, e você terá uma manutenção de código mais feliz no longo prazo.
  10. Documente seu código. Se a documentação é uma API de Web Service ou uma simples classe, documente do mesmo jeito. Eu tenho sido acusado de excesso de comentários no meu código, e isso é algo que eu me orgulho. Leva apenas um segundo para adicionar uma linha de comentário adicional para cada 3 linhas de código.
  11. Teste, teste e teste. Eu sou um fã de testes de caixa preta. Quando sua rotina é concluída, o seu período de "selo de aprovação" começa. Se você tem um departamento de Quality Assurance, você pode estar falando mais para eles do que para seu gerente de projeto sobre os erros em seu código. Se você não testar seu código completamente, você pode desenvolver mais que código, e possivelmente uma má reputação.
  12. Celebre todo sucesso. Se um programador feliz te pedir para vir ver sua obra extraordinária de código, mesmo que você já tenha visto um trecho de código como esse mais de 100 vezes em suas experiências, comemore o sucesso desse desenvolvedor.
  13. Faça revisão de código frequentes. Em projetos e pessoalmente. Na empresa, você sempre terá as revisões de código de quão bem você codificou alguma coisa. Não olhar para isso como pessoas crucificando o seu estilo de codificação. Pense nisso como uma crítica construtiva. Quando estiver na revisão, pergunte: "Como eu poderia ter feito melhor?" Isto irá acelerar o seu aprendizado e torná-lo um programador melhor.
  14. Relembre seu código antigo. Existem duas maneiras de olhar para código antigo: "Eu não posso acreditar que eu escrevi este código" e "Eu não posso acreditar que eu escrevi este código." A primeira afirmação é muitas vezes de nojo e perguntando como você pode melhorá-lo. Você ficaria surpreso como um código antigo pode ser ressuscitado em uma rotina possível e melhor, ou até mesmo um produto inteiro. A segunda declaração é de espanto e realização. Desenvolvedores têm suas conquistas de código, aquelas que eles concluíram e todos tomaram conhecimento.
  15. Humor é necessário. Em meus 20 anos de desenvolvimento, eu nunca conheci um programador que não tem um senso de humor decente. Na verdade, nesta indústria, é uma exigência.
  16. Cuidado com o programador sabe-tudo, programador possessivo e o programador inexperiente. O programador sabe-tudo tenta relegar você em vez de trabalhar como um membro da equipe. O programador possessivo cria o código e não quer partilhar com ninguém. E o programador inexperientes pede ajuda constantemente (a cada dez minutos) ao ponto que o código desenvolvido é seu, não dele.
  17. Jamais um projeto será simples. Se alguém precisa de um site de 3 páginas com o Microsoft Access no início, ele acaba se tornando um site de 15 páginas com o SQL Server, um fórum e um CMS personalizado (Content Management System).
  18. Nunca tome nada como garantido. Se você levar em um projeto simples, você pode pensar que uma determinada seção será fácil de concluir. Não pense, mesmo por um momento. Ao menos que você tenha uma classe, componente, ou um pedaço de código já codificados, testado exaustivamente e em produção. A partir de um projeto existente, não pense que será fácil.
  19. Software nunca está acabado. Um colega programador me disse uma vez que o software nunca está acabado, está "temporariamente concluído". Bons conselhos. Se o cliente ainda está usando um programa que você escreveu e tem resistido ao teste do tempo, existem boas chances de você ainda estar atualizando-o, o que não é uma coisa ruim. Mantém seu emprego.
  20. A paciência é definitivamente uma virtude. Quando os clientes, amigos ou membros da família usar um PC, ficam frustrados e partem para bater no computador. Eu continuo dizendo a todos: "você está controlando o computador, não o contrário". Você precisa ter um certo nível de paciência para programar computadores. Tão logo os programadores entendem o que fizeram de errado, eles dizem: "Ah, é por isso que estava acontecendo isso".


Qualquer sugestão, deixem seus comentários.

4br4ç05,
nglauber

5 comentários:

Ricardo Gilson disse...

Muito bom professor.... parabéns pelo trabalho.

LLLLLL disse...

Tentarei seguir as dicas...

Unknown disse...

Posso postar isso em uma rede social informando a fonte?

Nelson Glauber disse...

Oi Ilken,

Claro. Sem problemas :)

4br4ç05,
nglauber

Unknown disse...

blz professor.. good job!