Pragmatismo e Padroes - Um limiar tenue entre o sucesso e o fracasso do seu projeto
27
-
Upload
klederson-bueno -
Category
Internet
-
view
329 -
download
0
Transcript of Pragmatismo e Padroes - Um limiar tenue entre o sucesso e o fracasso do seu projeto
Klederson BuenoPai Marido NERD CTO Arquiteto de Sistemas Desenvolvedor Evangelista PHP
github.com/klederson
br.linkedin.com/in/klederson
"I’m Batman"
CV / RESUME
"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 )
MVPminimum Viable Product
Direct to the point01
fast02
PROOF OF CONCEPT03
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
ITERATOR
LOCATOR
Factory OBSERVER
SINGLETON
STRATEGY
FACADE
DECORATOR
COMMAND
MVC
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.
ARQUITETURA
Long Term SolutionSis that right? How hard?
Agile ( Scrum, XP, … )01
STEP BY STEP02
EVERYTHING CHANGES03
PARA O DESENVOLVEDOR
PARA OCLIENTE
GET THINGS DONE
USABILIDADEPRODUTIVIDADEMUTABILIDADE
CODE BUROCRACYtoo many
Dúvidas?Reclamações? Agressões Gratuitas ( ou não )?
