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

Greenn UP - Programação pragmática / Boas práticas

Greenn UP - Programação pragmática / Boas práticas

Avatar for Wagner Voltz - Fusca

Wagner Voltz - Fusca

July 24, 2025
Tweet

More Decks by Wagner Voltz - Fusca

Other Decks in Programming

Transcript

  1. Wagner Fusca Atuo com desenvolvimento de software desde 2005 e

    com métodos ágeis desde 2012. Ajudo empresas e pessoas a serem mais produtivas e eficientes através de consultoria, treinamentos in-company, mentorias, coach e palestras. Experiência com Kanban, métricas e BI (dados), Scrum, OKR, Management 3.0, eXtreme Programming XP, Devops, SAFe, Lean e gestão de produtos digitais. Experiência em empresas de software, indústria, comércio, fintechs, telecom, agropecuária e cosméticos
  2. Dívida técnica Toda e qualquer alteração no código fonte, realizada

    por um time de desenvolvimento de software que não gera melhoria em sua qualidade
  3. Quais sintomas indicam que tenho dívida técnica? • Perda de

    satisfação do cliente quanto a primeira entrega • Demora/atrasos para entregar o software • Erros de estimativas com frequência • Entrega de software com bug em produção • Projeto engessado • Cobertura de testes fraca • Suíte de testes que demora para ser executada • //TODO E //FIXME
  4. Bom design e código limpo faz com que você vá

    mais rápido - Martin Fowler Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
  5. Design Simples - Resolva o problema agora You Ain’t Gonna

    Need It (YAGNI)-Você Não Vai precisar Disso Adicione somente as funcionalidades que são necessárias para a aplicação. Deixe de lado qualquer tentação de adicionar outras funcionalidades que você acha que precisa.
  6. Design Simples - KISS Keep It Simple Stupid (KISS) -

    Mantenha Isto Simples Seu código fonte deve ser simples e de fácil compreensão por outras pessoas. Utilize nomes que deixem o mais claro possível o que uma classe, método ou atributo irá fazer.
  7. Design Simples - Componentizar Don’t Repeat Yourself (DRY)- Não Repita

    Você Mesmo Nunca escreva o mesmo código mais de uma vez. Eles não devem estar em mais de um lugar. Crie classe, use herança, interface, classe abstrata (polimorfismo), padrões de projeto (design pattern) para não repetir classes. https://refactoring.guru/pt-br/design-patterns/catalog
  8. SOLID • [S]ingle Responsability Principle/Princípio da Responsabilidade Única (SRP) ◦

    Uma classe deve ter apenas uma razão para mudar, ou seja, uma única responsabilidade. • [O]pen/Closed Principle/Princípio do Aberto/Fechado (OCP) ◦ Entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação. • [L]iskov Substitution Principle/Princípio da Substituição de Liskov (LSP) ◦ Subtipos devem ser substituíveis por seus tipos base sem alterar o comportamento esperado do programa. • [I]nterface Segregation Principle/Princípio da Segregação de Interface (ISP) ◦ Uma classe não deve ser forçada a implementar interfaces que não utiliza. Prefira interfaces específicas em vez de genéricas e inchadas. • [D]ependency Inversion Principle/Princípio da Inversão de Dependência (DIP) ◦ Dependa de abstrações, não de implementações. Módulos de alto nível não devem depender de módulos de baixo nível diretamente.
  9. Você precisa se dedicar mais! Estudar e praticar! >> Fundamentos

    de OO >> SOLID >> Keep It Simple Stupid KISS >> Donʼt Repeat Yourself DRY >> You Ainʼt Gonna Need It YAGNI >> Separation Of Concerns >> Object Calisthenics >> TDD >> OWASP