Your SlideShare is downloading. ×
Praticando o Desapego: quando ignorar a dívida técnica
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Praticando o Desapego: quando ignorar a dívida técnica

1,310
views

Published on

Apresentação para o agile brazil 2012.

Apresentação para o agile brazil 2012.

Published in: Technology

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,310
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
31
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • - 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
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • - find . -name '*.java' | grep -v 'generated' | xargs wc -l | sort\n
  • - find . -name '*Test.java' | grep -v 'generated' | xargs wc -l | sort\n
  • \n
  • \n
  • \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
  • \n
  • Transcript

    • 1. praticando o desapego quando ignorar a dívida técnica
    • 2. sumárioquem somos nós?a histórialiçõesresultados
    • 3. quem somos nós? Netto @nettofarah github.com/nettofarah ThoughtWorks BR/SF Vini @vvgomes github.com/vvgomes ThoughtWorks BR/NYC
    • 4. nossa missão
    • 5. objetivogerenciar o catálogo de produtos e categorias de um dos maiores ecoms do mundo
    • 6. find . -type f ( -name *.css -o -name *.js -o -name *.java -o -name *.jsp -o -name *.html )-print0 | xargs -0 cat | wc -l
    • 7. find . -type f ( -name *.css -o -name *.js -o -name *.java -o -name *.jsp -o -name *.html )-print0 | xargs -0 cat | wc -l 558982 linhas de código
    • 8. grep -R ‘<bean’ . | wc -l
    • 9. grep -R ‘<bean’ . | wc -l 684 spring beans
    • 10. grep -R ‘class’ . | wc -l
    • 11. grep -R ‘class’ . | wc -l 3096 classes java
    • 12. grep -R ‘@Test’ . | wc -l
    • 13. grep -R ‘@Test’ . | wc -l 1774 testes com junit4
    • 14. grep -R ‘public void test’ . | wc -l
    • 15. grep -R ‘public void test’ . | wc -l 1603 testes com junit3
    • 16. tecnologias
    • 17. pontos de integração40 queues 157 fields 20 schemas 8 cores ~ 30 offline jobs 5 webservices
    • 18. 104 pontos de integração!
    • 19. testes
    • 20. testes• 2777 junit tests
    • 21. testes• 2777 junit tests• 360 functional tests
    • 22. testes• 2777 junit tests• 360 functional tests• ruby 1.8.6 (sem bundler!)
    • 23. testes• 2777 junit tests• 360 functional tests• ruby 1.8.6 (sem bundler!)• windows xp
    • 24. testes• 2777 junit tests• 360 functional tests• ruby 1.8.6 (sem bundler!)• windows xp• monkeypatches para IE/windows
    • 25. testes• 2777 junit tests• 360 functional tests• ruby 1.8.6 (sem bundler!)• windows xp• monkeypatches para IE/windows• build de 7 horas
    • 26. times4 times (aprox. 35 devs)8 engineers6 managers
    • 27. primeira estóriaimportar produtos de um feed
    • 28. IHateYouForeverImpl• 2272 linhas• 32 dependências• getItemStatus (3 setters)
    • 29. IHateYouServiceImplTest 78 linhas de test setup
    • 30. loadAllProducts.xml 26 folhas impressas
    • 31. ProductDTO.java• 86 atributos• + getters / + setters• equals() => 400 linhas
    • 32. Vamos jogar tudo fora e começar do zero!
    • 33. Tá bom!Vamos refatorar tudo!
    • 34. pague o aluguel!
    • 35. vamos arrumar a casa• refatoração intensiva• pair programming• reclamação
    • 36. 6 semanas mais tarde
    • 37. mais de perto
    • 38. ferrou!• um refactoring inocente (especulativo)• bugs em produção (custou dinheiro)
    • 39. todos ‘chora’
    • 40. todos ‘chora’• desconfiança do time onshore
    • 41. todos ‘chora’• desconfiança do time onshore• quase cancelamento do projeto
    • 42. todos ‘chora’• desconfiança do time onshore• quase cancelamento do projeto• iteration manager se demitiu
    • 43. todos ‘chora’• desconfiança do time onshore• quase cancelamento do projeto• iteration manager se demitiu• tech lead se demitiu (foi pra europa)
    • 44. nova abordagem
    • 45. faça as pazes consigo mesmo http://fc06.deviantart.net/fs71/f/2011/027/a/3/rainbow_farting_unicorn_by_hi_my_name_is_light-d3875xd.jpg
    • 46. desapegue-se http://pottermaniaca1.tumblr.com/post/3687853880
    • 47. purismo tem limite
    • 48. right software > software right +/-software certo > fazer software certo
    • 49. vale a pena refatorar?• bloqueia outra estória?• compromete a entrega?• gera danos ao negócio?
    • 50. 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
    • 51. código legado é código que funciona http://favim.com/image/467371/
    • 52. protótiposmvp em nível de funcionalidade
    • 53. licença poéticanão fui eu. foi meu eu-lírico. http://weheartit.com/entry/36480124/via/ilaria_tatti
    • 54. jogue a sujeira pra baixo do tapetehierarquias e classes paralelasempacote em façades
    • 55. coragem x imprudência http://tobemtogordo.files.wordpress.com/2011/06/coragem-esse-c3a9-o-significado.jpg
    • 56. reduza o ciclo de feedback tem gente usando?
    • 57. refatoração é viciante
    • 58. conheça suas ferramentas
    • 59. debuggers
    • 60. IDEs
    • 61. refactorings
    • 62. refactorings• extract [class, method, variable]• rename [class, method, variable]• move [class, method, variable]
    • 63. quem é mesmo que chama aquele método? vai encarar?
    • 64. controle de versão• git / svn [blame, diff, log]• grep / awk / find / cut / xargs / sort
    • 65. testes e tdd
    • 66. design evolutivo?
    • 67. black box vs white box redução dos testes funcionais
    • 68. flappy tests
    • 69. flappy tests• refatorar
    • 70. flappy tests• refatorar• reduzir o grau de integração
    • 71. flappy tests• refatorar• reduzir o grau de integração• somente ui? teste unitário em javascript
    • 72. 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
    • 73. 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!
    • 74. divide and conquer
    • 75. divide and conquerfuncionalidades grandes como pequenos serviços
    • 76. fábricas de dívida técnica
    • 77. como vender a refatoração?• não dá pra medir com precisão• reclamar não ajuda
    • 78. conclusões
    • 79. produção 2 meses antes do planejado
    • 80. será que este sucesso é consequencia do esforço inicial?
    • 81. simmas não
    • 82. perguntas

    ×