podTag

Tag #08 - Clean code, boas práticas e design patterns

Listen Later

Olá, mundo! Se você mantém o seu código cheiroso e limpo igual a sua mesa de escritório, esse é o podcast perfeito pra você! No oitavo episódio do podcast, vamos falar sobre Clean Code e padrões de projeto.

Participantes:

  • Luiz Gonçalves, que pelo menos indenta os códigos
  • Renan Burda, que aguarda pelo domínio do Django no mercado
  • João Risso, que deixa o código sempre cheirosinho

    • CUPONS DA SEMANA:

    • Três meses grátis de Premium no Castbox 90DAYS
    • 10% OFF na Casa do Código: (com os caracteres especiais)

      • DEVPARANÁ CONFERENCE MARINGÁ

      • Localização: Parque Internacional de Exposições Francisco Feio Ribeiro - Maringá PR
      • Data: 28 de julho
      • Agenda: 8 talks, 4 de convidados e 4 de pessoas da comunidade.
      • Site oficial e ingressos: https://www.devparana.org/conf/

        • NOVOS CANAIS DA COMUNIDADE PODTAG

        • Grupo no Facebook
        • Email oficial
        • Página oficial no Facebook
        • Site oficial (que é uma PWA \m/)
        • Perfil no GitHub
          • O que é código ‘limpo’?

          Código limpo é um estilo de desenvolvimento que tem por foco a facilidade para escrever, ler e manter o código. Para maiores informações e práticas recomendadas, leia o artigo “Clean Code: boas práticas para manter o seu código limpo!”.

          Uma referência mais completa e que criou o termo propriamente dito, foi o livro “Clean Code: A Handbook of Agile Software Craftsmanship”, escrito por Robert C. Martin.

          Code Smells

          Termo criado por Kent Beck [1] em 2006, quando este escreveu o livro Refactoring com Martin Fowler. Este livro é uma referência importante na área de refatoração de código, em Engenharia de Software.

          Code smells indicam problemas maiores em sistemas de software, como funções grandes demais, classes que acumulam muitas responsabilidades, entre outros problemas. Uma classificação dos code smells em tipos pode ser encontrada aqui e aqui.

          Padrões de projeto

          Um dos livros de maior relevância na área de padrões de projeto é o Design Patterns, publicado em 1994. Este livro aborda diversas capacidades e problemas comuns do paradigma de programação orientado a objeto.

          Os autores Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides são chamados conjuntamente de “Gang of Four”.

          Através de exemplos em C++ e Smalltalk, os autores apresentam técnicas em projeto do que acreditavam ser boas práticas de programação, o que se confirmou com o tempo. Além disso, casos de estudo são apresentados.

          Estes padrões foram classificados em três categorias: criacionais, estruturais e comportamentais. Na lista abaixo, há uma breve descrição dessas categorias e os padrões de projeto pertencentes a cada uma delas:

          • Criacional: padrões que criam/instanciam objetos, ao invés do programador instanciar os objetos diretamente. Isto dá ao programa maior flexibilidade para escolher quais objetos devem ser criados em um determinado caso.
            • Abstract factory pattern: agrupa factories de objetos que possuem uma função/tema comum.
            • Builder pattern: constrói objetos complexos através da separação entre construção e representação.
            • Factory method pattern: cria objetos sem especificar exatamente qual classe deve ser criada.
            • Prototype pattern: cria objetos clonando um objeto existente.
            • Singleton pattern: restringe a criação de um objeto de uma classe a somente uma instância.
            • Estrutural: tratam da composição de classes e objetos. Utilizam herança para compor interfaces e definir maneiras de compor objetos para obter novas funcionalidades.
              • Adapter: permite que classes com interfaces incompatíveis funcionem juntas, através do encapsulamento das interfaces neste objeto.
              • Bridge: desacopla uma abstração de sua implementação, permitindo que ambas variem de forma independente.
              • Composite: compõe zero ou mais objetos similares, para que possam ser manipulados com um único objeto.
              • Decorator: adiciona ou sobrescreve dinamicamente o comportamento de um método existente de um objeto.
              • Facade: fornece uma interface simplificada para uma interface mais complexa de código.
              • Flyweight: diminui o custo da criação e manipulação de um grande número de objetos similares.
              • Proxy: fornece uma interface similar a de um outro objeto, permitindo a separação de controle de acesso, possivelmente reduzindo a complexidade na chamada e uso deste outro objeto.
              • Comportamental: most of these design patterns are specifically concerned with communication between objects.
                • Chain of responsibility: delega os comandos para uma cadeia de objetos, onde cada objeto implementa uma parte do processamento.
                • Command: cria objetos que encapsulam ações e parâmetros.
                • Interpreter: implementa uma linguagem especializada.
                • Iterator: acessa os elementos de um objeto em ordem sequencial, sem expor a forma como esses elementos são representados.
                • Mediator: permite um acoplamento mais flexível entre classes, sendo a única classe com conhecimento de todos os métodos destas classes.
                • Memento: permite restaurar um objeto a seu estado anterior (desfazer).
                • Observer: é um padrão de publicação/assinatura que permite aos objetos observadores receberem a notificação de um evento.
                • State: permite que um objeto altere o seu comportamento quando seu estado interno é alterado.
                • Strategy: permite que um algoritmo seja escolhido dentro de um conjunto de algoritmos dinamicamente, em tempo de execução.
                • Template: define um esqueleto de um algoritmo como uma classe abstrata, delegando às suas subclasses a implementação concreta do comportamento/algoritmo.
                • Visitor: separa um algoritmo da estrutura do objeto, movendo a hierarquia de métodos em um objeto. Exemplo: em uma busca em árvore binária, o acesso ao conteúdo dos nodos pode ser definido através de um classe visitante (ex. NodeVisitor), que conhece a estrutura dos objetos representados na árvore.
                  • Boas Práticas de Programação

                  O livro “Code Complete: A Practical Handbook of Software Construction”, escrito por Steve McConnell, apresenta diversos casos de estudo de práticas de programação e boas práticas para corrigir diversos problemas comuns, como nomenclatura de variáveis e tamanho de funções. Estas práticas devem ser analisadas por projeto e implementadas caso se detecte a necessidade, não são regras absolutas.

                  Referências

                  [1] Fowler, Martin. CodeSmell. Acessado em 2019-05-29. Website: https://martinfowler.com/bliki/CodeSmell.html

                  ...more
                  View all episodesView all episodes
                  Download on the App Store
                  podTagBy podTag Team