…gefällt mir erstmal nicht wegen seiner Funktionalität, sondern wegen einer solchen Zusammenfassung:
Das sind die hinzugefügten und entfernten Codezeilen, es wurde also viel mehr Code gelöscht als hinzugefügt. Was die Zusammenfassung nicht verrät: In diesem Fall wurde nichtmal Funktionalität entfernt!
Die Statistik ist aus diesem PR, ein Update für das altehrwürdige Usergallery-Plugin für die Blogsoftware Serendipity. Betonung liegt dabei auf alt, der PR entfernt unter anderem einen Sonderfall für die Nutzung unter PHP 4 (offizielles Supportende: 2008). Das war aber nicht die große Codeeinsparung, sondern die stammt aus der Entfernung einer gebündelten Library namens JPEG_TOOLKIT zum Auslesen von Exif-Tags. Die konnte mit einer Funktion aus Serendipitys Kern ersetzt werden, serendipity_getMetaData
, die wiederum auf normalerweise einkompilierte PHP-Funktionen wie iptcparse
und exif_read_data
zurückgreift.
Völlig ohne sichtbare Änderung ging das zwar nicht, serendipity_getMetaData
gibt eine leicht andere Auswahl an Metadaten zurück. Und die Keys des zurückgegebenen Arrays sind auch teilweise anders, wodurch die Konfiguration zurückgesetzt werden musste (was ein paar der neuen Codezeilen erkennen und umsetzen). Doch das war es in meinen Augen definitiv wert, vor allem wenn man bedenkt, dass das JPEG_TOOLKIT unter PHP 8 (und möglicherweise auch früheren Versionen) nicht nur nicht funktionierte, sondern sogar kritische Fehler warf. Das halte ich auch meinem Gedanken entgegen, dass gebündelter Code nicht wirklich zählt: Oft stimmt das, wird er doch in einem anderen Projekt gepflegt. Aber hier wäre der Code von uns zu pflegen gewesen, da das Ursprungsprojekt nicht mehr aktiv zu sein scheint. Für mich zählt es dann doch.
Ich sehe sowas als Paradebeispiel für einen PR, wie ich ihn bei der Wartung im Idealfall anstreben will: Viel Code wurde entfernt, die Funktionalität dabei bewahrt. Diese Sichtweise sollte universell sein und kommt mir beim Aufschreiben trivial vor, aber man darf nicht vergessen: Das ist sie nicht. Berichte über Manager, die Entwickler nach Codezeilen bewerten wollen, findet man immer noch immer wieder. Insbesondere, wenn wie bei der Überarbeitung des Bayesplugins sogar Funktionalität entfernt wird – zugunsten simpleren und wartbaren Code sowie einer klareren Bedienung – ist Verständnis nicht gesetzt. Und es ist ja auch eine Besonderheit der Programmierung, dass ein scheinbar geringeres Arbeitsergebnis letztendlich besser sein kann.
Der PR oben ist übrigens nur als Beispiel gemeint für diese Art von Codeänderungen, er ist nicht direkt mein Favorit. Ich erinnere mich an andere, bei denen ich an die hunderttausend Codezeilen entfernen konnte. Leider war das in einem privaten Repository.
- Kürzliche Entwicklungen bei Serendipity
- Lazytube 1.1.0: Leichtere Youtube-Embeds nun per Spartacus und mit Vorschaubild-Proxy
- Socialplugin 1.0: Die Variante ohne Shariff, oder neue Sharebuttons für Serendipity
- 15 Jahre Serendipity als Entwickler - ein Rückblick und ein Ausblick
- Serendipity 2.5-beta1