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 )?

THANK YOU

br.linkedin.com/in/klederson

Klederson [email protected]

for watching