Get best of the week

Verdammt altes CRM

Das ganze letzte Jahr haben unsere Mitarbeiter CRM 2.0 mit BPMS Camunda und nur zehn Prozessen anstelle von Hunderten von Status abgeschlossen und dann versucht, es für Benutzer und Dienste bereitzustellen, ohne etwas zu löschen. Ich hoffe, dass sie, nachdem sie endlich das erste tcm-ku (den ältesten Teil von Skyeng) aus unserem Ökosystem herausgeschnitten haben, den Rechen und die Funde hier teilen werden.



Nachdem ich mich für das Thema interessiert hatte, fand ich in der Zwischenzeit einen ähnlichen Fall - und beschloss, Dmitry Kosov aus Finam nach ihren Erfahrungen mit der Aufgabe des Erbes der frühen 2010er Jahre zu fragen.

Hallo , ich bin derselbe "Seryozha aus Brjansk", der beschlossen hat, das Entwicklungswissen durch Blogging und Screencasts zum Thema PHP zu erweitern. In diesem Jahr möchte ich meinen Aktivitäten einen Podcast hinzufügen: Branchenkollegen dazu einladen. In der ersten Folge die Geschichte des Wechsels vom ersten Zend zu Symfony. Wenn Sie weitere technische Details wünschen, lesen Sie auch Dimas Vortrag auf Youtube . Nun, in unserer Diskussion nach dem Bericht werden Sie wissen:

  • Wie Sie nicht verlieren und Motivation finden, wenn Sie verstehen, dass es ein ganzes Jahr dauert, bis Sie Ihren Code für die Produktion starten.

  • warum eine Dokumentation, wenn sie nicht lügt, lügt,

  • und wie der Prozess des zweijährigen Refactorings organisiert ist, ohne die Produktion von Features am Beispiel eines realen Projekts und Teams zu stoppen.

Viel Spaß beim Lesen oder Hören .



Welche Rahmenbedingungen wurden zwischen 2011 gewählt? Und wie man 2016 einen neuen auswählt


Dima, Finam: Ich habe mich speziell um die Veröffentlichung gekümmert: Wir haben genau 4.600 Dateien im Daddy, wobei genau unser Code kein Hersteller ist, kein js. Dieser Papa wiegt 16 Meter. Und das erste Commit, das wir bereits im Dezember 2011 gemacht hätten - sein Autor arbeitet noch, das ist unser Teamleiter.

Anfangs wurde der Stapel richtig ausgewählt. Und selbst 2012 war es ziemlich modern - der erste Zend war ziemlich relevant. Ich habe dann bei einem anderen Job gearbeitet, aber ich erinnere mich, dass wir erst am 12. irgendwo im späten Frühjahr den Stapel für ein neues Projekt ausgewählt haben. Wir schauten auf:

  • Zend - der zweite kam gerade heraus, war aber zu jung, es gab keine Gemeinschaft für ihn,

  • erstes Yii - aber das ActiveRecord-Konzept hat uns nicht gefallen,

  • Phalcon,

  • und noch etwas von exotisch.

Und sie wählten auch den ersten Zend. In diesem Moment war es eine gute, relevante Wahl. Aber die Zunge ging vorwärts. Sie möchten jedoch normale Namespaces verwenden, anstatt Klassen durch Unterstriche zu benennen. Ich möchte einige vorgefertigte Bibliotheken aus Open Source verbinden, die natürlich niemand unter dem ersten Zend schreibt. Ich möchte Mitarbeiter für das Team gewinnen - ein paar Mal, als wir nach neuen Leuten suchten, stand für einige direkt auf dem Gesicht: "Ich nehme es nicht".

Letztendlich hörte der erste Zend einfach auf, ihn zu unterstützen. Zum Beispiel haben sie bei 7.0 immer noch einen Sicherheitsupdate-Patch veröffentlicht, und wir haben 7.2 und 7.3 selbst gepatcht.

Mit Beginn des Umzugsprozesses haben wir ein wenig gezogen.


Es gab kein globales Risiko - wir haben uns nur angesehen, was modern und relevant ist. Im Vergleich zu anderen Projekten: Wir sind nicht das einzige PHP-Team im Unternehmen. Wir haben festgestellt, dass Symfony mit allen zufrieden ist - es sah aus wie ein Projekt, das einige Jahre dauern wird, eine umfangreiche Community, viele vorgefertigte Bibliotheken, neue Dienstprogramme usw. hat.

Ich habe dieses Geschäft angefangen - ich habe in den ersten Augenblicken nur gegraben, um mich auf die Bewegung in Richtung Symfony zu bewegen. Als ich ankam, war ich in verschiedene Teile des Projekts vertieft, um es so umfassend wie möglich kennenzulernen - und als das groß angelegte Refactoring begann, wusste ich es gut genug. Und ein anderer Kamerad kam, nachdem wir angefangen hatten. Wir haben ihn in den Prozess eingetaucht - aber versucht, ihn nicht sehr zu erschrecken. Zumindest am Anfang)

OK. Wir haben einen Rahmen gewählt. Was weiter?


Seryozha, Skyeng: Es gibt zwei Möglichkeiten - Sie können alles auf einmal umschreiben. Sie können versuchen, langsam per Drag & Drop zu ziehen. Wo hast du angefangen

Dima, Finam: Wir haben mit dem Holivar angefangen, welchen Weg wir gehen sollen. Niemand hat die Erfahrung gemacht, einen solchen Band neu zu schreiben. Zum Beispiel hatte ich von meinem vorherigen Job Erfahrung mit dem Umschreiben eines kleinen autonomen Dienstes - dort haben wir die Entwicklung für einen Monat eingefroren, alles neu geschrieben und sind weitergegangen. Hier hätten wir ein Jahr lang nicht gereicht. Vielleicht hätten wir es geschafft, in einem Jahr 80 Prozent zu verdienen, aber wissen Sie ...

Es gibt ein Prinzip: Die ersten 80% der Arbeit dauern 80% der Zeit. Die restlichen 20% der Arbeit werden weitere 80% der Zeit in Anspruch nehmen.


Es war unmöglich, die Anwendung und ihre aktuellen Aufgaben zu stoppen. Für diesen Fall gibt es genau zwei Konzepte: Entweder Sie tun etwas mit der aktuellen Anwendung oder Sie stellen eine neue bereit. Wir haben die Option zur Bereitstellung eines neuen abgelehnt, da viel Code vorhanden ist. Infolgedessen haben wir die Symfony-Anwendung nicht neben unserer alten bereitgestellt, sondern darüber hinaus.

Aber warum so? Wir haben mehr als 250 Tabellen in der Datenbank, und wenn Sie einige Serviceplatten entfernen, sind dies ungefähr 200 Entitäten. Sie sind ziemlich stark miteinander verbunden und aufgrund dieser Anzahl von Verbindungen ist es sehr schwierig, den Code in einige autonome logische Teile zu zerlegen. Unterbrechen Sie es trotzdem nicht, eine Verbindung wird aus diesem Teil herausragen: Zum Beispiel sind Anrufe und Telefonie mit Managern und Kunden verbunden. Daher haben wir festgestellt: Wenn Sie eine neue Anwendung bereitstellen, neue Funktionen dafür schreiben und alte langsam übertragen, führt dies zu doppelter Arbeit. Schließlich kann der Code, den wir in die neue Anwendung übertragen, nicht vollständig aus der alten herausgeschnitten werden. Und wir müssen ihn an zwei Stellen unterstützen.

Dann erinnerten wir uns an eine andere Erfahrung, die unser Team bereits gemacht hatte.


Dies ist die Erfahrung des Umschreibens einer Ebene für den Zugriff auf Daten. Denn einst wurde Mongo zusammen mit dem ersten Zend als Hauptdatenbank ausgewählt. Die Praxis hat jedoch gezeigt, dass die Wahl nicht sehr richtig ist.

Seryozha, Skyeng: Ja, Sie haben alle relationalen Verbindungen, aber Sie haben eine dokumentenorientierte Datenbank ausgewählt.

Dima, Finam: Ja, und als ich ankam, waren die Jungs gerade dabei, von Mongo nach PostgreSQL zu kopieren ... Und wir hatten die Idee, dass wir eine Datenzugriffsschicht haben. Und da wir bereits wissen, wie man Ebenen für den Datenzugriff umschreibt, nehmen wir sie möglicherweise etwas weiter und greifen sofort auf die ORM-Ebene zu.

Wenn Sie sich die Anwendung als einen solchen Kuchen vorstellen, gibt es 5 Ebenen: ORM, Datenzugriff, Geschäftslogik, Controller, Ansichten. Und wir können 2,5 Ebenen berühren - ORM und Zugriff auf Daten sowie teilweise Geschäftslogik vollständig ändern. Nicht die Algorithmen selbst, sondern die Klassen und Objekte, mit denen diese Algorithmen arbeiten. Ich wusste eindeutig, dass es möglich ist, die Lehre separat zu verdauen. Nun, ich habe es getan.

Also stieg ich in unseren Bootstrap ein, initialisierte dort die Doktrin, verschrieb alle notwendigen Einstellungen - und gab den Jungs eine Codeüberprüfung mit den Worten: "Nun, jemand hätte damit anfangen sollen."


Der Anfang des Pfades könnte ungefähr so ​​aussehen. Und dann haben wir das Prinzip angewendet, dass ein Mammut in Teilen gegessen werden sollte. Manchmal stellte sich heraus, dass die Teile mehr waren als wir dachten, aber die Grundaufgabe des zweiwöchigen Sprints bestand darin, einen Zug zu machen - und wir stellten sicher, dass es in demselben Bereich keine Feature-Aufgaben gab.

Ich fing Käfer, rollte zurück, rollte aus


Seryozha, Skyeng: Trotzdem ist Refactoring eine entscheidende Sache. Wie haben Sie sich versichert?

Dima, Finam: Wir haben eine Reihe von Unit-Tests - sie decken wichtige Punkte ab. Es gibt eine Reihe von Funktionstests, die von unserem Tester automatisiert werden. Die Hauptaufgabe von CRM ist die Arbeit mit Daten. Und um ohne Daten zu testen, ist es mit Unit-Tests nicht immer möglich: Es ist einfacher, ein Paket zu senden, zu überprüfen, ob es normal verarbeitet wird und ob eine Entität mit den erforderlichen Parametern darauf erstellt wurde.

Natürlich haben wir viel mit unseren Händen überprüft: insbesondere einige wichtige und wichtige Dinge, wie die gleichen Kunden und Anrufe.


Ich erinnere mich gut, wie ich diese Aufgabe gemacht habe. Ich rief unseren Leiter des Callcenters an und wir waren uns einig, dass ich mein Bestes geben werde, wenn ihnen die Arbeit ausgeht und nur der Mitarbeiter übrig bleibt, und der Mitarbeiter alles bei echten Anrufen überprüft. Ich gab mein Bestes, sah in den Protokollen zu, fing eine Reihe von Fehlern auf, rollte weg, regierte sie, warnte den Angestellten, rollte aus, fing wieder das nächste Bündel, rollte zurück ... Und so ein paar Iterationen.

Seryozha, Skyeng: Nachdem Sie den ganzen Weg gegangen sind , aber jetzt ist es wahrscheinlich mehr als die Hälfte des Weges. Was würden Sie dann raten?

Dima, Finam:Ich würde wahrscheinlich empfehlen, die gleiche Symfony-Anwendung etwas früher zusätzlich zu unserer bereitzustellen. Um sicherzustellen, dass das, was wir schreiben, was wir tun, wirklich funktioniert. Ich erinnere mich, wie wir es bereitgestellt, zuerst über die Konsole und dann über den Controller gestartet, auf unsere Ebene der Geschäftslogik geklopft haben - und sichergestellt haben, dass die Anwendung es sieht, auf alle Dienste zugreifen, alle Methoden abrufen und die Ergebnisse entladen kann.

Ich habe gerade gemerkt, wie stark ein Motivator die Erkenntnis war, dass wir wirklich alles richtig geschrieben haben. Um zu überprüfen, ob Sie in die richtige Richtung gehen, um sicherzustellen, dass Sie alles richtig machen, sollten Sie frühzeitig vorgehen.

Nicht bei den ersten Schritten, aber wenn Sie bereits etwas geschrieben haben, nehmen Sie es so, schießen Sie ein Jahr im Voraus, organisieren Sie eine solche lokale Zeitmaschine, stellen Sie sicher, dass Sie alles richtig machen - dies gibt Ihnen Kraft. Und du wirst weiter gehen.

ps


Danke fürs Lesen und Zuhören. Weitere PHP-Podcasts finden Sie hier .

Und wenn Sie weitere interessante Berichte und Gespräche wünschen, "kommen" Sie zum dritten virtuellen PHP-Meeting am 30. Mai.

More articles:


All Articles