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

1,802 views

Published on

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,802
On SlideShare
0
From Embeds
0
Number of Embeds
34
Actions
Shares
0
Downloads
34
Comments
0
Likes
5
Embeds 0
No embeds

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
  • Praticando o Desapego: quando ignorar a dívida técnica

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

    ×