Hardcore-Sachen: eine Reise zur Rekonstruktion von mehr als 30.000 Codezeilen in einem Kernsystem

Da gibt es diese Passage im klassischen Buch „Refactoring“:

Am Anfang ging es bei den Refactorings, die ich durchgeführt habe, nur um Details. Wenn der Code prägnanter wird, sehe ich einige Dinge auf Designebene, die ich vorher nicht verstehen konnte. Ohne Refactoring wäre ich nicht in der Lage, diese Ebene zu erreichen.

Refactoring ist wirklich eine spannende Sache für Programmierer.

Zu Beginn dieses Jahres hat unser Team die Rekonstruktion eines komplexen Projekts abgeschlossen, das den Kernbestandteil des Werbesystems darstellt. Es umfasst etwa 300 Dateien und mehr als 30.000 Zeilen Code.

Vom Entwurf der technischen Lösung bis zur endgültigen vollständigen Einführung vergingen nur etwa 1 Monat, und es gab keine Unfälle.

Dies sollte das größte und erfolgreichste Refactoring-Projekt sein, das ich je in meiner 8-jährigen Programmierkarriere erlebt habe: Die Geschwindigkeit ist schnell genug, der Plan ist umfassend und die Qualität ist akzeptabel.

01 Lassen Sie uns zunächst über den historischen Ballast dieses Systems sprechen

Unsere Werbemaschine durchlief vor dieser Rekonstruktion etwa eineinhalb Jahre der Iteration. In der Anfangsphase war sie auf Suchszenarien ausgerichtet, mit einem Einzelgeschäft und klare Prozesse.

Ab 2019 begann das Werbegeschäft des Unternehmens schnell zu expandieren, wobei der Umsatz nahezu exponentiell wuchs. In diesem Prozess stand unsere Werbemaschine vor zwei Herausforderungen:

1. Die Geschäftsszenarien wurden zunehmend komplexer. Zusätzlich zur Suchmaschinenwerbung musste sie auch Informationsflussempfehlungen und ähnliche Empfehlungsszenarien unterstützen.

2. Der Werbeverkehr beginnt rasant zuzunehmen. Neben der Erfüllung der funktionalen Anforderungen muss auch die Leistung berücksichtigt werden.

Nach dem Aussortieren kann der größte Teil der Logik der gesamten Engine gemeinsam genutzt werden, daher haben wir ein Hauptgerüst definiert und die erweiterbaren Teile abstrahiert. Auf diese Weise kann jedes Szenario entsprechend den Besonderheiten seines eigenen Unternehmens bestimmte öffentliche Schnittstellen implementieren. Darüber hinaus haben wir aus Performance-Sicht die Lesbarkeit des Codes geopfert und einige Logik parallelisiert.

Mit der Geschäftsentwicklung begann das Suchszenario in eine Phase schneller Iteration einzutreten, in der immer mehr neue Strategien hinzugefügt wurden und unser Hauptrahmen zu diesem Zeitpunkt allmählich unflexibel wurde.

Wenn Sie den Hauptrahmen ändern, müssen andere Szenen als die Suche entsprechend rekonstruiert werden. Während der Zeit der schnellen Geschäftsentwicklung ist der Bauzeitplan überhaupt nicht zulässig, sodass wir die Patch-Entwicklung nur auf dem vorhandenen Framework durchführen können. Dies führt zu zwei offensichtlichen Problemen:

1 Um mit der speziellen Suchlogik kompatibel zu sein, müssen wir in anderen Szenarien verschiedene Wenn-Urteile hinzufügen, um diese Logiken zu umgehen.

2. Es gibt immer mehr Werbestrategien, insgesamt Dutzende. Wenn das Framework seine klare Struktur verliert, beginnt die Umsetzung einiger Strategien, es mangelt an hierarchischer Unterteilung und einem steckbaren abstrakten Design.

In diesem Zusammenhang begann der Code mit der Anhäufung von Änderungen von der ursprünglichen Absicht des Designs abzuweichen, und die technischen Schulden wurden immer schwerer. Wir konnten jedoch nie den richtigen Zeitpunkt für eine Umgestaltung finden.

Der Wendepunkt kam Ende 2019. Aufgrund der Besonderheiten des Werbegeschäfts begann der Verkehr natürlich zu sinken. Darüber hinaus konzentrierte sich das Produktbetriebsteam auf die Arbeitsplanung für das zweite Jahr , was uns sehr geholfen hat, mit dem Wiederaufbau zu beginnen.

Wir haben die Bauzeit auf 1 Monat festgelegt und am Ende war es nur einen Tag später als erwartet online. Obwohl zwei Online-Probleme auftraten, wurden diese rechtzeitig während der Graustufenphase entdeckt und behoben, und es gab keine Offline-Probleme Unfall verursacht wurden.

Im Allgemeinen handelt es sich um ein schwieriges und relativ erfolgreiches Refactoring-Projekt. Lassen Sie uns ausführlich über die wertvollen Erfahrungen sprechen, die ich aus diesem Projekt gewonnen habe.

02 Welche Vorbereitungen haben wir vor dem Refactoring getroffen?

Die Menge des dieses Mal überarbeiteten Codes ist sehr groß, mehr als 30.000 Zeilen, und es handelt sich um den Kernmotor des Werbesystems. Vor dem Start können wir mit folgenden Schwierigkeiten rechnen:

1. Widerstand auf der Unternehmensseite: Diese Umstrukturierung kann zwar langfristige F&E-Effizienz bringen Das Geschäftseinkommen kann nicht direkt verbessert werden, und der Entwicklungszyklus wird nicht zu kurz sein. Wie können wir Unterstützung von Kommilitonen aus der Wirtschaft erhalten?

2. Technische Bedenken: Sobald Refactoring einen Online-Unfall verursacht, verfügt das Unternehmen über ein Strafsystem, das alle leichtfertig in die Schlacht ziehen lässt. Wenn während des Rekonstruktionsprozesses sehr umfangreiche Geschäftsiterationen auftreten, kann gleichzeitig niemand die Lieferzeit garantieren und es wird schwierig, die Qualität zu kontrollieren.

Als Reaktion auf die Anliegen dieser beiden Parteien spielen meiner Meinung nach folgende Aufgaben eine Schlüsselrolle.

▍Lassen Sie alle die Schmerzpunkte sehen

Wie bereits erwähnt: Mit der Geschäftsiteration ist das Hauptgerüst unserer Werbemaschine verschwommen und Dutzende Werbestrategien sind in verschiedenen Geschäftsszenarien mit chaotischen Konfigurationen verstreut.

Als Reaktion auf diese beiden Schwachstellen haben wir einen Monat im Voraus begonnen, das bestehende Geschäft zu sortieren, alte Codes zu lesen und frühere Anforderungsdokumente durchzusehen. Schließlich haben wir die Kernprozesse und Werbestrategien verschiedener Szenarien in ein A eingeteilt klare Form.

Diese Tabelle ermöglicht es Technologie und Produkten zum ersten Mal, das Gesamtbild unseres Motorteils klar zu erkennen und die Komplexität des Geschäfts und die aktuellen technischen Engpässe zu verstehen.

▍Nachdem wir die Ziele und Werte des Refactorings geklärt hatten und jedem die Schwachstellen bewusst gemacht hatten, planten wir zwei Kernziele für dieses Refactoring:

1 des Hauptrahmens: Modularisieren Sie den Hauptprozess, definieren Sie die Protokolle der oberen und unteren Schicht neu und stellen Sie sicher, dass jede Ebene auch intern abstrahiert werden muss und eine gute Skalierbarkeit aufweist.

2. Flexible und konfigurierbare Strategien: Werbestrategien werden nach Geschäftsabsichten klassifiziert und abstrahiert, die Ausführungsbedingungen der Strategien sind dynamisch konfigurierbar und die Strategien können nach Belieben ein- und ausgeschaltet werden.

Darüber hinaus haben wir die erwarteten Vorteile verfeinert, die nach Erreichen dieser beiden Kernziele erzielt werden können:

1. Technische Vorteile: Die Codestruktur ist klarer, einfacher zu verstehen und zu warten; die Skalierbarkeit wird verbessert und die Effizienz der Engine-Entwicklung wird weiter verbessert.

2. Geschäftsvorteile: Strategien können eine detailliertere Konfiguration und Erweiterung ermöglichen und sind geschäftsfreundlicher. Eine verbesserte F&E-Effizienz kann die Geschäftsiteration weiter beschleunigen.

Nachdem der Wert des Wiederaufbaus für alle synchronisiert wurde, steigert er die Begeisterung aller weiter und gibt allen eine stärkere Motivation zur Teilnahme.

▍Kontrolle des Gesamtrhythmus

Die Kontrolle des Gesamtrhythmus ist ebenfalls ein sehr wichtiger Teil, damit jeder eine Zeitvorstellung für diese Angelegenheit haben kann.

Zunächst haben wir die Bauzeit auf 1 Monat festgelegt, einerseits auf die maximal akzeptable Durchlaufzeit, andererseits auf eine schnelle Lösung aus technischer Sicht Das Frühlingsfest rückt näher und wir müssen uns beeilen, bevor das Unternehmen geschlossen wird. Gehen Sie online, bevor Sie online gehen, und reservieren Sie einen Puffer von 1-2 Wochen, um unerwartete Situationen zu vermeiden.

Darüber hinaus haben wir mit der Unternehmensseite eine Vereinbarung getroffen: Während der Umbauzeit werden nicht dringende Anforderungen für den Motorteil nicht akzeptiert. Dadurch können parallele Entwicklungs- und Codekonflikte minimiert werden und das Team kann sich stärker konzentrieren.

03 Welche Erfahrungen können Sie während des Implementierungsprozesses teilen?

Dieses Refactoring verlief so reibungslos, dass ich 4 wertvolle Erfahrungen mit Ihnen teilen kann.

1. Hochwertige technische Designlösungen

Dies ist auf die täglichen Anforderungen zurückzuführen. Wir entwerfen technische Lösungen für Projekte mit einem Entwicklungszyklus von mehr als 3 Tagen. Diese Rekonstruktion ist sicherlich keine Ausnahme.

Die Gesamtarchitektur des Frameworks, das Protokolldesign zwischen Modulen und das Skalierbarkeitsdesign der Strategie stehen im Mittelpunkt dieser technischen Lösung, die das Team nicht weniger als dreimal besprach.

Nachdem der große Plan fertiggestellt war, verfeinerte das Team die öffentlichen Teile wie Datenbank, Schnittstellenfelder, Cache-Struktur, vergrabene Protokollpunkte usw. weiter. Da es sich um eine kollaborative Entwicklung mit mehreren Personen handelt, stimmte das Team zu, Dokumente als zu verwenden Die Kommunikationsschnittstelle und Dokumente bleiben immer mit Ihrem Code synchron.

Unter solch hohen Anforderungen erstellte das Team ein technisches Lösungsdokument mit mehr als 5.000 Wörtern und insgesamt 36 Seiten, das eine gute Grundlage für die allgemeine Qualitätssicherung legte.

2. Refactoring des Framework-Codes

Dieser PR ist sehr wichtig und der wichtigste Schritt von der Implementierung unserer technischen Lösung bis zum Code. Wir haben die rekonstruierte Paketstruktur, die Modulaufteilung, die API-Definition zwischen den einzelnen Schichten und die Abstraktion verschiedener Werbestrategien geklärt und dabei zunächst die Implementierungsdetails ignoriert.

Auf diese Weise wird im Grunde der Hauptcode gebildet, der unser ideales Framework klar darstellen kann. Anschließend organisierten wir mehrere zentrale Codeüberprüfungen und bildeten schließlich eine einheitliche Meinung.

Mit diesem Schritt kann sehr gut vermieden werden, dass man sich zu früh mit den Implementierungsdetails beschäftigt, was zu einer unzureichenden Aufmerksamkeit für das Hauptframework führt und eine spätere Überarbeitung tatsächlich die Effizienz beeinträchtigt.

3. Häufige Kommunikation und gepaarter Codeüberprüfungsmechanismus

Nach Eintritt in die detaillierte Implementierungsphase ist ein sehr wichtiger Punkt: Verständnis der vorhandenen Logik. Der Motorcode wurde anderthalb Jahre lang von vielen Menschen in der Geschichte entwickelt, aber dieses Mal beteiligten sich nur drei Studenten an der Rekonstruktion.

Wenn wir während des gesamten Prozesses auf unklare Codelogik stießen, haben wir wiederholt kommuniziert und überprüft und keine subjektiven Vermutungen angestellt. Diese Vorsicht ist tatsächlich sehr wichtig.

Darüber hinaus haben wir für die Codeüberprüfung Studenten zugewiesen, die mit diesem Geschäft vertraut sind und für jedes Modul verantwortlich sind. Sie werden paarweise gebildet und der Mechanismus ist flexibel.

4. Effektiver Testplan

Refactoring wurde nicht durchgeführt, zuerst testen. Dieses Prinzip wird im Buch „Refactoring“ hervorgehoben und steht auch im Mittelpunkt unserer Diskussion dieser technischen Lösung. Ich werde es hier im Detail hervorheben.

Zunächst haben wir in der Anfangsphase eine Vereinbarung getroffen: keinen alten Code anzufassen und ein komplett neues Paket für den Wiederaufbau zu erstellen. Dadurch ist es einfach, die Ergebnisse vor und nach der Rekonstruktion zu vergleichen und gleichzeitig Online-Graustufenexperimente durchzuführen.

In Bezug auf den Testplan lohnt es sich, aus den folgenden 4 Punkten zu lernen:

1. Durch dieses Refactoring werden keine funktionalen Anpassungen vorgenommen, also das Verhalten des Äußeren Wenn sich die API ändert, ist diese End-to-End-Testmethode die wichtigste Methode für F&E- und QS-Tests.

2. Rauchtest: QA-Studenten stellen Rauchfälle zur Verfügung und F&E-Studenten führen den Rauchtest durch. Vor dem F&E-Test müssen alle Rauchfälle bestanden werden. Das ist in den meisten Internetunternehmen nicht üblich, bei großen Projekten aber absolut effektiv.

3. Dual-Prozess-Überprüfung der Sandbox-Umgebung: Wie bereits erwähnt, bleibt der Code vor und nach unserer Rekonstruktion erhalten, sodass die Eingabeparameter der Online-Umgebung über Skripte als Fälle erfasst werden können und dann die API-Rückgaben zurückgegeben werden Auf automatisierte Weise werden die Felder einzeln verglichen.

4. Graustufenexperiment in der Online-Umgebung: Graustufen sind für die Rekonstruktion sehr wichtig. Wir verwenden die vorhandene ABTest-Plattform, um den Graustufenverkehr schrittweise von 5 % über 10 % auf 30 % und schließlich auf 100 % freizugeben Es wurde ein sehr vorsichtiges Tempo der Volumenexpansion festgelegt und anschließend durch Protokolle und die Überwachung von Geschäftsindikatoren überprüft.

Am Ende geschrieben

Überprüfung des gesamten Wiederaufbauprozesses, zusammengefasst in den folgenden 7 Schlüsselpunkten:

1. Nutzen Sie die Gelegenheit zur Umstrukturierung

2. Frühzeitiges Sortieren ist sehr wichtig, finden Sie zuerst die Ziele und Werte, um alle zu begeistern

ist nicht für den Langzeitbetrieb geeignet, es ist nicht geeignet. Parallel zum Geschäft sind hochwertige technische Lösungen erforderlich Seien Sie sorgfältig und verantwortlich für jede Codezeile. Der wichtigste Faktor sind natürlich die Menschen. Bei der Umgestaltung von Großprojekten wird die Zusammenarbeitsfähigkeit des Teams extrem auf die Probe gestellt .

Das obige ist der detaillierte Inhalt vonHardcore-Sachen: eine Reise zur Rekonstruktion von mehr als 30.000 Codezeilen in einem Kernsystem. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!