Desenvolvimento
- Comece pequeno e depois expanda: ao criar um novo sistema ou adicionar funcionalidades a um sistema existente, comece com uma versão muito simples, com quase nenhum recurso necessário, e expanda gradualmente
- Mude uma coisa de cada vez: quando testes falham ou uma funcionalidade não funciona durante o desenvolvimento, fica muito mais fácil encontrar o problema se você fez apenas uma mudança por vez
- Adicione logging e tratamento de erros cedo: ao desenvolver um novo sistema, é útil adicionar logging e tratamento de erros desde o início
- Cada nova linha de código deve ser executada pelo menos uma vez: é preciso testar antes que a funcionalidade esteja concluída
- Teste as partes antes de testar o todo: partes bem testadas economizam tempo
- Tudo leva mais tempo do que parece: especialmente em programação, sempre leva mais tempo do que o esperado
- Entenda primeiro o código existente: antes de adicionar uma nova funcionalidade, é preciso entender a solução atual. Ler código é uma habilidade tão necessária quanto escrever código
- Leia e execute: há duas formas complementares de entender código: lendo-o e executando-o
Resolução de problemas
- Bugs sempre existem: a abordagem de “fazer certo da primeira vez” não é uma boa ideia
- Resolva relatos de problemas: desenvolvedores devem dedicar tempo para lidar com relatos de problemas dos clientes e corrigir bugs. Isso ajuda a entender muito melhor o que os clientes estão tentando fazer, como o sistema é usado, quão fácil ou difícil é resolver problemas e quão bem o sistema foi projetado
- Reproduza o problema: o primeiro passo para corrigir um bug é reproduzir o problema. Depois, quando a correção for adicionada, verifique se o problema desapareceu
- Depois de corrigir os erros conhecidos, veja o que restou: quando há vários problemas, corrija todos os problemas conhecidos e então observe os sintomas restantes
- Não presuma coincidência: ao testar e solucionar problemas, não acredite em coincidências; investigue. “Você mudou o valor de um timer e agora o sistema reinicia com mais frequência? Não é coincidência. Um novo recurso foi adicionado e uma funcionalidade não relacionada ficou mais lenta? Não é coincidência. Investigue mais.”
- Correlacione com timestamps: ao solucionar problemas, use os timestamps dos eventos
Colaboração
- Presencial tem a maior largura de banda: ao discutir como resolver um problema, conversar presencialmente é melhor do que qualquer outro método (vídeo, telefone, chat, e-mail)
- Rubber duck debugging: quando você trava em um problema, explicá-lo a um colega pode fazer você perceber a solução. Mesmo que o colega não diga nada, muitas vezes, ao conversar, você percebe qual é o problema. Parece mágica, mas funciona com uma frequência surpreendente
- Pergunte: ao tentar entender um código, muitas vezes ler e executar é o melhor caminho. Mas, se for possível perguntar a alguém que conhece aquilo bem (provavelmente o autor original), use isso também
- Compartilhe o crédito: dê crédito a quem merece. Em vez de dizer “nós tentamos...”, diga “Marcus teve a ideia do que tentar” (se foi isso mesmo que aconteceu). Mencione ativamente quem ajudou ou contribuiu
Outros
- Experimente: quando você não tiver certeza de como um recurso da linguagem funciona, escreva um pequeno programa para testar
- Durma: ao enfrentar um problema difícil, pode ser uma boa ideia dormir uma noite antes de decidir
- Mudança: não tenha medo de mudar de função ou de emprego de vez em quando. Trabalhar com outras pessoas, em outros produtos ou em outras empresas é estimulante
- Continue aprendendo: uma das maiores vantagens do desenvolvimento de software é que sempre há espaço para aprender e descobrir mais. Experimente diferentes linguagens de programação e ferramentas, leia livros sobre desenvolvimento de software e faça cursos MOOC. Pequenas melhorias se acumulam e trazem uma mudança real no seu conhecimento e na sua capacidade
7 comentários
Presencial tem a maior largura de banda — ótima forma de expressar isso.
+1.
Depuração com pato de borracha. Até falar com alguém que realmente não entende programação faz você perceber qual é o problema.
+1.
É um verdadeiro guia.
+1
Uau, tudo isso faz muito sentido. É uma pena que a comunicação presencial tenha a maior largura de banda. Espero que a tecnologia avance mais.