In der vergangenen Woche habe ich Refactoring von Martin Fowler gelesen, und es geht darum, wie man umfangreiche Änderungen an einer großen Codebasis vornimmt, ohne dass alles zusammenbricht. Ich erwähne das, weil in diesem Buch viele wirklich gute Notizen enthalten sind, die meinen jüngsten Ansatz zur Überprüfung und Refaktorierung einer Menge CSS in Frage gestellt haben. Viele der Ratschläge sind klein, irgendwie offensichtlich, aber ich habe festgestellt, dass ich in letzter Zeit faul war, wenn es darum ging, wie viele dieser kleinen, offensichtlichen Dinge ich bei Projekten wie diesem abtat.
Martin schreibt
…wenn ich das Problem nicht sofort erkennen und beheben kann, kehre ich zu meinem letzten funktionierenden Commit zurück und mache das, was ich gerade getan habe, in kleineren Schritten wieder. Das funktioniert, weil ich so oft committe und weil kleine Schritte der Schlüssel sind, um schnell voranzukommen, besonders wenn man mit schwierigem Code arbeitet.
Also: häufig committen und nur eine Sache in diesem Commit tun. Darüber hinaus testen Sie diese Änderungen ständig, während Sie codieren.
Das andere, dessen ich mir dank dieses Buches bewusster geworden bin, ist, dass Commit-Nachrichten kostbare Dinge sind, weil sie anderen helfen, die Bedeutung von geänderter Arbeit zu verstehen. Wir alle haben scheinbar einfache Commit-Nachrichten gesehen, wie z.B. "Typografie refaktoriert", die sich als Tausende von Zeilen lang herausstellen und wir rollen mit den Augen. Das schreit geradezu nach Fehlern und visuellen Regressionen. Kleinere Commits sollten verhindern, dass so etwas jemals passiert. Eine gute Reihe von Commit-Nachrichten sollte sich anfühlen, als ob man mit jemandem zusammenarbeitet, als ob man ihn Schritt für Schritt durch die Änderungen führt.
Obwohl ich darin besser werde, finde ich diese Arbeitsweise außerordentlich schwierig, weil sie sich langsamer anfühlt als weitreichende Änderungen und Hoffen auf das Beste. In seinem Buch ermutigt uns Martin, dieses Gefühl zu überwinden. Wenn wir große Teile unserer Codebasis refaktorieren, argumentiert er, sollten wir immer langsam und stetig, geduldig und diszipliniert sein.
Würden Sie das Buch generell empfehlen? Wie wäre es für jemanden, der den Großteil seiner Geschäftslogik in PHP schreibt?
Refactoring 2. Auflage hat JavaScript-Beispiele, aber die vorgestellten Prinzipien sind universell. Es ist einer meiner wertvollsten Besitztümer. Es hat mir geholfen, besseres JavaScript, CSS, Java usw. zu schreiben.
Das sind gute Ratschläge: in kleinen Schritten committen. Das sind gute Ratschläge nicht nur für Refactoring, sondern auch für den Aufbau großer, komplexer Features. Ich verfalle oft in die Falle, nicht oft genug zu committen, aber es braucht nur einen Vorfall, bei dem man ein paar Stunden Arbeit verliert, um zu erkennen, dass langsam und stetig der richtige Weg ist.