↪️ 🌋 💅 Merde vieux CRM 🔁 🗑️ 🧝🏿

Toute l'année dernière, nos gars ont terminé CRM 2.0 avec BPMS Camunda et seulement dix processus au lieu de centaines de statuts, puis ont essayé de le déployer auprès des utilisateurs et des services sans rien perdre. J'espère qu'après avoir finalement coupé le premier tcm-ku (la partie la plus ancienne de tous les Skyeng) de notre écosystème, ils partageront le râteau et les trouvailles ici.

Entre-temps, étant devenu intéressé par le sujet, j'ai trouvé un cas similaire - et j'ai décidé de demander à Dmitry Kosov de Finam leur expérience d'abandonner l'héritage du début des années 2010.

Salut , je suis le même "Seryozha de Bryansk" qui a décidé de pomper les connaissances en développement par des blogs et des screencasts sur PHP. Cette année, je veux ajouter un podcast à mes activités: inviter des collègues de l'industrie. Dans le premier épisode, l'histoire du passage du premier Zend à Symfony. Si vous voulez plus de détails techniques, consultez également le discours de Dima sur Youtube . Eh bien, dans notre discussion après le rapport, vous saurez:

comment ne pas perdre et trouver de la motivation, si vous comprenez que c'est une année entière avant de lancer votre code en production,

pourquoi toute documentation si elle ne ment pas, elle ment,

et comment le processus de refactoring de deux ans est organisé sans arrêter la production de fonctionnalités en utilisant l'exemple d'un vrai projet et d'une véritable équipe.

Profitez de la lecture ou de l'écoute .

Quels cadres ont été choisis entre 2011? Et comment en choisir un nouveau en 2016

Dima, Finam: J'ai regardé spécifiquement, en préparation pour la sortie: nous avons exactement 4 600 fichiers dans le papa, où exactement notre code n'est pas un fournisseur, pas un js. Ce papa pèse 16 mètres. Et le premier engagement que nous aurions déjà fait en décembre 2011, - son auteur travaille toujours, c'est notre chef d'équipe.

Initialement, la pile a été sélectionnée correctement. Et même en 2012, c'était assez moderne - le premier Zend était assez pertinent. J'ai ensuite travaillé à un autre emploi, mais je me souviens que juste le 12, quelque part à la fin du printemps, nous avons choisi la pile pour un nouveau projet. Nous avons examiné:

Zend - le deuxième vient de sortir, mais était trop jeune, il n'y avait pas de communauté pour lui,

premier Yii - mais nous n'aimions pas le concept ActiveRecord,

Phalcon,

et autre chose d'exotique.

Et ils ont également choisi le premier Zend. À ce moment-là, c'était un bon choix pertinent. Mais la langue s'est avancée. Mais vous voulez utiliser des espaces de noms normaux, plutôt que de nommer des classes par des traits de soulignement. Je voudrais connecter des bibliothèques prêtes à l'emploi à partir de l'open source, que, bien sûr, personne n'écrit sous le premier Zend. Je voudrais attirer des employés dans l'équipe - à quelques reprises lorsque nous recherchions de nouvelles personnes, pour certains, il était écrit directement sur le visage: "Je ne le prendrai pas".

Finalement, le premier Zend a simplement cessé de le soutenir. Par exemple, à 7.0, ils ont toujours publié un correctif de mise à jour de sécurité, et nous avons corrigé 7.2 et 7.3 nous-mêmes.

Nous avons tiré un peu avec le début du processus de relocalisation.

Il n'y avait pas de risque global - nous avons juste regardé ce qui est moderne, pertinent. Par rapport à d'autres projets: nous ne sommes pas la seule équipe PHP de l'entreprise. Nous avons réalisé que Symfony allait bien avec tout le monde - cela ressemblait à un projet qui va durer plusieurs années, a une communauté étendue, beaucoup de bibliothèques prêtes à l'emploi, de nouveaux utilitaires, etc.

J'ai commencé cette entreprise - je creusais dans les premiers instants juste pour bouger, sur le mouvement vers Symfony. À mon arrivée, j'ai été plongé dans différentes parties du projet afin de pouvoir le connaître le plus largement possible - et au moment où le refactoring à grande échelle a commencé, je le connaissais assez bien. Et un autre camarade est venu après que nous ayons commencé. Nous l'avons plongé dans le processus - mais avons essayé de ne pas lui faire trop peur. Au moins au début)

D'ACCORD. Nous avons choisi un cadre. Et après?

Seryozha, Skyeng: Il y a deux façons - vous pouvez tout réécrire à la fois. Vous pouvez essayer de glisser-déposer lentement. Par où as-tu commencé?

Dima, Finam: Nous avons commencé avec l'holivar, quel chemin à parcourir. Personne n'a eu l'expérience de réécrire un tel volume. Par exemple, de mon travail précédent, j'ai eu l'expérience de réécrire un petit service autonome - là, nous avons juste gelé le développement pendant un mois, tout réécrit et continué. Ici, nous n'aurions pas suffi pendant un an. Peut-être que nous aurions réussi à gagner 80% en un an, mais, vous savez ...

Il y a un principe: les premiers 80% du travail prennent 80% du temps. Les 20% restants du travail prendront encore 80% du temps.

Il était impossible d'arrêter l'application et ses tâches actuelles. Et il y a exactement deux concepts pour ce cas: soit vous faites quelque chose avec l'application actuelle, soit vous en déployez une nouvelle. Nous avons rejeté l'option d'en déployer une nouvelle - car il y a beaucoup de code. Par conséquent, nous n'avons pas déployé l'application Symfony à côté de l'ancienne, mais en plus.

Mais pourquoi. Nous avons plus de 250 tables dans la base de données, et si vous supprimez certaines plaques de service, ce sont environ 200 entités. Ils sont assez fortement connectés les uns aux autres et en raison de ce nombre de connexions, il est très difficile de battre le code en quelques morceaux logiques autonomes. Ne le cassez pas, de toute façon, une connexion sortira de cette pièce: par exemple, les appels et la téléphonie sont connectés avec les gestionnaires et les clients. Par conséquent, nous avons réalisé: si vous déployez une nouvelle application, commencez à écrire de nouvelles fonctionnalités pour elle et transférez lentement les anciennes, cela entraînera un double travail. Après tout, le code que nous transférerons vers la nouvelle application ne peut pas être complètement coupé de l'ancienne. Et nous devrons le soutenir à deux endroits.

Ensuite, nous nous sommes souvenus d'une autre expérience que notre équipe avait déjà vécue.

Il s'agit de l'expérience de réécriture d'une couche pour accéder aux données. Parce qu'il était une fois, avec le premier Zend, Mongo a été choisi comme base de données principale. Mais la pratique a montré que le choix n'est pas très correct.

Seryozha, Skyeng: Oui, vous avez toutes les connexions relationnelles, mais vous avez choisi une base de données orientée document.

Dima, Finam: Oui, et quand je suis arrivé, les gars étaient juste en train de copier de Mongo vers PostgreSQL ... Et nous avons eu l'idée que nous avions une couche d'accès aux données. Et puisque nous savons déjà comment réécrire les couches pour l'accès aux données, nous allons peut-être l'élargir un peu et saisir immédiatement la couche ORM.

Si vous imaginez l'application comme une tarte, il y aura 5 couches: ORM, accès aux données, logique métier, contrôleur, vues. Et nous pouvons toucher 2,5 couches - changer complètement l'ORM et l'accès aux données, ainsi que partiellement - la logique métier. Pas les algorithmes eux-mêmes, mais les classes et les objets avec lesquels ces algorithmes fonctionnent. Je savais clairement qu'il était possible de digérer la doctrine séparément, eh bien, je l'ai fait.

Je suis donc entré dans notre bootstrap, j'ai initialisé la doctrine là-bas, prescrit tous les paramètres nécessaires - et j'ai donné aux gars un examen du code avec les mots: "Eh bien, quelqu'un aurait dû commencer cela."

Le début du chemin peut ressembler à ceci. Et puis nous avons appliqué le principe selon lequel un mammouth doit être mangé par parties. Parfois, les pièces s'avéraient plus que nous ne le pensions, mais la tâche de base du sprint de deux semaines était de faire un seul mouvement - et nous nous sommes assurés qu'il n'y avait pas de tâches de fonctionnalités dans la même zone.

J'ai attrapé des insectes, roulé en arrière, déployé

Seryozha, Skyeng: Pourtant, le refactoring est une chose cruciale, comment vous êtes-vous assuré?

Dima, Finam: Nous avons un certain nombre de tests unitaires - ils couvrent des points clés. Il existe un certain nombre de tests fonctionnels automatisés par notre testeur. Le travail principal du CRM est de travailler avec des données. Et pour tester sans données, avec des tests unitaires ce n'est pas toujours possible: il est plus facile d'envoyer un package, de vérifier qu'il est traité normalement, qu'une entité avec les paramètres nécessaires a été créée dessus.

Naturellement, nous avons beaucoup vérifié de nos mains: en particulier certaines choses clés et importantes, comme les mêmes clients et appels.

Je me souviens bien comment j'ai fait cette tâche. J'ai appelé notre chef du centre d'appels, et nous avons convenu que lorsqu'ils seront à court de travail et qu'il ne restera que le préposé, je ferai de mon mieux et le préposé vérifiera tout sur les vrais appels. J'ai fait de mon mieux, regardé dans les journaux, attrapé un tas de bugs, roulé, les gouverné, averti le préposé, déployé, attrapé à nouveau le paquet suivant, reculé ... Et donc quelques itérations.

Seryozha, Skyeng: Ayant fait tout le chemin, mais maintenant c'est probablement plus de la moitié du chemin, que conseilleriez-vous alors?

Dima, Finam:Je conseillerais probablement de déployer la même application Symfony par-dessus la nôtre un peu plus tôt. Pour s'assurer que ce que nous écrivons, ce que nous faisons, cela fonctionne vraiment. Je me souviens de la façon dont nous l'avons déployé, lancé d'abord à partir de la console, puis à partir du contrôleur, frappé sur notre couche de logique métier - et fait en sorte que l'application le voit, puisse accéder à tous les services, tirer toutes les méthodes, décharger les résultats.

Je viens de réaliser à quel point un motivateur était fort en réalisant que nous avions vraiment tout écrit correctement. Pour vérifier que vous allez dans la bonne direction, pour vous assurer que vous faites tout correctement, il faut le faire tôt.

Pas aux premiers pas, mais quand vous avez déjà écrit quelque chose, prenez-le comme ça, tirez pendant un an à l'avance, organisez une telle machine à remonter le temps, assurez-vous que vous faites tout correctement - cela vous donnera de la force. Et vous irez plus loin.

ps

Merci d'avoir lu et écouté. Plus de podcasts PHP peuvent être trouvés ici .

Et si vous voulez des rapports et des conversations plus intéressants autour d'eux, "venez" à la troisième réunion virtuelle PHP le 30 mai.

Merde vieux CRM