1. Aprimore suas habilidades.
Por que passar a vida desenvolvendo software se você não se preocupa em fazê-lo direito?
2. Reflita sobre o seu trabalho
Desligue o piloto automático e assuma o controle. Constantemente critique e valide seu trabalho.
3. Forneça opções. Não dê desculpas esfarrapadas
Ao invés de desculpas, forneça opções. Não diga que não pode ser feito; explique o que pode ser feito.
4. Não conviva com janelas quebradas
Corrija designes pobres, decisões erradas e código ruim quando se deparar com eles.
5. Seja um catalisador de mudanças
Você não pode forçar as pessoas a mudarem. No entanto, você pode lhes mostrar como o futuro pode ser e convencê-las a participar da sua criação.
6. Olhe o quadro geral
Não mergulhe nos detalhes para não esquecer de olhar o que está acontecendo ao seu redor.
7. Faça da qualidade um requerimento obrigatório
Envolva seus usuários para conseguir capturar os requerimentos que impõem qualidades reais para o projeto.
8. Invista regularmente no seu portfolio de conhecimentos
Torne a aprendizagem um hábito.
9. Analise de forma crítica o que você lê e ouve
Não se abale com o que dizem os vendedores, a mídia especializada ou com dogmas. Analise a informação de acordo com a sua realidade e a do seu projeto.
10. O que você diz e como você diz
Nada adianta ter grande idéias se você não consegue comunicá-las de maneira eficiente.
11. DRY – Don’t Repeat Yourself (Não se repita)
Cada pedaço do conhecimento deve ter uma representação única, sem ambigüidades e de representativa autoridade no sistema.
12. Torne fácil de reutilizar
Se for fácil de reutilizar, as pessoas reutilizarão. Crie um ambiente que favoreça a reutilização.
13. Elimine o efeito de coisas não relacionadas
Projete componentes que sejam auto-contidos, independentes e com um único propósito bem definido.
14. Não existem decisões finais
Nenhuma decisão é gravada em pedra. Pense em cada decisão como sendo gravada na areia da praia e prepare-se para as mudanças.
15. Utilize o rastro das balas para encontrar o alvo
O rastro que as balas deixam leva você para em direção ao alvo na medida em que você experimenta novas coisas e vê quão próximo conseguiu chegar do objetivo.
16. Faça protótipos para aprender
Prototipação é uma experiência de aprendizagem. O seu valor não está no código produzido, mas sim nas lições aprendidas.
17. Programe próximo do domínio do problema
Planeje e codifique utilizando o vocabulário do usuário.
18. Estime para evitar surpresas
Estime antes de começar. Você descobrirá quais são os problemas em potencial para o futuro.
19. Interaja o cronograma com o código
Use a experiência você adquire a medida que implementa para refinar suas estimativas de prazo.
20. Mantenha o conhecimento com comentários claros
Comentários claros nunca ficam obsoletos. Eles ajudam a alavancar seu trabalho e simplificam o debug e testes.
21. Use o poder da linha de comando
Use a linha de comando quando a interface gráfica não suprir suas necessidades.
22. Use um único editor. E use-o bem
O editor deve ser uma extensão da sua mão. Certifique-se de que o seu editor é configurável, extensível e adaptável as suas necessidades.
23. Sempre use controle de versão
O controle de versão é a máquina do tempo do seu trabalho – Com ele você pode sempre voltar atrás.
24. Corrija o problema, não a acusação
Não importa se o bug é uma falha de outra pessoa – ele ainda assim é um problema e portanto precisa ser consertado.
25. Não entre em pânico quando estiver debugando
Respire fundo e PENSE sobre o que pode estar causando o bug.
26. "select" não está quebrado
É raro você encontrar um bug no sistema operacional, no compilador, ou mesmo em programas e bibliotecas comerciais. Na maioria das vezes o problema está mesmo na sua aplicação.
27. Não presuma. Prove
Prove suas suposições no ambiente atual, com dados reais e para as condições de fronteira.
28. Aprenda uma linguagem de manipulação de textos
Você gasta grande parte do seu dia trabalhando com textos. Por que não deixar que o computador faça algo mais por você?
29. Escreva código que escreva código
Geradores de código aumentam sua produtividade e ajudam a evitar duplicidade.
30. Você não pode escrever um software perfeito
Software não pode ser perfeito. Mas proteja o seu código e seus usuários dos erros inevitáveis.
31. Projete para contratos (Design by Contracts)
Utilize contratos para documentar e verificar que o código não faz nem mais nem menos do que aquilo que necessita fazer.
32. Falhe cedo
Um programa morto costuma causar menos estrago do que um programa aleijado.
33. Use asserções para prevenir o impossível
Asserções validam suas suposições. Utilize-as para proteger seu código do mundo incerto.
34. Use exceções para problemas excepcionais
Exceções podem sofrer dos mesmos problemas de manutenção e legibilidade dos clássicos códigos em espaguete. Reserve as exceções para coisas realmente excepcionais.
35. Acabe o que você começou
Sempre que possível os métodos e objetos que alocam recursos devem ser responsáveis por desalocá-los.
36. Minimize o acoplamento entre módulos
Evite o acoplamento escrevendo código “tímido” e aplicando a lei de Demeter.
37. Configure ao invés de integrar
Implemente as escolhas tecnológicas de uma aplicação como opções de configuração, não como partes integradas da aplicação.
38. Coloque a abstração no código e os detalhes em metadados
Programe para o caso geral e coloque as especificidades fora da base do código compilado.
39. Analise o processo para melhorar a concorrência
Explore a concorrência dos processos dos seus usuários.
40. Projete utilizando serviços
Projete em termos de serviços independentes, com interfaces consistentes e para objetos concorrentes e bem definidos.
41. Sempre projete para concorrência
Permita a concorrência e você irá projetar interfaces limpas e com poucas suposições.
42. Separe visões de modelos
Ganhe flexibilidade a um baixo custo projetando suas aplicações em termos de modelos e visões.
43. Use quadro-negro para coordenar processos
Use quadros-negro para coordenar agentes ou fatos discrepantes enquanto mantém a isolação e independência entre os participantes.
44. Não programe por coincidência
Mantenha-se nas coisas confiáveis. Cuidado com complexidade acidental e não confunda uma feliz coincidência com uma regra geral.
45. Estime a ordem dos seus algoritmos
Faça uma estimativa do que algoritmo precisa suportar antes de escrever código.
46. Teste suas estimativas
Análises matemáticas de algoritmos não lhe dizem tudo. Tente medir o desempenho do seu código no ambiente real.
47. Refatore cedo, refatore sempre
Assim como você remove as ervas daninhas e rearranja o jardim, reescreva e reestruture o código constantemente. Corrija na raiz do problema.
48. Projete para os testes
Comece a pensar como testar antes de escrever uma linha de código.
49. Teste o seu software; ou o seu usuário testará por você
Teste arduamente. Não faça o seu usuário encontrar os erros que você deveria ter encontrado.
50. Não utilize assistentes de código que você não entenda
Assistentes podem gerar toneladas de código. Esteja certo de que você entenda tudo o que foi gerado antes de incorporá-lo ao seu projeto.
51. Não colha os requerimentos – Procure por eles profundamente
Requerimentos raramente estão na superfície. Normalmente eles estão soterrados sob várias camadas de suposições, preconceitos e politicagem.
52. Trabalhe com o usuário para pensar como o usuário
Esta é a melhor maneira conseguir inspiração sobre como o sistema será utilizado.
53. Abstrações vivem mais do que detalhes
Invista na abstração, não na implementação. Abstrações podem sobreviver às barreiras criadas pelas mudanças de implementação e pelas novas tecnologias.
54. Use um glossário de projeto
Crie e mantenha uma fonte única com todos os termos e vocabulários específicos do projeto.
55. Não pense fora caixa – Encontre a caixa
Quando confrontado com um problema impossível, identifique as verdadeiras limitações. Pergunte a você mesmo: “Isso precisa ser feito dessa maneira? Isso precisa ser feito por completo?”.
56. Comece quando você estiver pronto
Você adquire experiência durante toda a sua vida. Não deixe passar desapercebido as pequenas dúvidas.
57. Algumas coisas são melhores feitas do que descritas
Não caia na espiral da especificação – em algum momento você precisa começar a codificar.
58. Não seja um escravo dos métodos formais
Não adote uma técnica sem antes analisá-la no contexto de suas práticas de desenvolvimento e capacidade.
59. Ferramentas caras não produzem projetos melhores
Não se impressione somente pelo preço estampado na etiqueta. Julgue as ferramentas pelos seus méritos.
60. Organize o time pela funcionalidade
Não separe os designers dos programadores nem os testadores dos modeladores. Forme os times da mesma maneira que você organiza o código.
61. Não use manual de procedimentos
Um script ou arquivo de lote pode executar as mesmas instruções, na mesma ordem, o tempo todo.
62. Teste cedo. Teste sempre. Teste automaticamente
Testes que rodam a cada build são muito mais eficientes do que planos de testes empoeirados em uma prateleira.
63. O código não está terminado até todos os testes rodarem
E ponto final.
64. Use sabotadores para testar seus testes
Coloque bugs propositalmente em uma cópia separada do código para verificar se os testes irão apontá-los.
65. Teste a cobertura de estados, não a cobertura de código
Identifique e teste estados significativos do programa. Testar apenas linhas de código não é o suficiente.
66. Encontre um bug uma única vez
Quando um testador humano encontrar um bug deve ser a última vez que um humano encontre esse bug. Utilize testes automáticos para verificar esse bug a partir de então.
67. O português também é uma linguagem de programação
Escreva documentos da mesma forma que você escreve código: obedeça ao principio do DRY (não se repita), utilize metadados, MVC, geradores automáticos, etc.
68. Crie documentação durante, ao invés de tentar encaixá-la depois
Documentação criada separada do código muito mais chance de estar incorreta e desatualizada.
69. Supere um pouco as expectativas dos seus usuários
Compreenda quais são as expectativas do seu usuário e então entregue um pouquinho mais do que ele estava esperando.
70. Assine o seu trabalho
Mesmo os primeiros artesões ficavam orgulhosos de assinar seus trabalhos. Você também deveria ficar.
Estas dicas foram extraidas do livro The Pragmatic Programmer