 |
| Foto: riebschlager |
Como ser um bom programador
Programação é uma atividade intelectual, racional, emocional, artistica, espiritual e mística. Tudo depende do como cada pessoa vai trilhar este caminho.
Seguindo na proposta de comentar sobre otimização, desenvolvimento e outras coisas, coloco então algumas observações que tenho coletado, observado e principalmente, vivenciado nestes anos todos.
Tornar-se um bom programador tem a ver com desenvolver suas habilidades pessoais em primeiro lugar. Ter gosto pelo estudo mas sem se apegar a dogmas e paradigmas. Estar pronto a revisar conceitos. Procurar fazer o melhor de si.
Claro que aprender tecnologias é importante, mas de nada adianta decorar milhares de parágrafos de informação se na parte da interação social entre você e as demais pessoas, o computador ficar como uma barreira.
O programador realiza a tarefa de projetar em detalhes e traduzir para o computador uma determinada tarefa humana. É isto que deve ser lembrado, os computadores devem estar a serviço da humanidade e é por isto que é sempre bom aprender sobre as pessoas.
Nosso trabalho é aprimorar as maneiras de se conseguir isto, mesmo que seja trabalhando muito mais para que outros possam trabalhar muito menos.
Acredite que você pode fazer melhor e trabalhe para isto.
Se você encontrar algo errado, arrume. Não interessa quem fez, se está na sua mão é responsabilidade sua melhorar ou resolver o problema.
Simplifique a vida do usuário. Seu programa deve ser simples e fácil de usar. Inclua tratamento decente de erros, com mensagens claras e objetivas. Crie tratamento automatizado para os erros mais comuns.
Teste seu programa de todas maneiras. Teste seu programa de todas maneiras. E principalmente, teste seu programa de todas maneiras. Só porque tem um botão na tela, não pense que alguém vai clicar direto nele. É mais provável que vão fazer de tudo, e as vezes, até clicar o maldito botão.
Documente seu código. O código deve ser claro, auto-documentado. Evite siglas e menmonicos, prefira nomes auto-explicativos.
Use bem os recursos de máquina. Boa performance economiza tempo, energia e ajuda a conservar o meio ambiente.
Dedique o tempo necessário para conseguir uma boa solução. Mas não gaste mais tempo do que o benefício que se pretende conseguir.
Identação de código é obrigatório. Desculpe, mas se você não entende nem isto, por favor, mude de ramo, esqueça programação e nunca mais chegue perto de um programa.
Lembre que algum dia alguém vai ter que mexer neste programa. Pode ser até você mesmo, mas com certeza, os comentários e clareza do código serão de imensa ajuda.
Evite malabarismos desnecessários só para mostrar que aprendeu alguma mágica diferente.
Elimine código inútil ou sem uso.
Fuja do código spaghetti tanto quanto possível.
Divida o programa em pequenas secções, use funções, etc.
Pense no que está fazendo. Longas cadeias de IFs ou IFs quilométricos, que se extendem por páginas e páginas são uma fonte certa de dor de cabeça e não tem a mínima justificativa.
Faça modelos ou programas de exemplo para testar o funcionamento das diferentes partes, algoritmos e/ou funcionalidades.
Nenhum otimizador de programa ou SQL ou seja o que for, vai fazer milagre se o seu código for mal feito. Pode até melhorar um pouco e virar um código mal feito otimizado. Otimizadores funcionam bem mesmo é com código razoavelmente bem feito. Nenhum deles vai fazer milagre em arrumar lógica absurda.
Máquina mais rápida faz código ruim rodar um pouco menos devagar. Melhore o código até chegar ao equilíbrio entre tempo de desenvolvimento versus custo de hardware.
Lembre, programar é a arte de dizer ao computador quais são os passos que deve executar com as informações. Ponto. Portanto, estude lógica e pratique.
Verifique, compile, teste seu programa com frequencia.
Leia seu código fonte. Quanto mais você ler o código fonte, melhor vai ter compreensão dele.
Use padrões.
Reutilize código que funciona. Crie funções genéricas para atender necessidades comuns.
Use sua auto-crítica.
Otimize. Reotimize. Melhore e aperfeiçoe.
Adote um padrão de codificação.
 |
| Foto loupiote (Old Skool) |
Não seja preguiçoso. Fazer algo correndo pode lhe custar dez vezes mais tempo mais tarde. Ao invés de ser preguiçoso, use sua criatividade para desenvolver ferramentas que vão tornar seu trabalho mais fácil. Lembre, no início havia apenas a linguagem de máquina. Depois algum programador criou o Assembler e as linguagens de programação que facilitaram tudo.
São os programadores quem vão criar as ferramentas que serão usadas amanhã, portanto, não espere encontrar tudo pronto nalguma ferragem.
KISS. Sigla de "Keep It Single Stupid". Tradução: Faça isto simples estúpido!
Código bom é código simples. Mesmo que seja uma rotina complexa, pode ser feita com clareza a objetividade.
Não se case com nenhuma idéia. A pior coisa é você estar atrelado a uma grande idéia e ter apenas uma única grande idéia.
Mantenha contato com seus superiores e usuários para saber se vocês estão indo na mesma direção.
Converse com outros desenvolvedores para debater sobre o código, algoritmos, metodologias, etc. Conversa de bar está liberada.
Mantenha-se informado e adote novas tecnologias sempre que adequado.
Estudar novas tecnologias e também outras áreas, incluindo ciências humanas, lhe trazem idéias, inspiração e conhecimento sobre diferentes maneiras de fazer as coisas, de pensar, analisar e solucionar problemas.
Aprenda outras linguagens e principalmente, aprenda a programar de maneira diferente pois cada linguagem tem conceitos diferentes. Se você faz a mesma coisa com linguagens diferentes, está desperdiçando o potencial que cada ferramenta possui. É por isto que vejo tanto programa spaghetti feito em linguagem Java!
Não existe uma linguagem que seja ótima para tudo. Se necessário, adote linguagens que possam ser complementares, utilizando o melhor de cada uma, de acordo com a necessidade a ser atendida.
Pense para o futuro! A sigla de tecnologia da moda de hoje, será ultrapassada em dois anos.
Em cinco anos você vai descobrir que a linguagem atual é muito mais parecida com a linguagem de 20 anos atrás do que você pensa.
Em dez anos você vai saber que os princípios continuam os mesmos, apenas temos ferramentas melhores, hardware mais rápido e barato.
Boa parte das melhores ferramentas de hoje, foram idealizadas e desenvolvidas pelos que já pensavam nelas a 20 ou 30 anos.
Se você duvida, é só ler os livros e manifestos dos anos 70 e 80.
P+
05/11/2009
Leia também:
- Não é Máquina Atolada. A Performance É Que Foi Prô Brejo...
- Adicionar Hardware Não Compensa Software Lento
- Performance: Quando A Culpa Não é do Banco de Dados
.'.
