Februar 2011

So Mo Di Mi Do Fr Sa
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28          

Schreib deinen Code, als würde er auf's CPAN kommen

Hm... Perl ist ja geradezu prädestiniert, um damit ein Programm schnell herunter zu hacken. Ganz üble Sachen: viel Logik auf einer Zeile und so. Zumindest wird Perl in diese Richtung geschoben. Denn man kann wirklich einiges sehr kurz halten, dabei kann der Perl-Code aber auch lesbar bleiben! Aber so tief will ich eigentlich gar nicht einsteigen, ich wollte eher die Qualität von Modulen ansprechen. Und die bestimmt sich nicht nur anhand des eigentlichen Codes.

Tests. Dokumentation der API. Probleme mit Abhängigkeiten. Schon mal mit diesen Dingen konfrontiert worden, wenn im eigenen Haus ein Perl-Modul entwickelt wurde und jemand anderes dieses für ein zweites Projekt einsetzen wollte? Oft gibt es vor allem Probleme, wenn ein Modul von anderen (CPAN-)Modulen abhängt. Sollte man die Abhängigkeiten übersehen und nicht von Hand aufgelöst haben, führt das zum Crash der Applikation. Bei vielen CGI-Scripts mag das noch schnell erkannt werden, da diese meistens (hoffentlich) nicht zu groß sind. Aber bei komplexeren Applikationen z.B. mit mod_perl und Catalyst (oder Jifty, oder MasonX::WebApp, oder...) sind solche Stellen schwieriger zu finden. Anders als bei z.B. Java wird die komplette Applikation nicht auf einmal kompiliert, sondern meistens erst dann, wenn die Programmteile benötigt und geladen werden.

Dabei ist das Problem mit den CPAN-Abhängigkeiten recht einfach zu lösen Würde man Module schreiben, als wenn sie auf dem CPAN publiziert werden, könnte man vielen Problemen aus dem Weg gehen und damit gleichzeitig die Qualität der Module durch Tests und automatisierte Installationen erhöhen. Abhängigkeiten können sehr einfach definiert und bei der Installation automatisiert in der neusten (oder benötigten/spezifizierten) Version installiert werden! Ebenfalls sind Tests einfach zu schreiben, und mit der Unterstützung der CPAN Toolchain können die Testergebnisse sehr einfach durch z.B. automatisierte Build-Prozesse ausgewerter werden. So können z.B. nur dann Perl-Module auf dem Server aktualisiert werden, wenn diese die Tests einwandfrei bestehen.

Viele denken nun, wie z.B. hier bei Perl Buzz zu lesen, ein Modul à la CPAN aufzubauen sei recht schwierig. Im Gegenteil, es gibt hierfür CPAN-Module, welche eine fast komplette Struktur für ein Modul quasi "per Knofdruck" anlegen. Dabei wird das Modul selbst (mit Beispielcode und -dokumentation), Testskripte, Manifest-Dateien, Build- bzw. Makefiles, etc angelegt.

Seit Jahren verwende ich dazu Module::Starter und komme damit sehr gut klar. Auch meine Perl-Module auf dem CPAN wurden damit errichtet.

Und so geht's (auf der Kommandozeile aufrufen):
$ cpan install Module::Starter
$ module-starter -mb --module=Mein::Test::Modul --author=Matthias\ Dietrich --email=perl@rainboxx.de
Damit wurde ein minimales Grundgerüst im Verzeichnis Mein-Test-Modul angelegt, in dem man sein Modul erstellen kann: ein beispielhaftes Modul wurde unter lib/Mein/Test/Modul.pm angelegt. Wichtig: das Flag -mb weist Module::Starter an, anstatt dem Standard ExtUtils::MakeMaker das Modul Module::Build zu verwenden (ich nutze dieses Flag aus historischen Gründen).

Hat man nun ebenfalls das Flag -mb angewendet, kann man nun innerhalb der Datei Build.PL im Hash unter requires die Abhängigkeiten definieren. Das sieht dann ungefähr so aus:

...

my $builder = Module::Build->new(

   module_name => 'Locale::Maketext::Lexicon::DBI',

   requires    => {

                   'Locale::Maketext::Lexicon' => 1.66,

                   'DBI'                       => 0,

                   'Test::More'                => 0,

                  },

...
Ein einziger Aufruf (im Verzeichnis Mein-Test-Modul reicht nun, die Abhängigkeiten des Moduls zu installieren, das Modul zu "builden", testen und es ebenfalls zu installieren:
$ sudo cpan .
Ich empfehle jedem Perl-Entwickler, sich diese Arbeitsweise ans Herz zu legen. Auch wenn es einfach aussieht ist es natürlich jedesmal ein kleines Stück mehr Arbeit, was aber vieles vereinfachen kann. Implementiert man sowieso Tests, kann man mit diesem Vorgehen auch gleichzeitig die entsprechenden Unit- bzw. Modul-Tests "am Modul selbst" implementieren und testen.

Weiter Informationen finden man auf dem CPAN. Perl Training Australia hat zu diesem Thema ebenfalls einen Artikel verfasst, und auch der Author des Moduls Module::Starter empfiehlt: Write your code like it's going on CPAN.

Viel Spaß beim Coden!

Kommentare 1 Kommentare

Danke für die ausführliche Darstellung! Ich kann die Vorgehensweise nur empfehlen - nicht nur, wenn man im Team arbeitet. Auch beim Rauskruschteln eigener alter Module hilft es ungemein, wenn man sich damals beim Strukturieren etwas Mühe gegeben hat.

Und wenn man so eine fertige Struktur schon hat, fällt es einem auch gleich viel leichter, noch schnell ein paar Tests dazuzuhacken. Test Driven Development macht süchtig :-)

Trackbacks 1 TrackBacks

Folgende Einträge anderer Blogs beziehen sich auf den Eintrag Schreib deinen Code, als würde er auf's CPAN kommen
TrackBack-URL dieses Eintrags: http://www.rainboxx.de/mt/mt-tb.cgi/43

Matthias schrieb den sehr empfehlenswerten Tipp: Schreib deinen Code, als würde er auf's CPAN kommen Dem kann ich mich nur anschließen. Auch wenn Code nur intern zum Einsatz kommt (was in der Praxis die Regel ist), sollte er stets nach... Mehr