👩🏿‍🎨 🏴󠁧󠁢󠁥󠁮󠁧󠁿 🤘🏼 Damn old CRM ⛅️ 🤸🏾 🖖

All last year, our guys finished CRM 2.0 with BPMS Camunda and only ten processes instead of hundreds of statuses, and then tried to roll it out to users and services without dropping anything. I hope that after finally cutting out the first tcm-ku (the oldest part of all Skyeng) from our ecosystem, they will share the rake and finds here.

In the meantime, having become interested in the topic, I found a similar case - and decided to ask Dmitry Kosov from Finam about their experience of abandoning the heritage of the early 2010s.

Hi , I’m the same “Seryozha from Bryansk” who decided to pump up development knowledge by blogging and screencasts on PHP. This year I want to add a podcast to my activities: invite industry colleagues to it. In the first episode, the story of the move from the first Zend to Symfony. If you want more technical details, also check out Dima’s talk on Youtube . Well, in our discussion after the report you will know:

how not to lose and find motivation, if you understand that it’s a whole year before launching your code on production,

why any documentation if it’s not lying, it’s lying,

and how the process of two-year refactoring is organized without stopping the production of features using the example of a real project and team.

Enjoy reading or listening .

What frameworks were chosen between 2011? And how to choose a new one in 2016

Dima, Finam: I specifically looked, preparing for release: we have exactly 4,600 files in the daddy, where exactly our code is not vendor, not any js. This daddy weighs 16 meters. And the first commit we would have made already in December 2011, - its author is still working, this is our team leader.

Initially, the stack was selected correctly. And even in 2012, it was quite modern - the first Zend was quite relevant. I then worked at another job, but I remember that just in the 12th somewhere in the late spring, we chose the stack for a new project. We looked at:

Zend - the second one just came out, but was too young, there was no community for him,

first Yii - but we didn’t like the ActiveRecord concept,

Phalcon,

and something else from exotic.

And they also chose the first Zend. At that moment it was a good, relevant choice. But the tongue went forward. But you want to use normal namespaces, rather than naming classes through underscores. I would like to connect some ready-made libraries from open source, which, of course, no one writes under the first Zend. I would like to attract employees to the team - a couple of times when we were looking for new people, for some it was written directly on the face: “I won’t take it”.

Ultimately, the first Zend simply stopped supporting it. For example, at 7.0 they still released a security update patch, and we patched 7.2 and 7.3 ourselves.

We pulled a little with the beginning of the relocation process.

There was no global risk - we just looked at what is modern, relevant. Compared with that on other projects: we are not the only PHP team in the company. We realized that Symfony was happy with everyone - it looked like a project that will live for a number of years, has an extensive community, a lot of ready-made libraries, new utilities, and so on.

I started this business - I was digging in the first moments just for moving, on the movement towards Symfony. When I arrived, I was immersed in different parts of the project so that I could get to know it as widely as possible - and by the time large-scale refactoring began, I knew it well enough. And another comrade came after we started. We immersed him in the process - but tried not to scare him much. At least at the beginning)

OK. We have chosen a framework. What's next?

Seryozha, Skyeng: There are two ways - you can rewrite everything at once. You can try to slowly drag and drop. Where did you start?

Dima, Finam: We started with the holivar, which way to go. No one has had the experience of rewriting such a volume. For example, from my previous job I had experience rewriting a small autonomous service - there we just froze development for a month, rewrote everything and went on. Here we would not have been enough for a year. Maybe we would have managed to make 80 percent in a year, but, you know ...

There is a principle: the first 80% of the work takes 80% of the time. The remaining 20% of the work will take another 80% of the time.

It was impossible to stop the application and its current tasks. And there are exactly two concepts for this case: either you are doing something with the current application, or you are deploying a new one. We dismissed the option of deploying a new one - because there is a lot of code. As a result, we deployed the Symfony application not near our old one, but on top of it.

But why so. We have more than 250 tables in the database, and if you remove some service plates, these are about 200 entities. They are quite strongly connected with each other and due to this number of connections it is very difficult to beat the code into some autonomous logical pieces. Do not break it, anyway, a connection will stick out of this piece: for example, calls and telephony are connected with managers and clients. Therefore, we realized: if you deploy a new application, start writing new features for it, and slowly transferring old ones, this will result in double work. After all, the code that we will transfer to the new application cannot be completely cut out from the old. And we will have to support him in two places.

Then we remembered another experience that our team already had.

This is the experience of rewriting a layer to access data. Because once upon a time, along with the first Zend, Mongo was chosen as the main database. But practice has shown that the choice is not very correct.

Seryozha, Skyeng: Yes, you have all the relational connections, but you have chosen a document-oriented database.

Dima, Finam: Yes, and when I arrived, the guys were just in the process of copying from Mongo to PostgreSQL ... And we got the idea that we have a data access layer. And since we already know how to rewrite layers for data access, maybe we will take it a little wider from it and immediately grab the ORM layer.

If you imagine the application as such a pie, there will be 5 layers: ORM, data access, business logic, controller, views. And we can touch 2.5 layers - completely change ORM and access to data, plus partially - business logic. Not the algorithms themselves, but those classes and objects with which these algorithms work. I clearly knew that it is possible to digest the doctrine separately, well, I did it.

So I got into our bootstrap, initialized the doctrine there, prescribed all the necessary settings - and gave the guys a code review with the words: “Well, someone should have started this.”

The beginning of the path may look something like this. And then we applied the principle that a mammoth should be eaten in parts. Sometimes the pieces turned out to be more than we thought, but the basic task of the two-week sprint was to take one move - and we made sure that there were no feature tasks in the same area.

I caught bugs, rolled back, rolled out

Seryozha, Skyeng: Still, refactoring is a crucial thing, how did you insure yourself?

Dima, Finam: We have a number of unit tests - they cover key points. There are a number of functional tests automated by our tester. The main job of CRM is working with data. And to test without data, with unit tests it’s not always possible: it’s easier to send a package, check that it is processed normally, that an entity with the necessary parameters was created on it.

Naturally, we checked a lot with our hands: especially some key and important things, like the same clients and calls.

I remember well how I did this task. I called our head of the call center, and we agreed that when they run out of work and only the attendant remains, I will give my best, and the attendant will check everything on real calls. I gave my best, watched in the logs, caught a bunch of bugs, rolled away, ruled them, warned the attendant, rolled out, again caught the next bundle, rolled back ... And so a few iterations.

Seryozha, Skyeng: Having gone all the way, but now it’s probably more than half the way, what would you advise then?

Dima, Finam:I would probably advise deploying the same Symfony application on top of ours a little earlier. To make sure that what we write, what we do, it really works. I remember how we deployed it, launched it first from the console, then from the controller, knocked on our layer of business logic - and made sure that the application sees it, can access all services, pull all methods, unload the results.

I just realized how strong a motivator was the realization that we really wrote everything correctly. To check that you are going in the right direction, to make sure that you are doing everything correctly, should be done early.

Not at the first steps, but when you already have something written, take it like this, shoot for a year in advance, organize such a local time machine, make sure that you are doing everything right - this will give you strength. And you will go further.

ps

Thanks for reading and listening. More PHP podcasts can be found here .

And if you want more interesting reports and conversations around them, "come" to the third virtual PHP-meeting on May 30.

Damn old CRM