[AgileBR'19] Compilar não basta. Escreva código para pessoas.

Escrever código que uma máquina entenda é fácil, qualquer pessoa que sabe um pouco de programação consegue. O desafio é escrever código que qualquer uma entenda e altere facilmente, sem introdução de defeitos. Você já leu um trecho de código e pensou "O que diabos isso está fazendo?" ou "Como vou alterar isso para atender às novas necessidades?", "E se quebrar tudo?". Como a pressão e a correria do dia-a-dia que a maioria de nós vive pode contribuir para isso? Nesta palestra, vamos apresentar uma série de dicas para que você possa não só escrever código legível, mas identificar melhorias no código, além de mostrar como práticas do eXtreme Programming são fundamentais – de ritmo sustentável à criação de código de qualidade, permitindo a todo o time de desenvolvimento mudar com confiança.

Transcript

1. Compilar não basta. Escreva código para PESSOAS
2. Edlaine Z A M O R A Camilla C R I S P I M
3. Edilaine Z A M O R A Camilla C R I S P I M
4. "Qualquer um pode escrever código que um computador é capaz de entender. Boas programadoras escrevem código que outras pessoas conseguem entender" - Martin Fowler
5. ©ThoughtWorks 2018 Commercial in Confidence 5 GASTAMOS 10x MAIS TEMPO LENDO QUE ESCREVENDO CÓDIGO
6. https://www.butterfly.com.au/blog/website-develop ment/clean-high-quality-code-a-guide-on-how-to-be come-a-better-programmer 6 PRODUTIVIDADE
7. 7 TEORIA DA JANELA QUEBRADA
8. 8 https://martinfowler.com/bliki/StranglerFigApplication.html SISTEMAS LEGADOS
9. O QUE É UM BOM CÓDIGO?
10. P O R Q U E? Click to add subtitle here. Código que funciona
11. P O R Q U E? Click to add subtitle here. Código que funciona
12. P O R Q U E? Click to add subtitle here.
13. Código que funciona
14. O QUE UM CÓDIGO ESCRITO PARA PESSOAS?
15. P O R Q U E? c Número de WTF por minuto
16. FÁCIL DE LER E FÁCIL DE MUDAR
17. FÁCIL DE LER E FÁCIL DE MUDAR simples
18. FÁCIL DE LER E FÁCIL DE MUDAR simples nomes significativos
19. FÁCIL DE LER E FÁCIL DE MUDAR simples nomes significativos apenas uma tarefa
20. FÁCIL DE LER E FÁCIL DE MUDAR simples testes automatizados nomes significativos apenas uma tarefa
21. FÁCIL DE LER E FÁCIL DE MUDAR simples testes automatizados nomes significativos escrito por alguém que se importa apenas uma tarefa
22. O ASSUNTO É RECORRENTE 22 1999 198* ©ThoughtWorks 2018 Commercial in Confidence 2004 2000 2018 2008 2001 Manifesto Ágil 2012 SIMPLES DE FALAR
23. O ASSUNTO É RECORRENTE 23 1999 198* ©ThoughtWorks 2018 Commercial in Confidence 2004 2000 2018 2008 2001 Manifesto Ágil 2012 SIMPLES DE FALAR DIFÍCIL DE FAZER
24. REQUER ABERTURA, INTENCIONALIDADE, PRÁTICA
25. POR ONDE COMEÇAR? 25 Deixe o acampamento código melhor do que como você o encontrou Evite deixar a janela quebrada o código ruim, ou vai se propagar REGRA DA ESCOTEIRA Permite fazer mudanças no código, em busca de um código melhor. Teste também é código. TESTES / TDD Evite duplicações. "Nada é melhor que qualquer coisa" (Sandi Metz) "Duplicação é melhor que abstração errada" YAGNI - Só implemente o que tem certeza que vai precisar DRY - NÃO SE REPITA ©ThoughtWorks 2018 Commercial in Confidence
26. 26 Pensou em comentar? Pense de novo. Algo pode estar errado. E pode ser o seu código "Não escreva comentários em um código ruim, reescreva-o" - Brian W. KErnighan e P.J. Plaugher ESQUEÇA COMENTÁRIOS Variáveis; Funções; Parâmetros; Classes; Pacotes Comentários, na grande maioria das vezes, são desnecessários NOMES SIGNIFICATIVOS E AINDA...
27. E AINDA... 27 A discussão não é sobre tab ou espaço É sobre consistência O software precisa de formatação consistente FORMATAÇÃO É pequena. Faz uma coisa só Sem estrutura aninhada FUNÇÕES SIMPLES
28. E AINDA... 28 Saiba diferenciar e saiba quando usar qual Estruturas de dados expõem informações e objetos expõem comportamentos que encapsulam informações ESTRUTURA DE DADOS É UMA COISA E OBJETO É OUTRA COISA
29. ESCREVER CÓDIGO PARA PESSOAS É RESPONSABILIDADE DO TIME
30. eXtreme Programming COMBINAÇÃO DE PRÁTICAS TÉCNICAS E DE GESTÃO EXTREME PROGRAMMING 5 VALORES 1- FAZ-SE SÓ O QUE É NECESSÁRIO 2- TODAS AS PESSOAS SÃO PARTE DO TIME 3- SOFTWARE FUNCIONANDO AO FINAL DE CADA ITERAÇÃO PARA FEEDBACK 4- TODOS SÃO PARTE DO TIME E SE RESPEITAM 5 - PLANEJAMENTO PARA SUCESSO E CORAGEM DE DIZER A VERDADE 14 PRINCÍPIOS VALOR DE NEGÓCIO É FUNDAMENTAL GRANDE ÊNFASE EM QUALIDADE RESPEITO AS PESSOAS, E SUA QUALIDADE DE VIDA MELHORIA CONTÍNUA 24 PRÁTICAS CONCRETAS INTEGRAÇÃO CONTÍNUA REFACTORING TDD TIME SENTA JUNTO AMBIENTE INFORMATIVO CONTINUIDADE DO TIME ÚNICO CODEBASE Análise e Planejamento Questões humanas e de time Design Coding e Entrega
31. Duas visões sobre o mesmo problema, solução e código é melhor que uma Enquanto uma escreve, a outra já está revisando PROGRAMAÇÃO EM PAR ©ThoughtWorks 2018 Commercial in Confidence RITMO SUSTENTÁVEL Maximiza comunicação Todos os papéis e skills necessários. Melhor ritmo de trabalho TIME COMPLETO E SENTANDO JUNTO ALGUMAS PRÁTICAS Evitar horas extras. Descanso, melhores soluções Não comprometer a qualidade. Algumas coisas não são negociáveis.
32. Teste automatizado não é TDD Testar antes de desenvolver Pequenos passos – todos os cenários. Melhor entendimento do negócio Aumenta a qualidade Melhora design TDD ©ThoughtWorks 2018 Commercial in Confidence DESIGN INCREMENTAL Só uma versão oficial do código. Branches devem ser de curta duração. Todas trabalham no mesmo repositório. Alinhamento de padronização CODEBASE ÚNICO E COMPARTILHADO ALGUMAS PRÁTICAS Design para ter código fácil de evoluir. Mas sem design upfront (YAGNI) Vai codando, vai fazendo design, pensando no que refatorar Sem teste. Sem refactoring.
33. 33 ©ThoughtWorks 2018 Commercial in Confidence Escreva código para o seu eu do futuro #1 Requer prática e tempo. Tenha artifícios (como do XP) que possam ajudar #2 Não vá sozinha. Envolva outras pessoas nessa jornada! #3
34. Camilla Crispim ccrispim@thoughtworks.com cmllacrspm Edlaine Zamora ezamora@thoughtworks.com edlainezamora OBRIGADA!