Frameworks, ORMs, bibliotecas: escolhas (e consequências)
Pedro Cordeiro
Naroga
Desenvolvedor PHP Sênior - Sympla
me@naroga.com.br
Cenário
When should I use a framework?
Rasmus Lerdorf: All PHP frameworks suck!
When should I use a framework?
Almost always
When should I use a framework?
-
Allows focusing on the business end of your app.
-
There is a community fixing bugs that I'd need to fix on my own.
-
It's probably more secure and more extensively tested than what I can whip on my own.
A framework is just a tool, go with the one which adds the most productivity
Good devs can create great apps in any framework
Making it [the app] more scalable is about separating domain, following SOLID in that separated layer, introducing proper unit testing etc. It's developer who can do so, not the framework itself.
Alexander Makarov - Yii
A framework is just a tool, go with the one which adds the most productivity
Productivity walks hand-in-hand with simplicity;
Simplicity is not always the way to go;
Simplicity can bring technical debt;
Good devs can create great apps in any framework
Making it [the app] more scalable is about separating domain, following SOLID in that separated layer, introducing proper unit testing etc. It's developer who can do so, not the framework itself.
A framework can greatly hinder your ability to separate logic, follow SOLID and unit test. Yii is a major example of this.
Durability is key in the long run
Apps running on obsolete technology are also obsolete.
Durability is key in the long run
Can be achieved through:
-
LTS
-
Sane upgrading philosophy
-
Please, be SemVer!
-
Semantic Versioning
Semantic Versioning
Ready to use composer constraints;
Pervasiveness;
Everybody does it, right?
Wrong
Technique
The frameworks, ORMs and libraries in that you choose will greatly affect how constrained your application and future development process will be.
Making it [the app] more scalable is about separating domain, following SOLID in that separated layer, introducing proper unit testing etc.
SOLID
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Single Responsibility Principle
Classes should have only one reason to change.
One and only one well defined responsibility
Open/Closed Principle
Classes should be closed to modification...
...but should be open for extension.
Liskov Substitution Principle
If S is a subtype of T, than all T objects from an application should be replaceable by S, without changing the application properties.
Interface Segregation Principle
It's preferable to have multiple specific implementations than a single generic one.
Dependency Inversion Principle
Classes should depend on abstractions, not on implementations.
ActiveRecord violates SRP with wild abandon.
Making it [the app] more scalable is about separating domain, following SOLID in that separated layer, introducing proper unit testing etc.
Making it [the app] more scalable is about separating domain, following SOLID in that separated layer, introducing proper unit testing etc.
We can't unit test things that depend on global state.
Global state isn't just global variables. Static methods and Singletons also represent global state!
Unit testing methods with dependencies
Can't mock singletons!
Can't mock hardcoded dependencies (static methods, for example).
Managing class dependencies
Dependency Injection Containers > Service Locators
Injected dependencies can (almost always) be mocked.
Interoperability
PSR compliant frameworks allow for easy interchangeability of components.
PSRs
PHP Standard Recommendations, by the Framework Interoperability Group
PSR4 - Autoloading
PSR3 - Logging
PSR6 - Cache
PSR7 - HTTP
Other things that you might want to take into consideration
Support
Documentation quality
License
Resources available in the community at large
Things you should consider, but with limited weight
Ease of use
Productivity
Summary
A package [lack of] technique can constrain your application and your development processes.
Develop like you will outgrow your short-term commercial needs. The tradeoff is inelastic most of the time.
Try to keep personal preferences away from company choices.
Important notices
WE ARE HIRING
Backend and frontend
Important notices
ESTOU DOANDO OITO FILHOTES
SOCORRO
This presentation is available at
slides.com/naroga
presentation
By Pedro Cordeiro
