O documento discute o dilema entre focar na qualidade do código versus entregar novas funcionalidades rapidamente. Ele argumenta que é melhor não diminuir a qualidade para atender prazos, e sim buscar qualidade para maior produtividade no longo prazo. Técnicas como pair programming, TDD, refactoring, testes automatizados e código limpo ajudam a manter boa qualidade.

1. O Dilema
Focar na qualidade ou na entrega
imediata de novas funcionalidades?

2. Como e até quanto ponderar qualidade de um
projeto mediante ao pedido imediatista de
urgência de seu P.O..

3. Quem consegue distinguir código bom
de código ruim ?

4. Exemplo 01
Public void FazQualquerCoisa(bol condicao) {
if (condicao==true)
{
A();
B();
C();
}
}

5. Exemplo 02
Public void FazQualquerCoisa(bol condicao) {
// Precisa inicializar a variavel
bol retorno = false
if(condicao == true) {
retorno = true;
} elseif( condicao == false) {
retorno = false;
}
// METRO DE SP
return retorno;
}

6. Refactoring de código = baby
steps

7. Métodos pequenos induzem o
desenvolvedor pensar 2 vezes antes de
inserir mais linhas!

8. Código ruim se espalha igual a vírus!

9. Qual a qualidade dos nossos códigos?

10. 0% = Código escrito por mil macacos

11. 100% = Código impecável

12. Qual grau de qualidade que aumenta
nossa produtividade ?

13. Considere uma equipe de Fórmula 1 ...
Você acha que a equipe deve abrir
mão da qualidade para conseguir
maior agilidade ?

14. Quais fatores que as equipes aceitam
trabalhar abaixo da qualidade?
Experiência no negócio
Treinamento + tempo para treinamento
Testes
Falta de capacidade de avaliação de código ruim
Código legado
Não acha importante simplificar
Tentativa de generalização (Overdesign)

15. “Quem não utiliza testes automatizados é
charlatão!” – Klaus

16. JAMAIS diminua a qualidade para
alcançar o prazo !
SEMPRE busque a qualidade para ter o
seu máximo de produtividade!

17. Muita da sujeira em código esta ligada
a dificuldade em se ver, diariamente
e de forma simples, o código e sua
dependências!
Uma falha é mais fácil de ver quando
tudo está mais simples!

18. Refactoring = educação da equipe

19. O que fazer então ?
– Pair programming
– TDD
– Simplificar código
– Discutir questões porem ter uma opinião forte
– Métodos para documentar
– Métodos curtos
– Testes automatizados
– Refactoring
– Coding style deve ser sempre revisto e discutido
– Errar rápido para aprender(Dojos)

20. Ditado do GO, ”perca suas primeiras
cem partidas a mais rápido possível”.