Wir haben in letzter Zeit viel über das Refactoring von CSS geschrieben, von der Art und Weise, wie man einen langsamen und methodischen Ansatz verfolgt, bis hin zu schnellen Erfolgen. Infolgedessen habe ich viel über dieses Thema gelesen und bin irgendwie auf diesen Beitrag von Harry Roberts über das Refactoring gestoßen und wie man die damit verbundenen potenziellen Risiken mindern kann.
Refactoring kann beängstigend sein. Bei einer ausreichend großen oder veralteten Anwendung kann so viel grundlegend falsch an der Codebasis sein, dass viele Refactoring-Aufgaben sehr tief im gesamten Projekt liegen. Dies setzt Entwickler unter großen Druck, insbesondere angesichts der Tatsache, dass dies ihre Chance ist, „es dieses Mal richtig zu machen“. Dies kann lähmend wirken: „Wo fange ich an?“ „Wie lange wird das dauern?“ „Woher weiß ich, ob ich das Richtige tue?“
Harry kommt dann mit dieser Metapher eines Refactoring-Tunnels, in dem man sich leicht mitten im Refactoring wiederfindet und keinen Ausweg mehr hat. Er argumentiert, dass wir uns auf kleine, überschaubare Teile konzentrieren sollten, anstatt zu versuchen, alles auf einmal anzugehen.
Widerstehen Sie der Versuchung, alles zu refaktorisieren, was sich durch das gesamte Projekt zieht. Identifizieren Sie stattdessen kleinere und überschaubarere Aufgaben: Aufgaben mit einer viel kleineren Angriffsfläche und daher einem viel kürzeren Refactoring-Tunnel.
Diese Aufgaben können immer noch auf ein größeres und umfassenderes Ziel ausgerichtet sein, aber sie können in viel sichereren und kürzeren Zeiträumen realisiert werden. Möchten Sie alle Ihre Klassen von BEM auf BEM(IT) umstellen? Sicher, aber vielleicht implementieren Sie es zuerst nur in der Navigation.
Diese Vorgehensweise fühlt sich definitiv langsamer an, aber das damit verbundene Risiko ist so viel geringer.