ZendFramework + Bitrix
Perhaps it was one of the most dreary ways for me lately.
So. We are engaged in technically complex projects, potentially designed for high loads (highload). It so happened that among content management systems, Bitrix won so far. Customers want it. Judging by our experience - highload on Bitrix is a very real task, if you do everything carefully.
')
Usually in projects where there are a lot of forms, personal accounts or some kind of complicated logic, we offered the client a choice on implementation on Zend Framewok or on Bitrix. The minus of ZendFramework was that you need to write an admin on it. Minus of the Beatrix - it is poorly suited for projects with complex business logic: there is really no MVC and in some places there is a disgusting code and API. Marketing tales about the D7 core, which are already 2 years old - we do not take into account:
So, there was an idea on complex projects to use ZendFramework with data management from the Beatrix admin panel. We implemented the architecture in such a way that it is possible both to use the ViewHelper inside Bitrix templates, and to call the components inside the View. For all typical things sites (product catalogs, text pages, news, etc.) is responsible Bitrix. For complex forms, personal accounts, profiles - Zend. As a result, we got a fast and extremely flexible system, with a pleasant code in work, having spent approximately 3 days on integration.
1. Pilot project. We decided to do Scrumban on ZendFramework, because we wanted to have a structured code that would please. It was on this project that we had time to experiment and were able to work out the main points of integration:
2. Overcome skepticism of the most skeptical. Since we already had a working prototype of the bundle in our hands, we could discuss the code. I met the fierce resistance of one dude of my company. For about an hour, he found fault with our implementation, which ultimately helped us find a few mistakes and make a number of improvements. After that, the critic had no logical arguments left and we could move on.
3. Performance experiments. We really feared that loading the ZendFramework framework would cost considerable system time. After a series of optimizations, we carefully carried the load to autoload. The difference between the start of the pure bitrix and our bundle was 0.033 seconds, which is a penny compared to the ability to quickly develop well-structured code.
4. Experimental commercial projects. There were two of them. We managed to quite clearly understand at what point we need to beat our hands for trying to rewrite the standard logic of the Beatrix operation on ZF.
5. General meeting with the story of Cho-Cavo. We have this regularly and is called HolyWarModeOn. Gathered-discussed. I did not prepare well, so I caught (apart from my interest) another pack of skepticism. But I already had several working systems on my hands, the code of which pleased me. Like their performance. Therefore, I was sure: everything will work out.
6. Root Cause Analysis. I was asked to clearly justify the purpose for which integration with ZF is needed. I spent about half a day analyzing the root causes and made a printout in half of the wall with a tree of causal relationships. The printout hung a couple of weeks on public display: an excellent example of banner blindness.
The most basic thing I wanted to get:
7. Preparation of a clean assembly Bitrix. We use one clean build with an activated NFR license, which integrates our work. In principle, all developers have the potential to commit something there. When creating a new project, a special script creates a new repository and database on the dev server. A copy of the clean build is deployed to the new repository (trial box).
8. ZF training. It is no secret that knowledge of ZF requires more skill than riveting saytik purely on Bitrix. We conducted several holivars, where we detailed the MVC architecture and implemented basic terminology. After that, each of the developers received a test task and time to solve it. It was necessary in practice to touch the controllers, forms, helpers, validators. In my opinion, it was driving;) By that time, 80% of developers had already participated in commercial projects at ZF.
9. I conducted the formal exam in person. But not on knowledge of the theory, but sorting out along with the developers the code of his last project and giving feedback: what to tighten, what things are better to do differently, and so on. It took me almost a week. It was during the exam that I realized that the implementation was successful, because skepticism is gone completely and in all. On the contrary, one felt the desire to develop and pump oneself further.
10. Regular code review practices. This is quite a difficult practice. Requires perseverance and thoughtfulness. To find something more serious than outright shit or extra spaces, you need to work with your head. Sometimes it makes sense to conduct a code review paired with the developer. Especially if the system architecture is non-trivial. I consider code review an important learning practice. Analysis of the real project code gives the developer feedback. It is important for all of us to understand whether we are developing properly or not.
It seems to me that we found a good balance between:
More optimism, friends.
So. We are engaged in technically complex projects, potentially designed for high loads (highload). It so happened that among content management systems, Bitrix won so far. Customers want it. Judging by our experience - highload on Bitrix is a very real task, if you do everything carefully.
')
Usually in projects where there are a lot of forms, personal accounts or some kind of complicated logic, we offered the client a choice on implementation on Zend Framewok or on Bitrix. The minus of ZendFramework was that you need to write an admin on it. Minus of the Beatrix - it is poorly suited for projects with complex business logic: there is really no MVC and in some places there is a disgusting code and API. Marketing tales about the D7 core, which are already 2 years old - we do not take into account:
“Talk is cheap. Show me the code "(Linus)
So, there was an idea on complex projects to use ZendFramework with data management from the Beatrix admin panel. We implemented the architecture in such a way that it is possible both to use the ViewHelper inside Bitrix templates, and to call the components inside the View. For all typical things sites (product catalogs, text pages, news, etc.) is responsible Bitrix. For complex forms, personal accounts, profiles - Zend. As a result, we got a fast and extremely flexible system, with a pleasant code in work, having spent approximately 3 days on integration.
Implementations:
1. Pilot project. We decided to do Scrumban on ZendFramework, because we wanted to have a structured code that would please. It was on this project that we had time to experiment and were able to work out the main points of integration:
- Joint sessions.
- Joint connection with the database (haha, the old Bitrix code does not know how to work with MySQLi, but uses the outdated MySQL driver. ZendFramework does not support this junk, so I had to program a little).
- Binding to information blocks for working with models.
- Routing
2. Overcome skepticism of the most skeptical. Since we already had a working prototype of the bundle in our hands, we could discuss the code. I met the fierce resistance of one dude of my company. For about an hour, he found fault with our implementation, which ultimately helped us find a few mistakes and make a number of improvements. After that, the critic had no logical arguments left and we could move on.
3. Performance experiments. We really feared that loading the ZendFramework framework would cost considerable system time. After a series of optimizations, we carefully carried the load to autoload. The difference between the start of the pure bitrix and our bundle was 0.033 seconds, which is a penny compared to the ability to quickly develop well-structured code.
4. Experimental commercial projects. There were two of them. We managed to quite clearly understand at what point we need to beat our hands for trying to rewrite the standard logic of the Beatrix operation on ZF.
5. General meeting with the story of Cho-Cavo. We have this regularly and is called HolyWarModeOn. Gathered-discussed. I did not prepare well, so I caught (apart from my interest) another pack of skepticism. But I already had several working systems on my hands, the code of which pleased me. Like their performance. Therefore, I was sure: everything will work out.
6. Root Cause Analysis. I was asked to clearly justify the purpose for which integration with ZF is needed. I spent about half a day analyzing the root causes and made a printout in half of the wall with a tree of causal relationships. The printout hung a couple of weeks on public display: an excellent example of banner blindness.
The most basic thing I wanted to get:
- Structuring and standardization of code on complex projects. MVC. ORM.
- The need to raise the motivation of developers who are forced to pick the bitcode coprocode.
- Acceleration of development through joint developments (for example, we have an excellent database change logger, which allows you to see how the database has changed since the last release).
7. Preparation of a clean assembly Bitrix. We use one clean build with an activated NFR license, which integrates our work. In principle, all developers have the potential to commit something there. When creating a new project, a special script creates a new repository and database on the dev server. A copy of the clean build is deployed to the new repository (trial box).
8. ZF training. It is no secret that knowledge of ZF requires more skill than riveting saytik purely on Bitrix. We conducted several holivars, where we detailed the MVC architecture and implemented basic terminology. After that, each of the developers received a test task and time to solve it. It was necessary in practice to touch the controllers, forms, helpers, validators. In my opinion, it was driving;) By that time, 80% of developers had already participated in commercial projects at ZF.
9. I conducted the formal exam in person. But not on knowledge of the theory, but sorting out along with the developers the code of his last project and giving feedback: what to tighten, what things are better to do differently, and so on. It took me almost a week. It was during the exam that I realized that the implementation was successful, because skepticism is gone completely and in all. On the contrary, one felt the desire to develop and pump oneself further.
10. Regular code review practices. This is quite a difficult practice. Requires perseverance and thoughtfulness. To find something more serious than outright shit or extra spaces, you need to work with your head. Sometimes it makes sense to conduct a code review paired with the developer. Especially if the system architecture is non-trivial. I consider code review an important learning practice. Analysis of the real project code gives the developer feedback. It is important for all of us to understand whether we are developing properly or not.
It seems to me that we found a good balance between:
- Do not demotivate developers by digging into the bitrix bydlocode.
- make quality architecture.
- Do not reinvent the wheel, to the maximum using the capabilities of the CMS and the frame MVC.
- deliver high-tech products to the customer with clear, clear and supported code.
More optimism, friends.
Source: https://habr.com/ru/post/187382/
All Articles