Com o grande crescimento dos micro-frameworks, estamos com muito mais liberdade para criamos a nossa própria estrutura. Porém com grandes poderes temos grandes... problemas. Sempre queremos resolver todos os problemas do mundo antes mesmo da aplicação nascer. Nessa palestra eu mostro um pouco dos grandes desafios de montar a própria estrutura baseada em MVC ou outros. Exemplos de como não cair nessas armadilhas de prever problemas que ainda não existem.

1. OverEngineering
a linha entre o sucesso e o fracasso
by Daniel Archer

2. Daniel Archer
Zend Certified PHP 5.5
Análise de Sistemas
Desenvolvedor há 7 anos
Participante PHPRS
#orgulhodeserking
English Speaker
Conférencier Français
Arqueiro nas horas vagas
(duh!)

3. “Poucas coisas são garantidas que crescerão
eternamente:
● Distância entre as estrelas
● Entropia no universo visível
● As malditas Regras de negócio
“ by Subhas Dandapni

4. O que é OverEngineering?

5. Algumas imagens falam mais do que palavras

11. “Unnecessarily complicated”
by Collins English Dictionary

12. Imagine um novo projeto...

14. Imaginou?...
Agora pense em poder usar:
● todas as técnicas que aprendeu
● configurar todos os eventos já no início
● prever os futuros gatilhos que o cliente
solicitou no meio do projeto passado

16. “Premature optimization is the root of all
evil.” by Donald Knuth

17. Foca no Problema!

18. Alguns erros comuns… que já passamos
ainda

19. ● Lógicas de negócio, reusáveis
○ Ex: uma grande classe de CRUD BaseModel contendo
diversas lógicas e fluxos distintos.
○ Prefira isolar Actions do que agrupá-las em grandes
“BaseActions”

22. ● Classes Genéricas
○ Ex: Tentar abstrair todo pedaço de código
○ Às vezes é melhor duplicar do que abstrair de forma errada

25. ● Qualidade Excessiva
○ Ex: DesignPatterns e tipagem excessiva por todo o código
○ Procure olhar o software como um todo

27. ● Not-Invented-Here
○ Ex: Códigos criados dentro de Casa, reescrever bibliotecas
como CMS, template, cache, config e etc...
○ Reuse, Contribua, Reconsidere
○ Proudly-found-elsewhere

29. ● ...lidade
○ Ex: Escalabilidade, Configurabilidade, Mantenabilidade
○ Muitas vezes adicionamos uma camada extra de
complexidade, apenas para: talvez ser usada no futuro... 1x.

30. Escrever software não é fácil
mas não deve ser um tormento...

31. A dica de ouro é:
“Escreva código para ser deletado”.

32. Mas por quê?

33. Toda linha de código vem com um preço:
manutenção!

34. Não crie dependências desnecessárias.

35. “It's not a problem until it's a problem.”

36. 4 Dicas para melhorar a simplicidade do seu
código

37. 1. Não escreva código
Toda linha de código que não tem um motivo
para estar ali, é tempo gasto.

39. [Assim Não]

40. 2. Copie e Cole
Não tem problema copiar algumas poucas
vezes, para não adicionar complexidade.

42. 3. Escreva um monte de lixo
Às vezes, precisamos criar a ideia completa e
funcional para depois, sim, entender e
compreender o quê foi feito

43. 4. Quebre seu código em pedaços
Uma vez feito, separe o quê realmente é
lógica de negócio e isole o necessário.

44. A dura realidade é que:

45. O cliente é mais importante que o
desenvolvedor

46. Saímos do modelo cascata, para o modelo
ágil, justamente para entregar softwares
funcionais em menos tempo de acordo com a
necessidade do cliente.

47. Funcionalidade é mais importante que
flexibilidade

49. O segredo está em balancear técnicas de
flexibilidade e entrega de código funcional

50. Continue programando… todos os dias

51. K.
I.
S.
S.

52. K.eep
I.
S.
S.

53. K.eep
I.t
S.
S.

54. K.eep
I.t
S.imple
S.

55. K.eep
I.t
S.imple
S.tudent

56. kingho.st/daniel-archer
Palestra sobre Frameworks e Microframeworks

57. Bibliografias
1. https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-d
elete-not-easy-to
2. http://productdesignmanagement.com/over-engineering/
3. https://www.vinta.com.br/blog/2017/case-against-over-engineering/
4. https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fb
ef4fc8
5. http://www.codesimplicity.com/post/what-is-overengineering/
6. http://www2.lsd.ufcg.edu.br/~nazareno/ensino/si1/16.OverEngineering.pdf
7. https://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/
8. https://www.martinfowler.com/articles/designDead.html