Symphony of self-winding
Sometimes, despite all the flaws, technology shoots. All these problems see, swear, wonder, but can not do anything. Already fired, which means you have to use it, unexpectedly, of course, but once a year the stick shoots. Although the rapid emergence of new technologies in the field of web development is more like the work of a multi-barreled wooden machine gun, spewing feces. Moving from metaphors to specifics, I suppose that the PHP framework Symfony, in my opinion, is a prominent representative of such technologies. And I would like to talk about the problems of this framework.
Among those who write on symfony there are many people who sincerely love him. And among those who do not like him there are many people who, nevertheless, earn this framework. So everything written below is nothing more than psychotherapy for the latter, as well as a handy link for trolling first fans, for example, Yii.
When I first started working with this framework for 4 years, it seemed to me that it was over complicated. In the community, they explained to me that I was a noob who didn’t try so many other web frameworks to draw conclusions. This explanation made me feel better. 3 years ago I was lucky to work in tandem with a man, a symfony fan, who wanted to do everything correctly and according to ideology, which is why we godlessly broke deadlines. A colleague explained this to me by saying that it is not necessary to rivet govnokod. This explanation was from the field of ideology and I chose not to argue. 2 years ago I made a few sample projects myself, using as few symfony components as possible, and was pleasantly surprised by this framework. The community told me that I have a low level of intelligence, which is why I am not able to operate effectively with complex abstractions. This explanation is not something that would satisfy me, but at least poorly explained what was happening. A year ago, I got support from a project whose owner was unhappy with the high cost of support and low development speed. The project was written by serious guys, everything was done according to the book, the ideal code. Everything was involved: filters, all features of forms, events were actively used, the best popular bands were used where there was even the slightest opportunity not to write your code, in general the code was a rare reference that you rarely see in the open source. I wrote off the incident to the fact that the “stars” were tired of doing routine support and began to work carelessly. Well, what else could I think if the bundles to the framework multiplied, and the framework itself not only received a grant, was also considered the height of perfection everywhere?
')
And finally, a month ago, I had to leave this project, transferring it to another programmer. When I started looking for a replacement, I was confronted with the fact that all the symfony questions I could come up with for an interview somehow rested on knowledge of reference information, which, given its abundance, was not surprising but inconvenient. The search strategy of “just a sane programmer” would be a failure - you need a man who immediately drove into the project without wasting his time fighting the wisdom of the framework, which already had bumps. Moreover, the project itself was an ordinary CRUD, albeit a voluminous one. In the end, I just made an approximate list of basic things that every programmer must face in order to check whether the candidate had encountered the truth before confronting me. But this approach made me think.
Based on the results of several interviews, I came to some conclusions. First of all, symfony does not really know almost anyone, except for people who not only work with it, but, excuse me, they fart into it. Secondly, even those people who know many of the symfony components swear by their over-complexity and, as a result, do not use them. All this finally convinced me that something was wrong with this framework.
Now Symfony is about 5 years old, but this is the so-called Symfony 2 - the second branch of the framework, compatible with the first one at the level of the name almost completely (not counting the two at the end). Otherwise, these are different frameworks, and the first branch has already been safely forgotten by everyone, so the discussion is about the Symfony 2 framework, the first commits to the github repository of which were made in January 2010.
From the very beginning, the framework was positioned as a bunch of the newest, the best and the most advanced in web development in PHP, and these were the first tiles on the road leading to hell. Now it is a four-lane highway. Corporations from the pearl framework to such an extent that the creator offered training courses with certification even at the time when the framework was somewhat far from being ready for industrial use. Or maybe it was just a way to monetize, and if so, then it was a success. The very existence of such courses already indicated that the framework was not for the faint of heart and in general was intended to impress serious uncles who were used to seeing a strong correlation between the certificate and the professional competence of the certificate holder. And it’s true, there was tracing paper with many things from the cozy java-world: and dependency injection, when you can even declare your own mother a service, would be an empty line in the config, and ORM in complexity comparable to Hibernate, and annotations that were larger than annotations, and, as a finishing touch, a super-modular structure wildly crushed into files and trying to squeeze all of the OOP capabilities in PHP.
All this was so consistent with the spirit of high calm in programming that one day the creator of the framework received a grant to develop his brainchild of $ 7 million. A serious framework for serious tasks received not only arguments within the framework of the current ideology of a perfect code, but also an argument that is clear to all programmers, even completely unrelated to perfect code, and moreover, not related to programming.
First, the framework broke up, and, despite its hellish curvature in 2011, everyone just said how wonderful it is. Characteristically, many, including me, were led to this and decided to choose this framework as a way of vocational guidance. Some were silent, some were spitting, due to demagogy and active substitution of concepts (components of a symphony are used a lot where == a symphony is used a lot where) problems are largely ignored, and the popularity of the framework has grown. And after receiving the grant it was possible to shut up any skeptic. Circle samodduduva closed.
The framework is over complicated, and for no apparent reason. And all this is nailed by mental nails. In an attempt to make the framework architecture as flexible as possible, a ton of abstractions were built, requiring a boilerplate and time to get the useful code to work within these abstractions. That everything was like in Java, but only in PHP.
There is no way to get rid of this - we strongly reject the departure from the standard ideology by the community. You can not just take and refuse to use the component that you have become across the project. This would entail strong reputational costs for the unfortunate who, for example, would suggest not using standard ACLs or forms. If you want to throw Doctrine out of your project, then you will have a long and tedious explanation for everyone you meet, why you did it under a reproachful shake of the head. The symfony components themselves are very good (because of this, many third-party developers get the impression that the whole framework is just as good), but when they get together, the terrible begins.
Even though decent times have passed since the creation of PHP, and many stereotypes have lost relevance, very often in the field of web development, trash is still happening. In small projects, no one writes tests, no one works on a good architecture, no one thinks about how to maintain it. But why be honest, in medium and large all this begins to happen already after the project “survived”. This is bad, but it is the norm. According to my feelings, what they write in Habré about how to develop programs correctly is observed, God forbid, 20-30% of developers. In other cases, this is thrash, in which the perfect code is suitable only as an epitaph to the grave of the project. Here the use of symfony by all quality standards is not just throwing beads in front of pigs, it is pouring cattle with so many beads that it wheezes and dies, choking them.
Symfony gives a tremendously winding learning curve, on top of which you are not waiting for the development efficiency higher than other frameworks, but rather the ability to deal with Symfony itself. Sometimes this is the framework where it is easier to rewrite everything yourself than to follow its guidelines. I thought that I was an idiot who couldn’t understand the symphony until I had met the code from a person speaking in Symfony conferences and supporting the own fork of this framework. This code implemented its own ACL mechanism. In the comments to the code was a note - your own ACL was written because of the complexity of the standard ACL in Symfony. Maybe he is also an idiot, you can’t guess, but there is something to think about, but in general a funny picture emerges.
The complexity of the framework is such that I find myself thinking that if I haven't been actively working on a project on Symfony for a couple of weeks, then I have to enter not only the project itself, but also the framework. Maybe I have a bad memory, but can a more memorable reader, who believes that there is no such difficulty, immediately recall and write without Google and copy-paste as:
There is also a special third way, originally Russian, it is that you get a job in a low-grade web studio that rive sites on a pattern, which means you will repeat the same few operations 10 times a day, which will give the ability to remember them. And it will give a lasting illusion that you still know symfony. Although if you are inquisitive enough, you will recognize it. But why?
Unfortunately, I haven’t found a way to meet all the requirements of a modern symfony programmer without catching a brain symphony. If you, dear reader, have found one, and it is not a prize in a genetic lottery, then share it in the comments.
When I caught a glimpse of the fact that Drupal from version 8 has a lot in common with symfony, there was no limit to my surprise. After all, both products are essentially site designers, despite the fact that in one case we have a CMS, and in the other - a general-purpose framework. It is possible that the concept of the designer for most of the modern web is the concept that will save time, increase security through the use of repeatedly tested components. There still there are all kinds of ryushechki, which look very nice, and the old web macaque, which does not know the words of design, is not available for self-realization. And customers love it. Rushies, not old web macaques.
But there is a certain balance between how much time you spend on finishing the finished block, so that it works in your project, and how much time you personally spend on writing this functionality yourself. This choice is very ambiguous in the case of Symfony - the complexity of the framework itself, the imposition of complex for the architecture of bundles, the curvature of the bundles themselves, sometimes breaking during a minor update, all this makes the use of ready-made blocks not an obvious choice. Even if a ready-made bundle will save you many hours in the future, if you don’t roll out the new functionality today, there may not be a future. And you can not roll out, if you deal with a bundle - not all of them start up with a half turn. There have been cases when I threw out a bundle wrapper around a popular library after several hours of torment and eventually used my strapping or direct access to the library. Symfony is now popular, which means there is a crowd of samopiarschikov, eager to get a hundred or two stars on the githaba. Unfortunately, after the first few asterisks, the enthusiasm of such programmers fades away and you can do the bug fixes yourself.
The idea of ​​a major designer site is often criticized for the fact that such an approach is difficult to support and find those who can support it. You can not find a person immediately under the technology that you have. In the Perl world, this is even one of the most common problems - only the name remains from the web framework, anything can be hidden under the hood. And this leads to the search for “just a good programmer” and giving him time to enter the project. For PHP, where a very significant part of the projects is a trifle, budgets for which are small, and there are a lot of mediocre staff in the labor market, support for the website designer raises serious questions.
Symfony, as it is now, occupies an incomprehensible niche. Above it was written that it is best suited for mass slamming of sites based on frameworks based on it. But this is a bottom of web development, especially from the point of view of the qualifications of programmers who settle on such a bottom, sticking for 10 hours.
But symfony implies a huge amount of time for training, there is a completely official boring book on it, which reveals subtleties a little less than nothing. There are courses on it. It seems like it is designed for major major projects? Well, let's say. We seem to have all the architectural delights required in large projects. Both fragmentation, convenient for testing, and events in the core of the framework, and DI, and configuration files are subject to corporate deity Xamael, and all that jazz.
Upon closer inspection, all this is nothing more than the realization of many patterns that are themselves born in any large project. But only if they are needed. Symfony unequivocally says that they are needed. And exactly in the form in which they are implemented in symfony. Although the use of an ORM such as Doctrine in corporate projects is generally extremely doubtful - the long queries for DQL on dozens of tables are something that will not dream even in the worst nightmares. The ACL, which will be tied to LDAP and the devil still knows what, and which will need to be written almost from scratch, trying to tune out the standard symfony ACL. Looking at other architectural delights, you wonder - the component for dumping recursive data structures (and these are almost the things you want to dump) appeared only in version 2.6, after the release of the first LTS branch. It took about 4 years for such an elementary feature to appear in the framework.
For small piece projects, symfony is good at the cost of a huge number of bundles. But it is bad due to the complexity of training and ... solving problems caused by the framework itself - all this takes time. On the other hand, based on symfony, you can easily build your own framework that meets the specifics of your work. On the third hand, for as long as I can remember, web studios have always created frameworks for themselves based on anything for typical sites. And that is characteristic, the difficulties in replacing the programmer are the same as in the case of the Symfony fork, and in the case of a samopisny project.
For modern sites, symfony is good due to ... being stuck at the level of the web 2.00, or rather its first revisions. Symfony Forms is a great thing as long as you don't have to make semi-dynamic or dynamic forms. For a circle of Symfony Forms are divine, for a CRUD with a couple of dynamic fields, they are tolerable, for some serious client logic, it's easier to throw out the form and design it again. Validation and data storage will have to alter too. Those. the forms themselves are a great thing, but the transition from a simple frontend to a complex one is not thought out. The same applies to Assetic. Although otherwise Symfony promotes the most advanced (or stereotypically correct?) Approach in everything.
For corporate projects, Symfony is suitable for those that have LTS and official support, courses with certification, but bad for those ... and yet software for corporations, regardless of the framework and language, always turns out to be monstrous and difficult to support.
Even for minor changes, you have to pile up a bunch of files. For example, if you add a field to a form, you need to do this:
Insulating components by file and specifying the dependencies of some components on others also turns into a headache over time. You can not just pull the core of the framework through the global, this is wrong! Instead, when you need to do something complicated inside the Entity, but still an Entity associated with this, you can either forward the necessary dependencies to the Entity, or refactor the entire call chain upstairs, making sure that the necessary actions occur along with the Entity preservation .
In both cases, this is difficult and requires high concentration - you need to fix the constructor of the Entity or its repository, making sure that the necessary dependencies are thrown. Then make changes to services.yml. It sounds simple, but even with IDE it takes time. Refactoring with forwarding up actions that require dependencies also causes understandable difficulties. You actually fall out of the process of writing business logic and immerse yourself in the process of fitting it under the framework. This is about how to be distracted by a phone call in the process of writing code.
For components, maximum insulation is good. For business logic, this, in my opinion, causes unnecessary complexity. In any case, in the form in which it is presented Symfony.
As soon as you have declared something to be the best and actively promote it, you are almost guaranteed to have an audience that wants to join this new and better. This audience will justify any flaws and shortcomings of the technology, and you, those who disagree ... will not justify. Symfony implicitly (or still explicitly?) Implies the most advanced solutions, the most correct approaches, which indirectly means that if you are not with Symfony, then your place in vocational school, and your fate - slander sites in Jumla. The good old "who is not with us is a fool."
Okay, let's say you adapted to this alignment, and learned how to build the right mine when discussing this framework. Now you are faced with another problem - advanced solutions are often raw, they are often thrown after a couple of months of activity on the githaba by the authors themselves. But they will advise you, especially the authors themselves. You will receive inheritance bundles that do not work under 2.3 or 2.7, fixes to which you will have to search for in numerous forks. And quality, quality ... In words, all the correctness sometimes turns into compliance with the PSR and a good IDE setting. Thanks to this, tons of boilerplates give a false impression of normal code quality. The symfony community is an almost perfect example illustrating the problem of a learned fool - the knowledge is showy, superficial, there is no true understanding of how it all works, but there is demagogy that allows to justify all the problems and impenetrable self-confidence.
The saddest thing is that these people usually do not know the whole framework perfectly, but often know its individual pieces, crutches, and other goat paths. As a result, when someone does not know what they know, they repeatedly refuse to notice the complexity of the framework and the huge amount of background information that cannot be remembered. They live in a close circle of tasks, where all workarounds have already been found, and they don’t care about other parts of the framework.
The community is the main and only catalyst of the bedlam that is created with symfony. Without it, you could throw Assetic, Forms, Doctrine, and also Good Practices and use Symfony as a normal microform out of the box.
Symfony is not much worse than all other frameworks, but the ideology and unspoken rules that go along with the framework make it inefficient to use. In the case of a revision of what can and what is ungodly to do with this framework, it will be possible to work with it comfortably even in spite of the complexity. As part of this policy, the Symfony Book revision will also be useful so that it answers specific technical questions and does not teach the correct programming style.
Due to the complexity of symfony, there is a positive side, not for the customer, but for the programmer - the remuneration of labor is slightly higher than in other frameworks. Even more! On this framework, you can create such a bizarre architecture that will not be understandable to anyone, but according to all the formal features will be perfect. This will complicate the search for your replacement. Well, if you spend a couple of weeks and build your framework on the basis of symfony, then you will be relatively fun at freelancing.
I deliberately did not provide illustrations of specific problems, such as the implementation of aggregate functions on Doctrine, the slow work of Assetic, restrictions in the theme form, examples of boilerplate, etc. For those who sincerely love the framework, this is not a problem. And everyone else who also thinks that Symfony is a great way to do simple things through the thirtieth ass, I sincerely congratulate you are not alone. Welcome again.
Among those who write on symfony there are many people who sincerely love him. And among those who do not like him there are many people who, nevertheless, earn this framework. So everything written below is nothing more than psychotherapy for the latter, as well as a handy link for trolling first fans, for example, Yii.
Introduction
When I first started working with this framework for 4 years, it seemed to me that it was over complicated. In the community, they explained to me that I was a noob who didn’t try so many other web frameworks to draw conclusions. This explanation made me feel better. 3 years ago I was lucky to work in tandem with a man, a symfony fan, who wanted to do everything correctly and according to ideology, which is why we godlessly broke deadlines. A colleague explained this to me by saying that it is not necessary to rivet govnokod. This explanation was from the field of ideology and I chose not to argue. 2 years ago I made a few sample projects myself, using as few symfony components as possible, and was pleasantly surprised by this framework. The community told me that I have a low level of intelligence, which is why I am not able to operate effectively with complex abstractions. This explanation is not something that would satisfy me, but at least poorly explained what was happening. A year ago, I got support from a project whose owner was unhappy with the high cost of support and low development speed. The project was written by serious guys, everything was done according to the book, the ideal code. Everything was involved: filters, all features of forms, events were actively used, the best popular bands were used where there was even the slightest opportunity not to write your code, in general the code was a rare reference that you rarely see in the open source. I wrote off the incident to the fact that the “stars” were tired of doing routine support and began to work carelessly. Well, what else could I think if the bundles to the framework multiplied, and the framework itself not only received a grant, was also considered the height of perfection everywhere?
')
And finally, a month ago, I had to leave this project, transferring it to another programmer. When I started looking for a replacement, I was confronted with the fact that all the symfony questions I could come up with for an interview somehow rested on knowledge of reference information, which, given its abundance, was not surprising but inconvenient. The search strategy of “just a sane programmer” would be a failure - you need a man who immediately drove into the project without wasting his time fighting the wisdom of the framework, which already had bumps. Moreover, the project itself was an ordinary CRUD, albeit a voluminous one. In the end, I just made an approximate list of basic things that every programmer must face in order to check whether the candidate had encountered the truth before confronting me. But this approach made me think.
Based on the results of several interviews, I came to some conclusions. First of all, symfony does not really know almost anyone, except for people who not only work with it, but, excuse me, they fart into it. Secondly, even those people who know many of the symfony components swear by their over-complexity and, as a result, do not use them. All this finally convinced me that something was wrong with this framework.
A bit of history
Now Symfony is about 5 years old, but this is the so-called Symfony 2 - the second branch of the framework, compatible with the first one at the level of the name almost completely (not counting the two at the end). Otherwise, these are different frameworks, and the first branch has already been safely forgotten by everyone, so the discussion is about the Symfony 2 framework, the first commits to the github repository of which were made in January 2010.
From the very beginning, the framework was positioned as a bunch of the newest, the best and the most advanced in web development in PHP, and these were the first tiles on the road leading to hell. Now it is a four-lane highway. Corporations from the pearl framework to such an extent that the creator offered training courses with certification even at the time when the framework was somewhat far from being ready for industrial use. Or maybe it was just a way to monetize, and if so, then it was a success. The very existence of such courses already indicated that the framework was not for the faint of heart and in general was intended to impress serious uncles who were used to seeing a strong correlation between the certificate and the professional competence of the certificate holder. And it’s true, there was tracing paper with many things from the cozy java-world: and dependency injection, when you can even declare your own mother a service, would be an empty line in the config, and ORM in complexity comparable to Hibernate, and annotations that were larger than annotations, and, as a finishing touch, a super-modular structure wildly crushed into files and trying to squeeze all of the OOP capabilities in PHP.
All this was so consistent with the spirit of high calm in programming that one day the creator of the framework received a grant to develop his brainchild of $ 7 million. A serious framework for serious tasks received not only arguments within the framework of the current ideology of a perfect code, but also an argument that is clear to all programmers, even completely unrelated to perfect code, and moreover, not related to programming.
First, the framework broke up, and, despite its hellish curvature in 2011, everyone just said how wonderful it is. Characteristically, many, including me, were led to this and decided to choose this framework as a way of vocational guidance. Some were silent, some were spitting, due to demagogy and active substitution of concepts (components of a symphony are used a lot where == a symphony is used a lot where) problems are largely ignored, and the popularity of the framework has grown. And after receiving the grant it was possible to shut up any skeptic. Circle samodduduva closed.
Briefly about the main thing
The framework is over complicated, and for no apparent reason. And all this is nailed by mental nails. In an attempt to make the framework architecture as flexible as possible, a ton of abstractions were built, requiring a boilerplate and time to get the useful code to work within these abstractions. That everything was like in Java, but only in PHP.
There is no way to get rid of this - we strongly reject the departure from the standard ideology by the community. You can not just take and refuse to use the component that you have become across the project. This would entail strong reputational costs for the unfortunate who, for example, would suggest not using standard ACLs or forms. If you want to throw Doctrine out of your project, then you will have a long and tedious explanation for everyone you meet, why you did it under a reproachful shake of the head. The symfony components themselves are very good (because of this, many third-party developers get the impression that the whole framework is just as good), but when they get together, the terrible begins.
Even though decent times have passed since the creation of PHP, and many stereotypes have lost relevance, very often in the field of web development, trash is still happening. In small projects, no one writes tests, no one works on a good architecture, no one thinks about how to maintain it. But why be honest, in medium and large all this begins to happen already after the project “survived”. This is bad, but it is the norm. According to my feelings, what they write in Habré about how to develop programs correctly is observed, God forbid, 20-30% of developers. In other cases, this is thrash, in which the perfect code is suitable only as an epitaph to the grave of the project. Here the use of symfony by all quality standards is not just throwing beads in front of pigs, it is pouring cattle with so many beads that it wheezes and dies, choking them.
Symfony gives a tremendously winding learning curve, on top of which you are not waiting for the development efficiency higher than other frameworks, but rather the ability to deal with Symfony itself. Sometimes this is the framework where it is easier to rewrite everything yourself than to follow its guidelines. I thought that I was an idiot who couldn’t understand the symphony until I had met the code from a person speaking in Symfony conferences and supporting the own fork of this framework. This code implemented its own ACL mechanism. In the comments to the code was a note - your own ACL was written because of the complexity of the standard ACL in Symfony. Maybe he is also an idiot, you can’t guess, but there is something to think about, but in general a funny picture emerges.
Symfony-only developer
The complexity of the framework is such that I find myself thinking that if I haven't been actively working on a project on Symfony for a couple of weeks, then I have to enter not only the project itself, but also the framework. Maybe I have a bad memory, but can a more memorable reader, who believes that there is no such difficulty, immediately recall and write without Google and copy-paste as:
- do the inheritance of the tables in the doctrine, a typical action for several user groups
- add new role to standard ACL
- add helper to twig
- add annotation for for VARCHAR and TEXT in models
- add repository
- add a new validation group to the form
- add a transformer to the form
- declare something as a service, possibly with several arguments, it is possible to write a factory for this service
- implement the download of the file associated with the Entity
- add to the doctrine support for the next SQL aggregate function
- write console command
There is also a special third way, originally Russian, it is that you get a job in a low-grade web studio that rive sites on a pattern, which means you will repeat the same few operations 10 times a day, which will give the ability to remember them. And it will give a lasting illusion that you still know symfony. Although if you are inquisitive enough, you will recognize it. But why?
Unfortunately, I haven’t found a way to meet all the requirements of a modern symfony programmer without catching a brain symphony. If you, dear reader, have found one, and it is not a prize in a genetic lottery, then share it in the comments.
Constructor
When I caught a glimpse of the fact that Drupal from version 8 has a lot in common with symfony, there was no limit to my surprise. After all, both products are essentially site designers, despite the fact that in one case we have a CMS, and in the other - a general-purpose framework. It is possible that the concept of the designer for most of the modern web is the concept that will save time, increase security through the use of repeatedly tested components. There still there are all kinds of ryushechki, which look very nice, and the old web macaque, which does not know the words of design, is not available for self-realization. And customers love it. Rushies, not old web macaques.
But there is a certain balance between how much time you spend on finishing the finished block, so that it works in your project, and how much time you personally spend on writing this functionality yourself. This choice is very ambiguous in the case of Symfony - the complexity of the framework itself, the imposition of complex for the architecture of bundles, the curvature of the bundles themselves, sometimes breaking during a minor update, all this makes the use of ready-made blocks not an obvious choice. Even if a ready-made bundle will save you many hours in the future, if you don’t roll out the new functionality today, there may not be a future. And you can not roll out, if you deal with a bundle - not all of them start up with a half turn. There have been cases when I threw out a bundle wrapper around a popular library after several hours of torment and eventually used my strapping or direct access to the library. Symfony is now popular, which means there is a crowd of samopiarschikov, eager to get a hundred or two stars on the githaba. Unfortunately, after the first few asterisks, the enthusiasm of such programmers fades away and you can do the bug fixes yourself.
The idea of ​​a major designer site is often criticized for the fact that such an approach is difficult to support and find those who can support it. You can not find a person immediately under the technology that you have. In the Perl world, this is even one of the most common problems - only the name remains from the web framework, anything can be hidden under the hood. And this leads to the search for “just a good programmer” and giving him time to enter the project. For PHP, where a very significant part of the projects is a trifle, budgets for which are small, and there are a lot of mediocre staff in the labor market, support for the website designer raises serious questions.
Neither here nor here
Symfony, as it is now, occupies an incomprehensible niche. Above it was written that it is best suited for mass slamming of sites based on frameworks based on it. But this is a bottom of web development, especially from the point of view of the qualifications of programmers who settle on such a bottom, sticking for 10 hours.
But symfony implies a huge amount of time for training, there is a completely official boring book on it, which reveals subtleties a little less than nothing. There are courses on it. It seems like it is designed for major major projects? Well, let's say. We seem to have all the architectural delights required in large projects. Both fragmentation, convenient for testing, and events in the core of the framework, and DI, and configuration files are subject to corporate deity Xamael, and all that jazz.
Upon closer inspection, all this is nothing more than the realization of many patterns that are themselves born in any large project. But only if they are needed. Symfony unequivocally says that they are needed. And exactly in the form in which they are implemented in symfony. Although the use of an ORM such as Doctrine in corporate projects is generally extremely doubtful - the long queries for DQL on dozens of tables are something that will not dream even in the worst nightmares. The ACL, which will be tied to LDAP and the devil still knows what, and which will need to be written almost from scratch, trying to tune out the standard symfony ACL. Looking at other architectural delights, you wonder - the component for dumping recursive data structures (and these are almost the things you want to dump) appeared only in version 2.6, after the release of the first LTS branch. It took about 4 years for such an elementary feature to appear in the framework.
For small piece projects, symfony is good at the cost of a huge number of bundles. But it is bad due to the complexity of training and ... solving problems caused by the framework itself - all this takes time. On the other hand, based on symfony, you can easily build your own framework that meets the specifics of your work. On the third hand, for as long as I can remember, web studios have always created frameworks for themselves based on anything for typical sites. And that is characteristic, the difficulties in replacing the programmer are the same as in the case of the Symfony fork, and in the case of a samopisny project.
For modern sites, symfony is good due to ... being stuck at the level of the web 2.00, or rather its first revisions. Symfony Forms is a great thing as long as you don't have to make semi-dynamic or dynamic forms. For a circle of Symfony Forms are divine, for a CRUD with a couple of dynamic fields, they are tolerable, for some serious client logic, it's easier to throw out the form and design it again. Validation and data storage will have to alter too. Those. the forms themselves are a great thing, but the transition from a simple frontend to a complex one is not thought out. The same applies to Assetic. Although otherwise Symfony promotes the most advanced (or stereotypically correct?) Approach in everything.
For corporate projects, Symfony is suitable for those that have LTS and official support, courses with certification, but bad for those ... and yet software for corporations, regardless of the framework and language, always turns out to be monstrous and difficult to support.
Component isolation problem
Even for minor changes, you have to pile up a bunch of files. For example, if you add a field to a form, you need to do this:
- add field to FormType
- add rendering to template
- if for a new field you need some dependencies (for example, getting data from the outside for the listbox), then you need to make changes in services.yml, the form-type constructor
- if the field is tied to some field of the model, but cannot be directly saved to the base, then you need to make changes to the transformer of the form
- if this field is a file, then you may have to edit the controller code, if you do not want to disfigure the model using the file saving procedure
- if you have validation rules in the model (and in 90% of the projects they are either there or in a separate yml, but not in any way), then add annotations to the model
Insulating components by file and specifying the dependencies of some components on others also turns into a headache over time. You can not just pull the core of the framework through the global, this is wrong! Instead, when you need to do something complicated inside the Entity, but still an Entity associated with this, you can either forward the necessary dependencies to the Entity, or refactor the entire call chain upstairs, making sure that the necessary actions occur along with the Entity preservation .
In both cases, this is difficult and requires high concentration - you need to fix the constructor of the Entity or its repository, making sure that the necessary dependencies are thrown. Then make changes to services.yml. It sounds simple, but even with IDE it takes time. Refactoring with forwarding up actions that require dependencies also causes understandable difficulties. You actually fall out of the process of writing business logic and immerse yourself in the process of fitting it under the framework. This is about how to be distracted by a phone call in the process of writing code.
For components, maximum insulation is good. For business logic, this, in my opinion, causes unnecessary complexity. In any case, in the form in which it is presented Symfony.
Community
As soon as you have declared something to be the best and actively promote it, you are almost guaranteed to have an audience that wants to join this new and better. This audience will justify any flaws and shortcomings of the technology, and you, those who disagree ... will not justify. Symfony implicitly (or still explicitly?) Implies the most advanced solutions, the most correct approaches, which indirectly means that if you are not with Symfony, then your place in vocational school, and your fate - slander sites in Jumla. The good old "who is not with us is a fool."
Okay, let's say you adapted to this alignment, and learned how to build the right mine when discussing this framework. Now you are faced with another problem - advanced solutions are often raw, they are often thrown after a couple of months of activity on the githaba by the authors themselves. But they will advise you, especially the authors themselves. You will receive inheritance bundles that do not work under 2.3 or 2.7, fixes to which you will have to search for in numerous forks. And quality, quality ... In words, all the correctness sometimes turns into compliance with the PSR and a good IDE setting. Thanks to this, tons of boilerplates give a false impression of normal code quality. The symfony community is an almost perfect example illustrating the problem of a learned fool - the knowledge is showy, superficial, there is no true understanding of how it all works, but there is demagogy that allows to justify all the problems and impenetrable self-confidence.
The saddest thing is that these people usually do not know the whole framework perfectly, but often know its individual pieces, crutches, and other goat paths. As a result, when someone does not know what they know, they repeatedly refuse to notice the complexity of the framework and the huge amount of background information that cannot be remembered. They live in a close circle of tasks, where all workarounds have already been found, and they don’t care about other parts of the framework.
The community is the main and only catalyst of the bedlam that is created with symfony. Without it, you could throw Assetic, Forms, Doctrine, and also Good Practices and use Symfony as a normal microform out of the box.
is it so bad?
Symfony is not much worse than all other frameworks, but the ideology and unspoken rules that go along with the framework make it inefficient to use. In the case of a revision of what can and what is ungodly to do with this framework, it will be possible to work with it comfortably even in spite of the complexity. As part of this policy, the Symfony Book revision will also be useful so that it answers specific technical questions and does not teach the correct programming style.
Due to the complexity of symfony, there is a positive side, not for the customer, but for the programmer - the remuneration of labor is slightly higher than in other frameworks. Even more! On this framework, you can create such a bizarre architecture that will not be understandable to anyone, but according to all the formal features will be perfect. This will complicate the search for your replacement. Well, if you spend a couple of weeks and build your framework on the basis of symfony, then you will be relatively fun at freelancing.
In custody
I deliberately did not provide illustrations of specific problems, such as the implementation of aggregate functions on Doctrine, the slow work of Assetic, restrictions in the theme form, examples of boilerplate, etc. For those who sincerely love the framework, this is not a problem. And everyone else who also thinks that Symfony is a great way to do simple things through the thirtieth ass, I sincerely congratulate you are not alone. Welcome again.
Source: https://habr.com/ru/post/256111/
All Articles