Montag, 21. Januar 2013

Das 1. Softwareprojekt: ein paar Erfahrungen

Anfang Dezember 2012 habe ich mich dazu entschieden, mein erstes Softwareprojekt zu starten, welches ich der Öffentlichkeit zugänglich mache. Zwar habe ich vorher schon ein paar "mittelgroße" Sachen programmiert, das sind aber alles Webapplikation, welche im Intranet der Firma laufen und das Arbeitsleben für meine Kollegen und mich vereinfachen.

Das neue Projekt Namens "pygcstats" ist zwar öffentlich, ist aber nur nützlich für Leute, welche Geocaching betreiben, bei geocaching.com registriert sind und dort einen Premium-Account haben (sonst kommt man nicht an die Daten, die pygcstats auswertet). Gut, das sind weltweit geschätzt ca. immer noch 3 - 3,5 Millionen potentielle Nutzer... Programmiersprache der Wahl ist wie immer bei mir Python.

Aber um das Programm an sich geht es gar nicht, sondern eher, was ich bis jetzt bei dem Projekt generell gelernt habe:
  • Nutze ein Versionskontrollsystem: Zu Beginn habe ich noch ohne programmiert, aber spätestens dann, wenn man veröffentlichen will und ggf. zusätzlich zum Release einen Entwicklungszweig hat, kommt man nicht ohne aus. Und auch wenn moderne VCS nicht wirklich schwer zu verstehen braucht es ein bisschen Einarbeitungszeit. Besonders dann, wenn man zum ersten Mal einen Branch erstellen, nutzen und veröffentlichen will. In meinem Fall bestand das "learning by doing" zum Glück "nur" aus einem falsch ausgeführten Push ins Repositry auf Launchpad. Der ließ sich aber problemlos rückgängig machen.
  • Beschäftige dich mit der Plattform, die den Code hostet: Wie weiter oben bereits erwähnt nutze ich Launchpad als Plattform und Bazaar als VCS. Aus zwei ziemlich platten Gründen: Zum einem, weil ich eh' einen Account bei launchpad.net habe, zum anderen, weil ich die Doku im Wiki bei ubuntuusers.de zu Bazaar ziemlich kompakt und gut verständlich finde. Was auch schön ist: bei Launchpad kann man ziemlich viel über die Weboberfläche konfigurieren. Aber: auch das kostet Zeit, besonders am Anfang, wenn man noch nicht weiß, wo was ist. Inzwischen geht alles ganz flüssig.
  • Doku schreiben kostet Zeit: gute Software mit schlechter Doku (oder keiner Doku) ist keine gute Software. Von daher habe ich von Anfang an Wert auf Doku gelegt. Sowohl in Form von Anleitungen für die Nutzer als auch in Form von Docstrings im Quelltext. Einen großen Teil der Nutzerdoku habe ich erst in Englisch und dann noch in Deutsch geschrieben. Ich habe zwar nicht die Zeit genau gemessen, aber ich würde schätzen, dass mindestens 1/3 der Gesamtarbeitszeit des Projekts bis jetzt für Dokumentation aufgewendet wurde.
  • Halte dich von Anfang an an die PEP8: Die PEP8 ist der allgemein akzeptierte Code Style Guide für Python. Dieser war mir zwar geläufig, aber nicht in allen Details. Na ja, jedenfalls waren die ersten Ausgaben des PEP8 Checkers für meinen Code ziemlich lang, was die Fehler anging. Der größte Teil waren Leerzeichen in Leerzeilen oder am Zeilenende. Nicht tragisch, aber trotzdem kostet es Zeit, diese alle zu eliminieren. Also lieber direkt beim coden darauf achten direkt löschen bzw. erst gar keine "entstehen" lassen.
Rückblickend würde ich zwar nicht sagen, dass ich etwas wirklich falsch gemacht habe, aber man hätte Sachen besser machen können. In erster Linie wäre das, sich vorab mit der Plattform und dem VCS seiner Wahl zu beschäftigen. Dann hat man im laufenden Projekt mehr Zeit, auf die Programmierung und das Testen zu fokusieren.
Und, der Tipp / Hinweis an alle: unterschätzt nicht den Zeitaufwand, den eine gute / ausführliche Doku braucht.

Ach ja: den ersten "öffentlichen" Release der Software gab's übrigens vor ein paar Tagen.

6 Kommentare:

  1. Eben weil das mit der Doku so viel Zeit benötigt, wird in Projekten vielfach sehr wenig dokumentiert. Hinzu kommt, dass dokumentieren für Programmierer häufig eine äußerst unbeliebte Tätigkeit ist.

    AntwortenLöschen
  2. Danke für das Posting, sehr interessant! Vermutlich werde ich aber nie in die Lage kommen diese Library in Anspruch zu nehmen denn in dem Bereicht arbeite ich nicht.
    Hast Du daran gedacht hast die Library per PIP verfügbar zu machen und falls nicht warum nicht?

    AntwortenLöschen
    Antworten
    1. Aktuell ist es nicht geplant, aber vielleicht irgendwann mal. Der Grund für "keine Eile" ist, dass die ganzen selbstgeschriebenen Python-Module von pygcstats genau für diesen Einsatz optimiert sind und abgesehen davon keinen Nutzen haben. Weshalb auch keine systemweite Installation nötig ist. Lokal entpacken reicht.

      Löschen
  3. Wenn du pep8 nutzt, dann ist autopep8 (http://pypi.python.org/pypi/autopep8) sicher interessant für dich! Autopep8 formatiert deinen Code automatisch nach den pep8-Vorgaben.

    Ich nutze es meist mit den Optionen -i (ändert die Datei direkt) und -v (zeigt an, wo Verstöße gegen pep8 existieren und welche Änderungen nicht durchgeführt werden).

    AntwortenLöschen
  4. Danke für den Tipp - werde ich bei Gelegenheit mal testen :-)
    Wobei: nachdem ich "direkt von Anfang an diszipliniert Programmieren" gewechselt bin klappt auch die PEP8 Konformität ganz gut ;-)

    AntwortenLöschen
  5. das sich vorher mit dem Werkzeug zu beschäftigen ist sicher eine gut Idee, bringt in der Praxis nicht viel. Fehlt es doch oft an der Zeit sich nebenbei damit zu beschäftigen und in der Freizeit will man manchmal auch noch was anderes machen. Wirklich hängen bleibt auch nur das, was man tatsäschlich benötigt. Ein kleines unbedeutendes "Bastelprojekt" kann aber schon zum Einstieg helfen.

    Die Dokumentation sehe ich nicht als separaten Zeitaufwand, das gehört einfach dazu. Eine vollständige Benutzerdokumentation, kann aber auch schon mal komplett in ein eigenständiges Projekt ausarten. Der gesamte Prozess des Programmierens besteht aus vielen kleinen Dingen, das coden selbst macht wohl nur 10-20% der eigentlichen Arbeit aus.

    AntwortenLöschen