1. O documento discute estratégias para debug e otimização de código de forma eficiente. 2. Recomenda-se usar o método científico para debug: estabilizar o erro, formular hipóteses, testar e corrigir. 3. A otimização deve ser feita após o desenvolvimento, com medições para identificar gargalos e avaliar melhorias.

1. Aumentando a produtividade:
DEBUG
Rodrigo Aguas da Silva

2. O que é debugging?
• Debug é o processo de identificação da causa
de um erro de software;
• Consome muito tempo dos desenvolvedores;
• Torna-se a parte mais chata da programação;
Mas não precisa ser assim!

3. Consumo de tempo
• Estudos mostram diferenças de até 20 para 1
no tempo gasto por programadores para
encontrar o mesmo conjunto de defeitos.
• O que ocasiona esse melhor desempenho?

4. Estratégia supersticiosa
1. Espalhe instruções de impressão aleatoriamente
pelo programa;
2. Examine a saída procurando o defeito;
3. Caso não encontre, mude algumas coisas no
programa até que pareça funcionar.
Dicas:
• Não perca tempo entendendo o problema
• Não faça backup do código original

5. FAIL!
Sintomas do uso:
• Defeitos ocultos da linguagem (quando é lua cheia)
• Editores de código possuídos
• Sumiço de commits importantes
• Defeitos misteriosos do compilador
• Localizar a causa do problema e entendê-lo
normalmente representa 90% do tempo gasto para
a correção.

6. Solução
• Você não precisa fazer um pacto com o diabo
e usar a estratégia supersticiosa.
• O método científico pode ser usado.

7. Método Científico
1. Reúna dados por meio de experimentos repetidos
2. Formule uma hipótese considerando esses dados
3. Elabore um experimento para provar ou não a
hipótese
4. Prove ou não a hipótese
5. Repita tantas vezes quanto for necessário

8. Aplicando ao Debug
1. Estabilize o erro
2. Localize a causa do erro:
1. Reúna cenários que produzem o erro
2. Formule uma hipótese sobre o defeito
3. Planeje a prova da hipótese
4. Prove ou não a hipótese
3. Corrija o defeito
4. Teste
5. Procure erros semelhantes

9. Estabilize o erro
• Se um defeito não ocorre de modo repetitivo,
é quase impossível diagnosticá-lo.
• Causas comuns de instabilidade:
– valores iniciais
– encadeamento temporal

10. Estabilize o erro
Simplificar o caso de teste ao máximo:
1. Identifique um cenário de fatores que
produzem o erro;
2. Formule uma hipótese a respeito de quais
são irrelevantes;
3. Execute o caso de teste
1. Se o erro continuar, elimine esses fatores
2. Se não, refutou a hipótese. Repita o processo;

11. Exemplo 1

12. Aplicando ao Debug
1. Estabilize o erro
2. Localize a causa do erro:
1. Reúna cenários que produzem o erro
2. Formule uma hipótese sobre o defeito
3. Planeje a prova da hipótese
4. Prove ou não a hipótese
3. Corrija o defeito
4. Teste
5. Procure erros semelhantes

13. Localize a fonte do erro
• Você também pode utilizar o método
científico nesse caso.
Dicas:
• Código de qualidade
• Testes unitários
• Uso adequado das ferramentas
• Não ignore os resultados negativos

14. Localize a fonte do erro
Dicas:
• Organize-se
• Reduza a região suspeita
• Suspeite de trechos com antecedentes
• Suspeite de alterações recentes
• Considere os problemas comuns
• Explique o problema a outra pessoa
• Afaste-se do problema

15. Limite o tempo
• Estabeleça um limite de tempo para mudar de
estratégia;
• Até para partir para uma solução mais radical,
como reescrever o código.

16. Aplicando ao Debug
1. Estabilize o erro
2. Localize a causa do erro:
1. Reúna cenários que produzem o erro
2. Formule uma hipótese sobre o defeito
3. Planeje a prova da hipótese
4. Prove ou não a hipótese
3. Corrija o defeito
4. Teste
5. Procure erros semelhantes

17. Corrigindo um defeito
• Corrigir é a parte fácil;
• Assim, torna-se propensa a erros;
• As primeiras correções estão erradas em 50%
das vezes;

18. Dicas para a correção
• Entenda o problema
• Relaxe
• Corrija o problema, não o sintoma
• Salve o código original
• Faça uma alteração por vez
• Faça alterações conscientemente

19. Dicas para a correção
• Verifique sua correção
• Crie um teste novo para o erro corrigido
• Procure defeitos semelhantes

20. Otimização de código
• Otimização de código é a prática de modificar
um código correto, tornando sua execução
mais eficiente.
• Não é a única maneira de melhorar o
desempenho do programa.

21. Por que otimizar?
• Só otimize, se houver um problema de
desempenho;
• Usuários se incomodam com desempenho
quando interfere no trabalho deles;
• Satisfação pessoal ou inflar o ego não são
motivos para otimizar código.

22. Princípio de Pareto
• O Princípio de Pareto se aplica perfeitamente
à otimização de código;
• 20% do código consomem 80% do tempo de
execução;
• Ou menos de 4% do código são responsáveis
por 50% do tempo de execução.

23. Mitos da otimização
• Quanto menos linhas de código, melhor será o
desempenho.
• Você deve otimizar à medida que escreve o
código.
• Um programa rápido é tão importante quanto
um correto.

24. Quando otimizar
1. Faça um projeto de qualidade, desenvolva o
programa, torne-o modular e modificável.
2. Quando estiver concluído e correto, verifique
o desempenho.
3. Se for pesado, otimize. Mas nunca antes de
ter certeza de que o precisa fazer.

25. Causas comuns de gargalo
• Entrada e saída
• Chamadas de sistema
• Linguagens interpretadas
• Erros

26. Medições
• Antes da otimização;
• Depois da otimização;
• Medidas devem ser precisas;
• Tenha certeza que está medindo apenas o
código a ser otimizado.

27. Atenção!
• Intuição ou experiência não avaliam
desempenho corretamente, a única base para
avaliação são as medições.
for (int coluna=0; coluna<MAX_COLUNAS; coluna++) {
for (int linha=0; linha < MAX_LINHAS; linha++) {
tabela[linha][coluna] = ......;
}
}

28. Resumo de otimização
1. Desenvolva o software com qualidade
2. Se o desempenho for insatisfatório:
1. Salve a última versão do código
2. Meça para encontrar gargalos
3. Avalie a viabilidade da otimização de código
4. Otimize o gargalo
5. Meça para avaliar a melhoria
6. Se a melhoria não aprimorar o desempenho, volta para o
código salvo
3. Repita a partir do passo 2

29. Comentários

30. Referências
• Code Complete (Steve McConnell)