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

    View full-size slide

  2. 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.

    View full-size slide

  3. "Pluralitas non est ponenda sine neccesitate"
    "Pluralidade não deve ser colocada sem
    necessidade"

    View full-size slide

  4. 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

    View full-size slide

  5. 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

    View full-size slide

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

    View full-size slide

  7. Confessions of a Ruby
    Sadist
    The time has come to show your code who’s boss.
    http://ruby.sadi.st/Ruby_Sadist.html

    View full-size slide

  8. 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

    View full-size slide

  9. 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

    View full-size slide

  10. 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

    View full-size slide

  11. 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

    View full-size slide

  12. 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

    View full-size slide

  13. Tests are
    refactoring
    best friends

    View full-size slide

  14. 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.

    View full-size slide

  15. 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.

    View full-size slide

  16. "Simplicidade é o último grau de
    sofisticação"
    Leonardo Da Vinci

    View full-size slide

  17. "Tudo deve ser feito da forma
    mais simples possível, mas não
    mais simples que isso"
    Albert Einstein

    View full-size slide

  18. "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

    View full-size slide

  19. "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

    View full-size slide

  20. "O propósito da engenharia de
    software é controlar a
    complexidade, não cria-lá."
    Pamela Zave

    View full-size slide

  21. “Em programação, a elegância
    não é um luxo mas sim uma
    qualidade que decide entre o
    sucesso e o fracasso.”
    Edsger Dijkstra

    View full-size slide

  22. Estado de fluxo (flow) de Mihaly Csikszentmihalyi

    View full-size slide

  23. 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

    View full-size slide

  24. 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!

    View full-size slide

  25. 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

    View full-size slide

  26. 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

    View full-size slide

  27. 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

    View full-size slide

  28. 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

    View full-size slide

  29. 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

    View full-size slide

  30. 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

    View full-size slide

  31. Mantenha o balanço dos componentes
    Nem pouco, nem muito.
    Poucos trazem complexidade, muitos trazem falta de controle.
    7

    View full-size slide

  32. 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

    View full-size slide

  33. 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

    View full-size slide

  34. 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

    View full-size slide