51. right software > software right
+/-
software certo > fazer software certo
52. vale a pena refatorar?
• bloqueia outra estória?
• compromete a entrega?
• gera danos ao negócio?
53. não sofra por
antecipação
• “isso aqui vai impactar na estória 125 da
próxima iteração”
• programe baseado em fatos, não em
especulação
• software é incerto por natureza
54. código legado é código que
funciona
http://favim.com/image/467371/
75. flappy tests
• refatorar
• reduzir o grau de integração
• somente ui? teste unitário em javascript
• ui burra? teste em nível de integração
76. flappy tests
• refatorar
• reduzir o grau de integração
• somente ui? teste unitário em javascript
• ui burra? teste em nível de integração
• nenhum dos anteriores? VALA!
- 113 arquivos (aprox. 5 consultas cada -> 565)\n+ Falta de cobertura de testes;\n+ Excesso de complexidade acidental;\n+ Duplicação de código;\n+ Excesso de responsabilidade em um objeto\n+ - cita o isStringEmpty("") == false\n
- o sistema é gigante.\n- ultra complexo\n- reescrever significa fazer engenharia reversa\n- caso do netscape\n
\n
- seguir a ideia do seu barriga\n - cobrar a dívida (no matter what)\n - atitude extrema\n
- refactoring como se não houvesse amanhã\n- pareamento o tempo todo, várias ideias e brainstorms sobre como melhorar o design\n- reclamação sobre o código o tempo todo\n
\n
- ainda estou dando uma prévia ali do futuro\n
- $5000,00 / min na black friday\n- um dia inteiro sem vender produtos no canadá\n- a tradução pra francês não ocorreu\n
- o tech lead ja trabalhava na empresa ha 8 anos\n - a iteration manager pirou, foi pra uma startup porque a pressão era menor :S\n
- o tech lead ja trabalhava na empresa ha 8 anos\n - a iteration manager pirou, foi pra uma startup porque a pressão era menor :S\n
- o tech lead ja trabalhava na empresa ha 8 anos\n - a iteration manager pirou, foi pra uma startup porque a pressão era menor :S\n
- o tech lead ja trabalhava na empresa ha 8 anos\n - a iteration manager pirou, foi pra uma startup porque a pressão era menor :S\n
- atitude do seu madruga\n- alguma frase do seu madruga\n- passou 14 meses sem pagar o aluguel\n- se dá mal as vezes, mas é feliz no geral\n- devemos perdoar as afrontas, devemos perdoar as ofensas, devemos perdoar as afrontas.. devemos perdoar os aluguéis atrasados\n
- chega de choradeira\n- chega de reclamação\n- é a hora de aceitar a situação\n
- código não é seu\n- se quiser escrever código bonito, faça open source\n- foi a parte mais difícil pra mim. (é triste ver seus colegas fazendo coisas legais, e você ali fazendo aquilo)\n
- nem sempre o código perfeito é o melhor código.\n- e daí se existe uma diferença semântica entre PUT e POST.\n- a briga sobre uso de forms x ajax pra fazer um DELETE\n- e daí se a classe é gigante\n
- não adianta escrever o código perfeito que ninguém usa\n- feedback dos usuários é importante\n- muito capricho as vezes é perda de tempo\n- good enough!\n
- refatorar gerava satisfação para o time, mas não para o negócio\n - esforço x dano\n
- a gente refatorava tudo, sem critério\n- aprendemos a selecionar os maiores pain points\n- so refatorar o que for necessário\n
- a gente olhava os commit logs pra comparar\n
- avlaliar tech debt conscientemente\n- catalog update remote... refatorar nao traria business value\nadicional, somente satisfação do time de dev.\n
- não vale a pena sofrer antes da hora.\n- não adianta querer otimizar pra algo que vc não tem certeza se vai acontecer\n
- o stalone é o único cara que com 60 anos derruba um helicóptero usando uma moto\n- assistam e vejam a piada do chuck norris\n- esqueçam os caras da esquerda.. os legados são os velhos aqui do lado direito\n
- quando for escrever funcionalidades novas, tente fazer em forma de protótipo.\n- trabalhar no código legado é mais difícil. Então tente validar a feature longe do tech debt. Depois tente enfiar o código lá no meio.\n
\n
- lembra da licença poética da literatura? (tire um momento em que tudo é liberado).\n- não é você que está escrevendo o código de cowboy..\n- não fui eu. foi meu eu-lírico\n- não tem problema tomar um atalho\n- cowboy consciente\n
- não é pq todo o código relacionado a produtos está numa classe que você precisa continuar aumento o que acontece por lá.\n- tente criar uma classe paralela e resolver o problema por lá.\n- empacota tudo numa façade e toca o pau\n
- não precisa ter medo, vá navegando no código.\n- nem sempre você precisa entender tudo por ali.\n- utilize suas ferramentas pra ajudar (intellij e eclipse têm comandos pra avançar e voltar no código)\n\n- ao mesmo tempo não seja imprudente.\n- evite mudanças desncessários (refatorar por refatorar)\n
- nós fomos mordidos por refactorings antigos.\n- terça feira eu corrigi um bug criado em fevereiro, por causa de um refactoring desnecessário.\n- todo mundo odiou a category tree (testes super flappy rodando por 1 ano)\n
seja corajoso e mude o código\nmas não seja imprudente ao ponto de especular refactorings\n\n- não refatore mais de 2 classes por vez\n
- ouviu algum guru falando que debugging é pra quem não sabe programar? (bullshit!)\n- conheça bem uma ou mais IDEs, elas vão fazer sua vida muito mais simples (visual studio com resharper)\n- os refactorings automatizados simplificam a vida e dão segurança.\n
\n
\n
\n
- extraia unidades de forma segura e rápida\n- o compilador e a ide são grandes amigos seus nessas horas\n- muitos outros (depende da IDE)\n
- esse método é chamado em vários lugares. uma mudança pode quebrar N features.\n- vale mesmo a pena mexer nele?\n- sempre use o show call hierarchy quando começar a modificar uma classe.\n- alternativa em ruby/python? o bom e velho grep (mas não vai te dar os níveis mais baixos)\n(se tiver metaprogramação ferrou tudo)\n
- de um blame e descubra quem é o pai da criança\n- deixe pra xingar depois, o dono da caca pode ser voce.\n- sempre faça um diff antes de commitar\n- use o log pra entender o que as outras pessoas pensaram quando escreveram aquele código\n\n- grep e awk podem te ajudar a achar o conteúdo que você procura\n- find pra navegar nos arquivos\n- cut pra extrair partes específicas do conteúdo\n- xargs pra passar argumentos de forma mais inteligente\n
- tdd é ferramenta de design, não de teste.\n- (levantar a polemica) qual é o ponto de fazer tdd pra design pronto?\n
\n
- nós começamos a matar os testes funcionais\n- geralmente se começa com testes funcionais, mas nós fizemos o contrário\n
- o que é um flappy tests? (não determinístico. pode falhar em um dos n pontos)\n
- o que é um flappy tests? (não determinístico. pode falhar em um dos n pontos)\n
- o que é um flappy tests? (não determinístico. pode falhar em um dos n pontos)\n
- o que é um flappy tests? (não determinístico. pode falhar em um dos n pontos)\n
- o que é um flappy tests? (não determinístico. pode falhar em um dos n pontos)\n
contudo, os testes ainda são lentos e instáveis\n
- teoria dos sistemas (self organization)\n- integração via http/rest..\n
- reclamar de um dev vai fazer com que ele seja melhor?\n- a velocidade de produção de lixo é muito superior a velocidade de limpeza\n- enxugar gelo\n
- reclamar só vai gerar desgaste\n
\n
- os retangulos amarelos sao os buffers\n- separação por slices\n
\n
\n
- nao sei. (sim, mas não)\n- não podemos afirmar que sim, nem que não. Mas uma coisa é certa: se mantivéssemos o mesmo ritmo, o burnup seria uma réplica das primeiras semanas. __/ ___/ __/\n- a mudança de atitude garantiu um ritmo sustentável que considera tech x biz\n