Klederson Bueno é um arquiteto de sistemas, desenvolvedor e evangelista PHP. Ele discute princípios de arquitetura de software limpo e SOLID, padrões de projeto como MVC e iterador, e abordagens ágeis como MVP e Scrum. Klederson também fala sobre a importância da legibilidade, testabilidade, manutenibilidade e reusabilidade no desenvolvimento de software.

2. Klederson Bueno
Pai
Marido
NERD
CTO
Arquiteto de Sistemas
Desenvolvedor
Evangelista PHP
github.com/klederson
br.linkedin.com/in/klederson
"I’m Batman"

3. CV / RESUME

4. "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)

5. "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 )

6. MVP
minimum Viable Product
Direct to the point01
fast02
PROOF OF CONCEPT03

7. NO DIa-a-Dia
Satisfação Pessoal
Aumentar Conhecimento
Suscetível A Mudanças
Produtividade
Novas Funcionalidades
Espaço para inovação REFACTORING

8. Produtividade e MOTIVAÇÃO
Um código limpo e claro aumenta a produtividade de
uma equipe e reduz o desinteresse natural pela
codificação no projeto.
ENTREGAS E PRAZOS
Em 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.

9. REUSABILIDADE DE CÓDIGO
No 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 PROJETOS
Um 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.

10. NO SOFTWARE
Legibilidade
Testabilidade
Suscetível A Mudanças
CLEAN CODE
S.O.L.I.D.
MANUTENIBILIDADE REUSO DE Código

11. ITERATOR
LOCATOR
Factory OBSERVER
SINGLETON
STRATEGY
FACADE
DECORATOR
COMMAND
MVC

12. Single Responsibility
Open/Close Principle
LIskov SubstitutioN
Interface Segregation
Dependency Inversion

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

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

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

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

17. DEPENDENCY INVERSION PRINCIPLE
Dependa sempre de abstrações, Elas mudam menos e são mais fáceis de serem trocadas/Mudadas quando
necessário.

18. ARQUITETURA

19. Long Term SolutionS
is that right? How hard?
Agile ( Scrum, XP, … )01
STEP BY STEP02
EVERYTHING CHANGES03

20. PARA O DESENVOLVEDOR

21. PARA O
CLIENTE

22. GET THINGS DONE

23. USABILIDADE
PRODUTIVIDADE
MUTABILIDADE

24. CODE BUROCRACY
too many

26. Dúvidas?
Reclamações? Agressões Gratuitas ( ou não )?

27. THANK YOU
br.linkedin.com/in/klederson
Klederson Bueno
klederson@klederson.com
for watching