Angebot zum Plugin-Review
03.09.2012 in: PHP, Webdesign und WordPress • 7 Kommentare
Mit David habe ich neulich darüber gescherzt, daß neben Open und Closed Source eine weitere Kategorie existiert, die vermutlich den größten Teil des bestehenden Codes ausmacht: Shamefully Hidden Source. Code also, den man lieber nicht zeigt, weil er nicht gut genug ist. Das ist okay. Ein Programmierer muß Fehler machen, und er muß auch bereit sein, eigenen Code zu verwerfen.
Heute bin ich auf diesen Video-Mitschnitt eines Vortrages von Douglas Crockford gestoßen:
Er hat den Vortrag letzten Monat in San Francisco auf der JAX Conference 2012 gehalten. Hier erklärt er, warum sein Tool JSLint tut, was es tut: Schlechten Stil aufspüren. So ist JavaScript beispielsweise eine der wenigen Sprachen, in denen Egyptian Brackets (oder K&R; style) tatsächlich besser sind als der Allman style.
Zufällig habe ich seit ein paar Tagen den Feed für die neuesten WordPress-Plugins abonniert. Manchmal sehe ich mir den Code an. Das ist kein Vergnügen. Neben ganz allgemeinen PHP-Fehlern, wie der Verschmutzung des globalen Namensraumes, sieht man hier auch, daß die Feinheiten der WordPress-API vielen Entwicklern nicht bewußt sind.
Ich weiß natürlich, daß es mehr schlechten als guten Code gibt und das Plugin-Verzeichnis – anders als die Themes – keinen Code-Review anbietet. Aber kann man sich den denn nicht woanders holen? Muß man alles, was scheinbar funktioniert, gleich als Plugin in Repository stellen? Viele Nutzer werden die Nachteile schlechten Codes erst bemerken, wenn es zu spät ist, wenn ihre Seite gehackt wurde oder ob der vielen unnützen Arbeit einfach hängt. An diesem Problem kranken übrigens auch viele der sogenannten »Premium-Themes« – deshalb fasse ich die grundsätzlich nicht mehr an.
Nun fällt das bloße Meckern unter not constructive, wie wir es auf WordPress Stack Exchange nennen.
Deshalb biete ich öffentliche Code-Reviews für Plugins an.
Und so funktioniert es:
- Du stellst dein Plugin in ein öffentliches Repository, damit ich Links auf einen bestimmten Code-Zustand setzen kann. GitHub eignet sich dafür sehr gut, es darf aber auch woanders sein.
- Du schreibst mir, daß du einen Review möchtest, und ich sage, ob und wann ich das machen möchte. Ich habe nicht gerade viel Zeit, daher werde ich vielleicht ablehnen müssen.
- Ich schreibe meinen Review. Wenn ich eine Sicherheitslücke finde, gebe ich dir privat Bescheid – und warte, bis du die repariert hast.
- Du bekommst zwei Tage vor der Publikation von mir eine Vorwarnung. :)
Das kostet sicher Überwindung – Crockford erklärt im Vortrag ganz gut, welche Rolle der Bauch hierbei spielt. Ich werde das berücksichtigen, meine Kritik also sachlich halten und Verbesserungen vorschlagen, nicht meckern oder dich gar bloßstellen.
Private Reviews für Plugins und Themes biete ich natürlich auch weiterhin an – dafür stelle ich eine Rechnung aus.
Großartiges Angebot; besser kann man nicht lernen als seine Ergebnisse öffentlich zur Schau zur stellen und aus der konstruktiven Kritik zu lernen.
Ich habe vor kurzem von einem Mitarbeiter von Mozilla eine Nachricht zu einer XSS Lücke in einem meiner Plugins bekommen. Im ersten Moment ist so etwas natürlich ärgerlich und peinlich, aber ich habe mich sehr über die Nachricht gefreut, denn ich hatte mich ehrlich gesagt so genau mit XSS noch nicht auseinandergesetzt.
Willst du nicht vielleicht dazu auch noch ne Session auf dem Camp halten? ;)
@Bernhard: Das können wir ja in der Knowledge-Base besprechen. Gerade beim Thema Sicherheit verschwinden die wirklich wichtigen Punkte oft hinter Security Theater, über das ich mich viel zu schnell aufrege. :)
@Thomas Scholz: Es gibt eine Session zum Absicherung von WordPress aus der Sicht für Benutzer. Zu dieser hatte ich schon eine ergänzende aus der Sicht von Entwicklern vorgeschlagen.
Ich würde die zur Not auch halten bzw. moderieren, aber der echte Experte bin ich eben auch nicht. Wenn du also noch Lust dazu hättest wäre das toll. Wir können auch gerne gemeinsam das ganze moderieren.
Vielleicht ist aber unter deinen Lesern auch jemand, der vielleicht selbst dazu sein Wissen mit den anderen Teilnehmern teilen möchte ;)
@Bernhard: Mal sehen, wie straff der Zeitplan wird. Das entscheide ich vor Ort.
Tolles Angebot! Gibt es eine Untergrenze von Code-Niveau, ab der du nur noch sagst „Komm, hier geht's zum VHS-Kurs“? Oder gibst du auch blutigen Plugin-Anfängern konkrete Hinweise mit?
Und die kostenpflichtige Version, darf ich mir darunter so etwas wie ein professioenlles Code-Lektorat vorstellen? Da würde ich wahrscheinlich bald mal auf dich zu kommen. Sich durch fremden (und mutmaßlich insuffizienten) Code zu wühlen bedarf ja schon einer gewissen Hingabe, ich kann das nur bewundern. ☺
@Caspar: Wenn ich an einem Code nichts loben kann, dann, bespreche ich ihn auch nicht öffentlich. Ich möchte niemanden bloßstellen, und ein Totalverriss würde andere nur abschrecken.
Bei einem bezahlten Review suche ich bei jeder verbesserungswürdigen Stelle nach einer konkreten Alternative; das kann ich natürlich hier im Blog nicht leisten. Und ich teste intensiver: Single- und Multisite-Installation, extrem eingeschränkte Schreibrechte, eventuell notwendige Endpoints, SQL-Injection,
wp-contentauf einer separaten Domain, User 1 ohne Adminrechte usw. Auch diese Punkte kann ich im öffentlichen Review nicht komplett abdecken; wenn sie mir ins Auge springen, spreche ich sie aber an.