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