SOLID on Legacy Code [pt BR]

Aplicada na Semana Acadêmica da Católica de Santa Catarina, esta palestra fala sobre o como podemos aplicar boas práticas de desenvolvimento de software em um time com softwares legados.

Transcript

1. SOLID on Legacy Aplicando SOLID no desenvolvimento de softwares legados
2. co-founder da Texo IT ex-engenheiro chefe do ContaAzul melhorando softwares legados há 5 anos sistemas distribuidos há 3 anos desenvolvimento de software há 16 anos 12 como profissional miere liniel teixeira
3. o que é legado?
4. "To me, legacy code is simply code without tests" Michael Feathers
5. as faces do legado
6. rigidêz
7. • Alterações simples tornam-se investidas de semanas • Medo de corrigir problemas não críticos • Dificuldade de estimar prazos
8. fragilidade
9. • Quebra em locais sem vínculo algum de negócio • Toda manutenção o torna pior • O time tem receio de fazer o software parar de funcionar se mexer nele
10. imobilidade
11. • O Desenvolvedor nota que poderia usar rotinas que estão em outro projeto • Ele nota que a rotina traz com ele muitas dependencias do outro projeto • Nota-se que o risco de trazer a rotina é muito alto • Reescreve-se a rotina duplicando a rotina anterior
12. viscosidade
13. é mais fácil fazer um Hack (gambiarra) do que manter o design original
14. as faces de um time legado
15. “combinamos este prazo com o cliente, faz do jeito mais rápido”
16. o contrato é mais importante que a necessidade do cliente
17. done is better than perfect ter a entrega pronta é o importante: independente da qualidade do que foi entregue
18. conhecimento não compartilhado
19. opiniões pré-formadas sobre algo que ainda não experimentou
20. medo de trocar o certo pelo duvidoso
21. escrever testes unitários é desperdício de tempo
22. re-escrita é vista como algo ruim
23. boas práticas são vistas como preciosismo
24. o mito da re-escrita do software
25. tornar mais confortável para o indivíduo
26. cada membro do grupo procurar tornar a si mesmo mais confortável
27. os mesmos problemas voltam a aparecer
29. benefícios do SOLID
30. diminuir o tempo de inclusão de novas features
31. diminuir o tempo de correção de bugs
32. diminuir o tempo para customizar as features do software
33. benefícios do SOLID … em programês
34. reuso baixo acoplamento inclusão ortonogal de comportamentos
35. mais fácil de se re-escrever mais fácil de se testar
36. tolerante à mudanças de escopo
37. ...e como aplicar?
38. não re-escreva o software “do zero”
39. não existe ninguém capaz de re-escrever um software inteiro sem conhecer TODO o escopo.
40. business technology ignorance chart / chaos chart chaos zone
41. começe “matando” bugs é o melhor modo de conhecer o software
42. categorize os bugs features, inscidência, etc
43. ajuste... ...bugs de menor inscidência
44. agrupe e re-escreva... ...blocos de bugs de uma mesma categoria ou que possuam maior inscidência
45. cubra com testes... ...qualquer alteração que foi feita no código legado
46. evidências de coincidência ou tendencia mínimo design viável
47. “enquanto a primeira ocorrência de algo é uma excessão, a segunda pode se tratar apenas de uma coincidência. mas, uma vez que ocorra três vezes ou mais, com certeza é uma tendência e deve ser tratado como tal.”
48. codifique apenas as linhas necessárias para resolver uma issue
49. quando for identificado que um código está duplicando outro trecho ( ou comportamento ), trate-o como uma coincidência e refatore para tal.
50. só faça abstrações genéricas quando uma alteração for duplicar um código já refatorado por duplicidade
51. benefits driven design
52. quando houver mais de um possível design mínimo viável para uma situação, escolha o que trouxer mais benefícios com o menor esforço benefícios: reuso, menor acoplamento, inclusão ortogonal de features, etc...
53. S O L I D com exemplos...
54. S O L I D Single Responsibility Principle
55. S O L I D Open Closed Principle
56. S O L I D Liskov Substitution Principle
57. S O L I D Interface Segregation Principle
58. S O L I D Dependency Inversion Principle
59. pensar no time como um todo quando for reescrever... ...focando apenas nas necessidades reais de seus clientes
60. dúvidas?
61. • http://java.dzone.com/articles/clean-code-four-simple-design • http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod • http://www.bullseye.com/minimum.html • http://www.liv.asn.au/Mobile/Home/Law-Institute- Journal/Article?NodeID=291271&NodeParentID=291270 • https://en.wikipedia.org/wiki/Law_of_Demeter references
62. Thanks! Twitter: @miere Skype: miere.teixeira GitHub: https://github.com/miere E-Mail: miere.teixeira@texoit.com E-Mail: miere.teixeira@gmail.com