pragmatismo e padroes - um limiar tenue entre o sucesso e o fracasso do seu projeto
TRANSCRIPT
Klederson BuenoPai Marido NERD CTO Arquiteto de Sistemas Desenvolvedor Evangelista PHP
github.com/klederson
br.linkedin.com/in/klederson
"I’m Batman"
"Doutrina que toma por critério da verdade o valor prático" (Para o pragmatismo é verdadeiro tudo o que pode ser feito com êxito e não há verdade absoluta)
"Uma solução genérica e rePetível para um problema comum no desenho de software" ( Padrões de projeto e boas práticas são propostas arquiteturais para a resolução de problemas no desenvolvimento de software )
NO DIa-a-Dia
Satisfação Pessoal
Aumentar Conhecimento
Suscetível A Mudanças
Produtividade
Novas Funcionalidades
Espaço para inovação REFACTORING
Produtividade e MOTIVAÇÃOUm código limpo e claro aumenta a produtividade de uma equipe e reduz o desinteresse natural pela codificação no projeto.
ENTREGAS E PRAZOSEm qualquer negócio o planejamento é essencial e o cumprimento de prazos e entregas bem definidas são cruciais para a saúde de um projeto.
REUSABILIDADE DE CÓDIGONo ciclo de desenvolvimento toda vez que precisamos parar para criar novas ferramentas para executar tarefas já executadas antes quer dizer que estamos com uma arquitetura pobre e um código não reutilizável.
MANUTENIBILIDADE DE PROJETOSUm bom software é todo aquele no qual podemos focar pelo menos 80% do desenvolvimento das regras de negócio, novas funcionalidades e melhorias ao invés de consertar problemas.
NO SOFTWARE
Legibilidade
Testabilidade
Suscetível A Mudanças
CLEAN CODE
S.O.L.I.D.
MANUTENIBILIDADE REUSO DE Código
Single ResponsibilityOpen/Close PrincipleLIskov SubstitutioNInterface SegregationDependency Inversion
SIngle Responsibility
As classes devem ser coesas,e possuírem uma única responsabilidade. Assim ela se torna mais reutilizável, simples, e propaga muito menos mudanças para o restante do sistema.
Open/Close Principle
classes devem poder ter seu comportamento EXTENSÍVEL. por meio de herança, interface e composição. não deve ser necessário abrir a própria classe para realizar pequenas mudanças.
Dependa sempre de abstrações claras e bem definidas
LISKOV SUBSTITUTION PRINCIPLE
Herança é extremamente poderosA mas deve ser usado com sabedoria. Devemos SEMPRE evitar classes do tipo gato extende cachorro só por que eles tem algo em comum ( andar por exemplo )
Interface Segregation Principle
MóduloS SIMPLES E COM POUCOS COMPORTAMENTOS. Interfaces com muitos comportamentos dificultam a manutenção pois se espalham por todo o sistema “contaminando" outros lugares e dificultando evoluções ou
REFACTORY.
DEPENDENCY INVERSION PRINCIPLE
Dependa sempre de abstrações, Elas mudam menos e são mais fáceis de serem trocadas/Mudadas quando necessário.
Long Term SolutionSis that right? How hard?
Agile ( Scrum, XP, … )01
STEP BY STEP02
EVERYTHING CHANGES03