Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Código simples - Navalha de Occam para desenvolvedores Ruby

Código simples - Navalha de Occam para desenvolvedores Ruby

Essa palestra é quase igual à anterior de mesmo nome, mas insere algumas ferramentas de Ruby.

Eustáquio Rangel

July 21, 2018
Tweet

More Decks by Eustáquio Rangel

Other Decks in Programming

Transcript

  1. Código simples Navalha de Occam para desenvolvedores Ruby

  2. Eustáquio Rangel @taq [email protected]

  3. Navalha de Occam Formulada pelo filósofo medieval Guilherme de Occam

    (por vezes grafado Ockham), a lex parsimoniae (lei da parcimônia) é um princípio, solucionador de problemas, filosófico reducionista, que permite distinguir entre teorias equivalentes e pode ser utilizado como técnica para formulação de modelos teóricos. Em resumo, entre duas teorias com resultados iguais, que explicam ou preveem os mesmos fenômenos, devemos escolher a mais simples.
  4. "Pluralitas non est ponenda sine neccesitate" "Pluralidade não deve ser

    colocada sem necessidade"
  5. None
  6. None
  7. Complexidade ciclomática Complexidade ciclomática (ou complexidade condicional) é uma métrica

    de software usada para indicar a complexidade de um programa de computador. Desenvolvida por Thomas J. McCabe em 1976, ela mede a quantidade de caminhos de execução independentes a partir de um código fonte. Essa complexidade é computada através do grafo de fluxo de controle do programa: os nós do grafo correspondem a grupos indivisíveis de comandos, e uma aresta direcionada conecta dois nós se o segundo comando pode ser executado imediatamente após o primeiro. A complexidade ciclomática também pode ser aplicada a funções, módulos, métodos ou classes individuais de um programa. Uma estratégia de teste de software formulada por McCabe é testar cada caminho independente de um programa, de forma que a quantidade de casos de teste será a complexidade ciclomática do programa. https://pt.wikipedia.org/wiki/Complexidade_ciclom%C3%A1tica
  8. def hello_world puts "Hello world" end http://blog.8thcolor.com/en/2013/06/did-you-say-complexity-eh/ def hello(name) if

    name puts "Hello #{name}" end end
  9. def hello(name) return unless name puts "Hello #{name}" end https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html

  10. None
  11. Confessions of a Ruby Sadist The time has come to

    show your code who’s boss. http://ruby.sadi.st/Ruby_Sadist.html
  12. Flog Flog shows you the most torturous code you wrote.

    The more painful the code, the higher the score. The higher the score, the harder it is to test. Run it against your best stuff. I double-dog dare you. http://ruby.sadi.st/Flog.html
  13. Default 57.0: flog total 7.1: flog/method average 18.3: PeopleController#create app/controllers/people_controller.rb:26-35

    17.4: PeopleController#update app/controllers/people_controller.rb:42-49 Responders 26.9: flog total 3.4: flog/method average 5.8: PeopleController#create app/controllers/people_controller.rb:19-22 4.5: PeopleController#update app/controllers/people_controller.rb:25-27 3.7: PeopleController#set_person app/controllers/people_controller.rb:37-38 3.6: PeopleController#person_params app/controllers/people_controller.rb:42-43
  14. Flay Flay analyzes ruby code for structural similarities. Differences in

    literal values, names, whitespace, and programming style are all ignored. Code that flay reports as similar is a good candidate for refactoring. http://ruby.sadi.st/Flay.html
  15. Default Total score (lower is better) = 70 1) Similar

    code found in :block (mass = 38) app/controllers/people_controller.rb:31 app/controllers/people_controller.rb:45 2) Similar code found in :block (mass = 32) app/controllers/people_controller.rb:34 app/controllers/people_controller.rb:48 Responders Total score (lower is better) = 0
  16. https://www.patreon.com/zenspider/overview Ryan Davis (@zenspider) 1% das gems de Ruby são

    dele, entre elas: • minitest • sexp_processor • ruby_parser • hoe • flay • flog
  17. Tests are refactoring best friends

  18. YAGNI https://pt.wikipedia.org/wiki/YAGNI YAGNI é uma abreviação da expressão de língua

    inglesa You Ain't Gonna Need It. Em engenharia de software, é uma orientação de trabalho que sugere aos programadores que não adicionem funcionalidades ao código fonte de um programa até que estas sejam realmente necessárias. Ron Jeffries afirma que sempre se deve implementar coisas que se realmente precisa, nunca o que se prevê que um dia irá ser preciso.
  19. KISS https://pt.wikipedia.org/wiki/YAGNI Keep It Simple, Mantenha Simples em português (ou

    : KISS principle acrônimo em inglês de: Keep It Simple, Stupid, ou seja, Mantenha Simples, Estúpido) é um princípio geral que valoriza a simplicidade do projeto e defende que toda a complexidade desnecessária seja descartada. Serve como fórmula útil em diversas áreas como o desenvolvimento de software, a animação, a engenharia no geral e no planejamento estratégico e táctico. Também é aplicado na Literatura, na Música e nas Artes em geral.
  20. "Simplicidade é o último grau de sofisticação" Leonardo Da Vinci

  21. "Tudo deve ser feito da forma mais simples possível, mas

    não mais simples que isso" Albert Einstein
  22. "A perfeição é alcançada não quando não há mais nada

    para adicionar, mas quando não há mais nada que se possa retirar" Antoine de Saint-Exupéry
  23. "Quanto mais velho fico, mais percebo que o maior problema

    a ser resolvido na tecnologia é fazer as pessoas pararem de fazer as coisas mais difíceis do que têm de ser." Chad Fowler
  24. "O propósito da engenharia de software é controlar a complexidade,

    não cria-lá." Pamela Zave
  25. “Em programação, a elegância não é um luxo mas sim

    uma qualidade que decide entre o sucesso e o fracasso.” Edsger Dijkstra
  26. None
  27. None
  28. Estado de fluxo (flow) de Mihaly Csikszentmihalyi

  29. Real-World Maintainable Software https://www.oreilly.com/programming/free/real-world-maintainable-software.csp The software development industry is increasingly

    realizing that success depends on a project’s long-term viability. To help with that effort, the Software Improvement Group (SIG) has identified ten guidelines for delivering code that’s easy to maintain and adapt over time. “It introduces 10 guidelines on writing maintainable ‘real-world’ software that are actually just basic junior level stuff that's centered only on the happy path development.” “That's what I'm striving for and I think the book lacks a lot in monitoring, analytics, continuous integration, continuous deployment and etc. All ‘real’ in my opinion, maintainable software parts that were not mentioned.” https://www.goodreads.com/book/show/32192028-real-world-maintainable-software
  30. Vamos conhecer as 10 regras para “júniors” Que muitos “sêniors”

    por aí não se importam por acharem muito básicas, mesmo que não as apliquem e foquem em apagar os incêndios depois!
  31. Escreva pequenas unidades de código Unidades pequenas são mais fáceis

    de analisar, testar e reutilizar. Métrica sugerida: não mais que 15 linhas por método 1
  32. Escreva unidades simples de código Unidades com menos pontos de

    decisões são mais fáceis de analisar e testar. Quanto mais pontos de decisões/caminhos/branches, mais difícil fica entender o código. 2
  33. Escreva código apenas uma vez O famoso DRY, Don't Repeat

    Yourself. Duplicação deve ser evitada. Além de aumentar consideravelmente o trabalho, pois as alterações também tem que serem feitas nas cópias, é uma causa forte de bugs de regressão. 3
  34. Mantenha as interfaces enxutas Evite muitos parâmetros na assinatura de

    um método. Métodos com assinaturas enxutas são melhores para utilizar e testar. 4
  35. Separe os interesses em módulos Módulos e classes com baixo

    acoplamento são mais fáceis de modificar. Se você não pode explicar o que a classe faz de maneira simples, ela representa mais que um conceito, ou um muito genérico ou abstrato. 5
  36. Acoplamento fraco de componentes Parecida com a anterior, mas ao

    invés de classes e módulos, componentes Alto nível de abstração para evitar que os componentes saibam muito dos detalhes de implementação, deixando eles mais independentes. 6
  37. Mantenha o balanço dos componentes Nem pouco, nem muito. Poucos

    trazem complexidade, muitos trazem falta de controle. 7
  38. Mantenha a sua base de código pequena Que acaba sendo

    consequência das outras regras. Uma maneira de alcançar isso é evitar “future proofing”, que é adicionar à aplicação funcionalidades (que inclusive podem ser relacionadas com otimização prematura) que ainda não foram requisitadas mas que os desenvolvedores acham que vão ser necessárias no futuro. Como recomendação para sistemas Java, o SIG estabelece no máximo 175000 (vixi!) linhas de código. 8
  39. Automatize seus testes Rodar os testes de forma manual não

    funciona. Testes automatizados dão feedback imediato e aumentam a confiança em refatorar o código. 9
  40. Escreva código limpo Não é somente uma questão de estilo,

    indentação ou nomes de variáveis. É antes de mais nada, uma questão de compreensão. O código deve mostrar claramente qual sua finalidade e evitar dúvidas ou mesmo armadilhas, permitindo que qualquer um que o ler vai entender rapidamente e será capaz de o modificar sem fazer erros descuidados. 10
  41. Obrigado! :-) @taq [email protected]