In den letzten zwei Wochen habe ich bei Gusto an einem wirklich großen Refactoring-Projekt gearbeitet, und mir ist klar geworden, dass dies das erste Mal ist, dass ein solches Projekt für mich reibungslos verlaufen ist. Es gab keine Schwierigkeiten im Prozess, es hat ungefähr so lange gedauert, wie ich erwartet hatte, und niemand scheint auf mich sauer zu sein. Tatsächlich liefen die Dinge fast *verdächtig* gut. Wie kam es dazu und woran lag es?
Nun, wir hatten ein Problem mit der Organisation unseres CSS. Einige Seiten in unserer App luden Bootstrap, andere nicht. Wieder andere luden nur unsere App-Styles, und einige luden nicht die Styles, die wir aus unserer Komponentenbibliothek bezogen, einem separaten Repository, das alle unsere Formulare, Schaltflächen, Variablen usw. enthält. Dies führte zu allen möglichen Design-Inkonsistenzen, aber am wichtigsten war, dass nicht klar war, wie man CSS in unserer App schreibt. Überschreiben die Styles der Komponentenbibliothek Bootstrap? Überschreibt Bootstrap die App-Styles? Das waren beängstigende Dinge.
Das Ziel war also eher komplex. Erstens musste ich herausfinden, wie unsere Styles in der App geladen wurden. Zweitens wollte ich Bootstrap aus unseren node_modules entfernen und eine neue Sass-Datei mit all diesen Styles erstellen. Drittens musste ich dann alle unsere Bootstrap-Styles entfernen und in die Komponentenbibliothek verschieben, wo wir jede Zeile Bootstrap in jede einzelne Komponente refactoren könnten (sodass alle Styles für die Tabs.jsx Komponente nur durch die Tabs.scss Datei gestylt wurden). All diese Arbeit sollte die Menge an CSS, die wir schreiben, um Tausende von Zeilen reduzieren und generell unsere Codebasis lesbarer und viel entwicklerfreundlicher für die Zukunft machen.
Bevor ich jedoch begann, wusste ich, dass alles außerordentlich organisiert sein musste, da dies eine große Umwälzung in Bezug auf unsere Codebasis mit sich bringen würde. Es wird Tabellenkalkulationen geben! Es wird einen einzigen, ordentlichen Pull Request geben! Und siehe da! Es wird eine schöne, glorreiche Dokumentation geben, die jeder lesen kann.
Hier sind also einige Tipps, um sicherzustellen, dass große Refactoring-Projekte reibungslos verlaufen, basierend auf meiner Erfahrung mit dieser großen und komplexen Codebasis. Lasst uns beginnen!
Tipp #1: Sammeln Sie so viele Daten wie möglich
Für dieses Projekt musste ich im Voraus eine Menge wissen, nämlich in Form von Daten. Diese Daten würden dann als Erfolgsmetriken dienen, denn wenn ich zeigen könnte, dass wir 90 % des CSS in der App sicher entfernen können, dann ist das ein riesiger Gewinn, den der Rest des Teams feiern kann.
Mein Lieblingstool für das Refactoring von CSS heutzutage ist die Coverage-Registerkarte von Chrome in DevTools, und das liegt daran, dass sie Ihnen zeigen kann, wie viel CSS auf einer bestimmten Seite angewendet wird. Sehen Sie hier
Und sie zeigte mir alles, was ich brauchte: die Anzahl der CSS-Dateien, die wir generierten, die Gesamtgröße dieser Dateien und wie viel CSS wir von dieser Seite sicher löschen können.
Tipp #2: Erstellen Sie eine Liste von allem, was Sie tun müssen
Das allererste Refactoring-Projekt, an dem ich bei Gusto gearbeitet habe, war ein absoluter Albtraum, weil ich direkt in die Codebasis gesprungen bin und angefangen habe, Dinge kaputt zu machen. Ich habe hier eine Klasse entfernt, dort ein Element, und bald darauf hatte ich Tausende von Zeilen CSS geändert und Hunderte von automatisierten Tests zum Scheitern gebracht. Natürlich war das alles meine Schuld und es hat eine Menge Leute wütend auf mich gemacht, und das zu Recht!
Das lag daran, dass ich mir keine Liste darüber aufgeschrieben hatte, was ich tun wollte und in welcher Reihenfolge ich es tun musste. Sobald Sie dies tun, können Sie verstehen, wie groß der Umfang des Projekts wirklich ist.
Tipp #3: Bleiben Sie fokussiert
Der zweite Grund, warum ich bei meinem ersten Refactoring-Projekt einen so großen Fehler gemacht habe, war, dass ich mich nicht auf eine sehr spezifische Aufgabe konzentriert habe. Ich habe einfach Dinge geändert, je nachdem, wie ich mich fühlte, was keine Art ist, ein Projekt zu verwalten.
Aber sobald Sie diese Aufgabenliste erstellt haben, können Sie sie sogar noch weiter in einzelne Pull-Requests unterteilen, die Sie erstellen müssen. Sie tun dies vielleicht bereits, aber ich würde Ihnen dringend empfehlen, jeden Commit so fokussiert und klein wie möglich zu halten. Sie müssen geduldig sein, eine Eigenschaft, die mir sicherlich fehlt, und entschlossen. Langsame, kleine Schritte während eines Refactoring-Projekts sind immer besser als ein einzelner großer, unkonzentrierter Pull Request mit Dutzenden von nicht zusammenhängenden Commits.
Wenn Ihnen während des Refactorings ein neues Problem mit dem CSS oder dem Design auffällt, dann eilen Sie nicht, es zu beheben, vertrauen Sie mir. Es wird eine Ablenkung sein. Konzentrieren Sie sich stattdessen auf die aktuelle Aufgabe. Sie können sich später immer noch um die andere Sache kümmern.
Tipp #4: Erzählen Sie jedem, dass Sie an diesem Projekt arbeiten
Das mag nur etwas sein, womit ich persönlich zu kämpfen habe, aber ich habe bis vor kurzem nicht erkannt, wie sehr Front-End-Entwicklung eine Gemeinschaftsanstrengung ist. Die eigentliche Schwierigkeit der Arbeit hängt nicht davon ab, ob man die schickste CSS-Technik kennt, sondern davon, wie bereit man ist, mit dem Rest seines Teams zu kommunizieren.
Erzählen Sie jedem, dass Sie an diesem Projekt arbeiten, um sicherzustellen, dass nichts übersehen wurde. Das Refactoring großer Codebasen kann zu Randfällen führen, die dann zu überwältigend schmerzhaften, kundenorientierten Problemen führen können. In unserem Fall, wenn ich das CSS vermasselt hätte, dann hätten möglicherweise Tausende von Menschen in dieser Woche nicht durch unsere App bezahlt werden können. Jede kleine Information kann Ihnen nur helfen, diesen Refactoring-Prozess so effizient und reibungslos wie möglich zu gestalten.
Tipp #5: Dokumentieren Sie so viel wie möglich
Ich wünschte wirklich, ich könnte das genaue Zitat finden, aber irgendwo tief in Ellen Ullmans ausgezeichnetem Buch Life in Code schreibt sie darüber, wie Programmieren so etwas wie eine schlechte Übersetzung eines Buches ist. Außerhalb der Codebasis haben wir Ideen, Gedanken, Wissen. Und wenn wir diese Ideen in Code umwandeln, geht etwas Unerklärliches für immer verloren, egal wie gut man im Programmieren ist.
Ein kleiner Tipp, der diesen Übersetzungsprozess unterstützt, ist das Schreiben von wirklich detaillierten Nachrichten in der Pull-Anfrage selbst. Warum tun Sie das? Wie gehen Sie dabei vor? Wie planen Sie zu testen, dass Ihr Refactoring nicht alles kaputt gemacht hat? Das sind genau die Informationen, die jemandem in Zukunft helfen werden, mehr über Ihre ursprüngliche Absicht und Ihre Ziele zu erfahren.
Zusammenfassung
Ich habe all das auf die wirklich harte, lange, dumme Art und Weise gelernt. Aber wenn Sie diese Tipps befolgen, werden große Front-End-Projekte mit Sicherheit viel reibungsloser verlaufen, sowohl für Sie als auch für Ihr Team. Ich garantiere es.
Die Code-Abdeckung funktioniert auf einer einzelnen Seite. Gibt es etwas, das auf einer ganzen Website funktioniert? Ich denke, es wäre einfach, etwas zu löschen, das auf einer bestimmten Seite nicht benötigt wird, aber anderswo auf einer Website benötigt wird.