In a previous article we started to tell you why Symfony is awesome! In this article you will find out not only why developers love Symfony but why EVERYBODY does!
Why QAs love Symfony ?
Symfony also helps our QAs in testing. We activate Symfony’s debugger and profiler in our staging environments to allow them to monitor more closely what the application is doing while running. It allows them to see what Database queries or other remote calls slow the application down, and also what errors or warning the application outputs in the logs. It’s all there, in a friendly User Interface called the WebProfiler.
Also, because of the decoupling offered by the Framework, our QAs need to test only the modules that change from one version to another. Our testers are now focused on features, not regressions.
Because Symfony2 is a decoupled framework, it exposes clearly-defined interfaces that the code can rely on. By keeping the interfaces we can replace entire modules without breaking BC and worrying about regressions. Our QA now have more time on testing the Features, not the Framework.
Testing for regressions is now a thing of the past since we started using Jenkins, for Continuous-Integration, and PHPUnit with our Symfony2-based apps. This combination is the “first-line defense” for regressions in code. Once a build passes CI, our QAs can start testing the features included in it.
Our PMs love Symfony because it boosts productivity of the developers, not only because it already offers a set of fundamental tools for building features, but also because it enables them to build testable code, cutting down on QA time.
Symfony also boosts the productivity of our developers by offering access to a huge-library of pre-packaged, production-ready libraries. This is where composer comes in. Whenever there is a need for a third-party integration, or, anything, basically, we do a search on packagist, the online repository of modules. Most of the time we will find a module doing just what we need. This prevents our developers in reinventing the wheel and getting up to speed with development.
The decoupling of the framework’s internals is also reflected in the code (most of all, the code being structured in “bundles”) and because of it, our developers can have a clearer image of what needs to be done to build a feature and our PMs can get more accurate estimations. When estimating we don’t need to account for regressions, or for affecting other features. We have CI for detecting regressions and we have sandboxed modules for new features.
Getting more accurate estimations is only part of the picture. The other part is prioritization. By getting better estimations, we also enable our PMs to better prioritize the features and deliver a better schedule of releases, delighting our clients.
Our clients love Symfony because of the stability it offers and the development speed it empowers. Most of them never thought they could have a website with an 100% uptime without having Google-like infrastructure.
Symfony2 allows our clients to save both, time and money. By allowing our developers to focus on building the Features, not the Tools used to build the Features, our clients get the features faster, with less money.
It also allows us to meet incredible code-quality standards with the help of CI and QAs.