Avatar

Ps0ke

Φίλιππος Στέφανος

Nocturnal Inclination

Nerdkram, Internethumor und der ganzen Rest.

Mein Workflow

Einleitung
Ich versuche in diesem Text mal meine Herangehensweise (oder meinenWorkflow wie man so schön sagt) bei einem neuen Projekt zu beschreiben. Als Beispiel nehme ich jetzt mal time(t)able, da ich dieses ja gerade erst fertig gestellt habe. Es ist ein Webservice zum Onlineverwalten des eigenen Stundenplans.
Dies soll kein Leitfaden, How-To oder Wie-lerne-ich-perfektes-Projektmangement-Ratgeber sein, sondern einfach nur beschreiben, wie ich persönlich arbeite. Ich bin auch kein Profi, aber vielleicht bekommt der Ein oder Andere ja ein bisschen Inspiration seinen eigenen Workflow zu verbessern. Wenn ihr selbst Tipps habt, wie man seine Produktivität steigern kann, schreibt sie doch in die Kommentare.

Die Idee
Am Anfang eines Projektes steht natürlich immer die Idee selbst. Ideen entstehen oft spontan oder aus einer bestimmten Not heraus. Wie und wann genau eine Idee entsteht, kann niemand so genau sagen, oft ist sie dann plötzlich einfach da. Trotzdem gibt es natürlich so etwas wie Inspiration. Twitter und verschiedene Blogs bieten einem eine riesige Auswahl an bereits bestehenden Werken, an denen man sich orientieren und inspirieren lassen kann. Ich empfehle jedoch sich gegebenenfalls vorher zu informieren, ob es eine Umsetzung bereits gibt, ob ihr Aussicht darauf habt, besser zu sein, oder ob eure Implementierung irgendwelche Vorteile hat, denn nur dann macht es auch Sinn, Arbeitszeit zu investieren. Für Programmierer bietet sich GitHub sowohl für Inspiration als auch als Suche für Bestehendes hervorragend an.
time(t)able entstand aus einer Not heraus. Wie ich es auf der Projectpage schon beschrieben habe, hatte ich lange Zeit meinen Stundenplan auf meiner Homepage in handgeschriebenem HTML und es war ein Krampf ihn bei Änderungen anzupassen. Irgendwann begannen Klassenkameraden damit, meinen Stundenplan mit zu benutzen und ich geriet immer mehr unter Druck, selbigen auch möglichst schnell auf den neusten Stand zu bringen. Irgendwann wurde mir das zu doof und da wir ja in der Oberstufe keine Klassen mehr haben, sondern jeder ein individuelles Kursprogramm wählt, beschloss ich, dass es so nicht mehr weiter gehen konnte. Ich habe mich gar nicht lang nach Alternativen umgesehen, sondern gleich beschlossen, es selbst in die Hand zu nehmen. Wozu kann man denn Programmieren?

Planung
Ein Projekt steht und fällt mit der grünlichen Planung. Man sollte sich immer vorher Gedanken machen, was man genau haben will, sich einen Plan zurecht legen und niemals einfach drauf los programmieren. Wenn man das tut, kommt am Ende vielleicht etwas Funktionierendes heraus, vielleicht sieht es auch noch halbwegs gelungen aus, aber auf alle Fälle wird es unter der Haube ein riesiges Chaos - es hat schon einen Grund, warum ich meine Blogsoftware für dieses Blog nicht released habe.
Ich beginne meistens damit, ein Brainstorming zu machen und alle Features, die ich gerne hätte, wild auf einen Zettel zu schreiben. Manche schreiben das gleich im Texteditor, ich bevorzuge jedoch den guten alten Block, da mir oft noch spontan (in der Schule) Dinge einfallen, und ich diese dann sofort notieren kann.
Dann suche ich mir die Features heraus, die für das funktionstüchtige Endprodukt unabdingbar sind, und vielleicht noch ein paar kleine Extras und setze mir diese als Ziel für das 1.0 Release, die anderen Dinge werden nach hinten verschoben, da man sein Erzeugnis auch irgendwann veröffentlichen und in meinem Fall auch dringend selbst benutzen will. Außerdem fallen mir während des Programmierens sowieso meistens noch genug Sachen ein, die ich noch unbedingt einbauen muss :) da ist es gut, den Mund für den Anfang nicht zu voll zu nehmen, damit man auch irgendwann fertig wird.
Ich habe bei anderen Projekten schon oft die Erfahrung gemacht, dass ich mir zu viel Vorgenommen hatte, dass Produkt dann nie fertig gestellt habe und ich am Ende keine Lust mehr auf das Projekt hatte. So war ich unglücklich, konnte das Produkt nie selbst benutzen und auch an keinen weiter geben. Davon hat also niemand etwas. Lieber ein bisschen bei der Featurereichhaltigkeit zurück stecken, dafür aber Irgendwann auch mal etwas releasen können und dann immer noch Lust haben, daran weiter zu bauen.
Nachdem ich also die wichtigsten Aspekte herausgestrichen habe, beginne ich (zumindest bei Webdesign) zuerst damit das Userinterface zu skizzieren. Auch hierfür nehme ich am liebsten Bleistift und Karopapier, die Feinversion vielleicht später noch einmal in Photoshop, aber meistens auch nur dann, wenn ich sowieso Grafiken brauche.


Während des Projekts liegen diese Skizzen meist wild auf meinem Schreibtisch herum, bis auf die Lücke für Tastatur und Maus. Oft stellt man fest, dass etwas, auch wenn man sich das noch so toll erdacht hatte, so einfach nicht funktioniert und muss umplanen, da ist es immer gut Bleistift, Radiergummi und einen Block griffbereit zu haben, denn das geht meistens viel schneller und einfacher, als aufwändige Photoshop Dokumente zu bearbeiten oder sich durch irgendeine Mockups-Leichtgemacht Applikation zu quälen. Nachdem das Projekt abgeschlossen ist, bzw. die Phase in der ich die Skizzen benötige abgeschlossen ist, sammle ich alle meine Homepage UI Skizzen in einer Mappe, um ggf. noch einmal darauf zurück greifen zu können.

Warum aber beginne ich gleich mit UI Skizzen? Es schafft einen guten Überblick darüber, was wirklich alles gebraucht wird, und in welche Untergruppen man die einzelnen Tasks einteilen kann und macht es so einfacher Arbeitsabschnitte zu definieren, aber dazu später mehr. Außerdem hat man so von Anfang an ein klar definiertes Bild von dem, was man eigentlich haben will, und muss sich nicht erst während es Programmierens damit auseinander setzen.
Dieser Punkt ist sehr wichtig für ein rundes Endergebnis! Viele Programmierer machen den Fehler, das Userinterface während des Programmierens zu designen und zu bauen. Doch während des Programmierens ist man nunmal ein Programmierer, denkt nicht meist nicht darüber nach, wie es am einfachsten zu benutzen, sondern wie es sich am einfachsten programmieren lässt. Es gibt keine Ausnahmen. Selbst ich bin so. Man steckt dann einfach so tief im Code, dass man die Usability einfach vergisst. Ich bin auch nicht der Einzige, der das sagt, das sagen viele, wenn nicht alle großen UI/UX Designer. Ich will hier auch gar nicht so groß einsteigen über UI Design, nur soviel wollte ich mal gesagt haben. Es ist immer eine gute Idee, das Userinterface zu designen, noch bevor man eine einzige Zeile Code schreibt. Dann hat man klare Angaben an die man sich halten muss. Natürlich stellt man hier und da fest, dass etwas so nicht funktionieren wird, oder benutzt das Endprodukt und bemerkt dann, dass es doch keine gute Idee war dies und jenes so zu machen, aber besser als einfach so drauf los zu schreiben ist es alle mal. An dieser Stelle möchte ich noch einmal auf ein Usabilityblog hinweisen, das von einem UI Designer namens Lukas Mathis geschrieben wird und passend zu dieser Problematik Ignore The Code heißt.
Nun ist der Zeitpunkt gekommen sich über Programmiertechnische Belange Gedanken zu machen, wie etwa Datenbanken, 3rd-Party-Bibliotheken oder Ordnerstrukturen. Auch dies notiere ich mir old-school mit Stift und Papier.

Projektvorbereitung
Erst wenn das Grundkonzept steht, beginne ich überhaupt den Computer zu benutzen. Ich beginne damit, das Projekt vorzubereiten, sodass ich dann sofort anfangen kann, zu Programmieren, ohne mich um organisatorisches kümmern zu müssen.
Das fängt damit an, ein 'Project' in meiner GTD oder To-Do Applikation Things zu erstellen. Things ist sehr teuer und es gibt sehr gute kostenlose Alternativen wie z.B. Wunderlist, allerdings empfehle ich dringend eine GTD App zu nutzen, da nach meiner Erfahrungen einfache Texteditorlisten schnell unübersichtlich werden. Dann trage ich all die Punkte ein, die ich mir damals beim Brainstorming notiert hatte und verstecke diejenigen, die nicht als essentiell markiert sind mit der 'Someday'-Funktion. Danach sortiere ich die Übrigen Tasks der Reihenfolge nach, in der es Sinn macht diese abzuschließen, da oft vieles auf einander aufbaut. Wenn das Projekt seine 1.0 erreicht hat, kann ich die anderen Tasks wieder hervor holen und mich um Updates kümment, aber so ist erstmal alles überflüssige aus den Augen. Es ist häufig nützlich alle Tasks zu taggen, da ich persönlich oft Lust auf eine bestimmte Art Arbeit habe und so schnell etwas dieser Kategorie finde, dass ich noch erledigen muss.

Als nächstes lege ich mir meine Ordnerstruktur an, wie ich sie mir vorher schon zurecht gelegt habe und gehe meist nach einem bestimmten Muster vor. Webdesignprojekte benötigen fast immer eine index.php oder index.html, einen js und einen img Ornder. Systemprogramme haben fast immer eine main.c, einen includes Ordner mit includes.h, einen build Ornder und so weiter. Ich benutze zum anlegen der Ordner und Dateien meist das Terminal mit touch und mkdir, da dies oft viel schneller geht, als den Finder oder einen Texteditor zu bemühen.

Daraufhin erstelle ich eine Projektdatei für meinen Texteditor Textmate und füge alle Dateien hinzu. Ab jetzt benötige ich den Finder eigentlich gar nicht mehr, sondern manage alles in meinem Texteditor. Auch dieser ist wieder sehr teuer und es gibt kostenlose Alternativen, allerdings werde mich davor hüten irgendeine Empfehlung abzugeben, denn ich will hier keinenEditor War vom Zaun brechen.

Nun initiiere ich ein git Repository, lege eine provisorische README und eine .gitignore an und commite den leeren Stand in das Repository. Ich werde hier nicht anfangen, Version Control zu erklären, aber kann es nur empfehlen, sich damit zu befassen. Ob man jetzt git, CVS, SVN oder irgendetwas anderes nimmt, bleibt einem selbst überlassen ich finde git allerdings besonders praktisch wegen der Integration mit GitHub. Dort kann man sein Repository hin pushen und GitHub hostet bequem all euere Sources. Es kann noch viel mehr, ich will jetzt aber auch nicht anfangen, GitHub zu erklären. Das ist jedenfalls der nächste Punkt: Auf GitHub ein neues Repository anlegen und den ersten commit pushen.

Jetzt starte ich meinen lokalen Web- und MySQL-Server und lege mir die entsprechenden Datenbanken an. Ganz bequem kann man das mit einem Softwarepacket namens XAMPP tun, das alle benötigte Software mitbringt, installiert und einrichtet. phpMyAdmin zum bequemen MySQL bearbeiten ist auch dabei.


Programmieren
Erst wenn all das getan ist, beginne ich, Code zu schreiben. Und ab jetzt kann ich mich bis zum Ende fast ausschließlich darauf konzentrieren Code zu schreiben, das bringt einen ungeheuren Gewinn an Konzentration mit sich. Wenn ich ausnahmsweise mal vor Anbruch der Dunkelheit das Programmieren beginne, schalte ich für gewöhnlich alle Instant-Messaging und Social-Media-Dienste wie Skype, ICQ, Jabber und Twitter aus. Anders kann ich mich einfach nicht konzentrieren. Ich sage dann immer, das Internet sei zu laut. Das ist auch der Hauptgrund warum ich normalerweise Nachts programmiere. Ich bin auch generell so ein Nachtmensch. Meine Arbeitsweise hat sich dementsprechend auf die dunkle Tageszeit angepasst. In meinem Editor benutze ich ausschließlich 'Weiß-auf-Schwarz'-Color-Schemes, wie jeder Programmierer hat man da seinen Lieblingsscheme und bei mir ist das eben 'Twilight'.

Auch mein Terminal ist auf 'Grün-auf-Schwarz' eingestellt um die Augen zu schonen. Ein weiteres kleines Tool, dass ich sehr lieb gewonnen habe ist f.lux welches die Lichttemperatur des Bildschirminhalts mit der Zeit immer wärmer dreht, sodass bei einem bei Dunkelheit die Augen nicht so brennen, wenn man mal eine weiße Dokumentationsseite aufruft.Wenn ich Nachts arbeite, kann ich Instant-Messaging auch an lassen, weil dann sowieso die meisten Offline sind und das für eine kurze Pause sehr angenehm ist. Ich kann auch generell empfehlen, ab und zu Pausen einzulegen wenn man mit einem Aufgabenblock fertig ist, um die Konzentrationsfähigkeit wieder aufzubessern.
Wenn ich so ganz allein vor meinem Rechner sitze und vor mich hin programmiere, habe ich sehr oft das Bedürfnis nach Hintergrundmusik, die einen ein bisschen umspielt, aber nicht ablenkt, weil man den Text auswendig mitsingt, versucht ihn zu verstehen oder die Melodie einen Mitreißt. Deshalb habe ich mir eine 'Non Disturbing Music' Playlist angelegt, die ich dann rauf und runter höre und deren Titel mittlerweile die meistgespieltesten meinter Mediathek sind. Zur guten Musikauswahl für diese Zwecke zählen bei mir: Paul Kalkbrenner, Daft Punk Tron Soundtrack, MEZ, UNKLE, die Windows XP Installations Musik und ein paar andere.

Grundsätzlich beginne ich immer damit, das Userinterface erst einmal in purem HTML nach zu bauen, damit die spätere Umsetzung leichter fällt. Generell arbeite ich mich von oben nach unten durch. Ich beginnge beim Userinterface, mache dann die einfach Accountinteraction wie Login/Logout, Registrierung und Löschung und gehe dann tiefer zu den Hauptprogrammbestantteilen. Dadurch hat man schnell einen funktionierenden Prototypen an der Hand und kann frühzeitig erkennen, ob die Idee so wie gedacht aufgeht, oder ob man komplett umdenken muss, ohne dass viel Zeit in das schreiben von Hardcorecode geflossen ist.
Jetzt aber genug des Meta-Geschwafels, wie programmiere ich denn nun? Da gibt es jetzt eigentlich gar keine so richtige Antwort drauf. Ein typischer Arbeitsablauf wäre in etwa so:
Zuerst suche ich mir in Things den nächsten Task aus, der erledigt werden muss. Dann schau ich im Terminal mit git status nach, welche Änderungen noch nicht commitet sind und wo ich also weiter arbeiten muss. Je nach Komplexität greife ich mir auch gerne einen Notizzettel und schreibe mir einen Grobverlauf auf um besser koordinieren zu können, was ich noch tun muss.

Danach nehme ich mir meinen Editor zur Hand und fange an zu schreiben. Mit Apache habe ich immer einen lokalen Webserver laufen und überprüfe meine Ergebnisse im Webbrowser. Dafür nehme ich als Hauptbrowser Firefox mit Webdeveloper, Useragentswitcher und Firebug als Addons - ansonsten unmodifiziert. Ich habe dafür extra ein gesondertes Profile angelegt, denn wenn man Firefox mit dem Argument -p startet, bekommt man einen Dialog zum wechseln der Profile. Mein Webkitbrowser ist Chromium. Ist ein Funktionierender Schnippsel fertig geschrieben, mache ich einen git commit und wenn ich einige commits gesammelt habe, pushe ich diese hoch auf GitHub, manchmal auch erst, bevor ich den Computer ausschalte. Wenn ich einen neuen Task beginne, lege ich immer einen neuen branch an, um den stable channel meines source repos nicht zu gefährden und wenn ein Task abgeschlossen ist, merge ich diesen wieder zurück in master. Dann Hake ich den Task in Things ab und widme mich dem nächsten. Von Zeit zu Zeit lasse ich Familienangehörige oder Freunde mal drüber schauen, ob mein Konzept so aufgeht, wie geplant, denn wenn man zu lange in seinem Projekt verbissen arbeitet, fallen einem viele Fehler, vor allem beim UI Design gar nicht mehr auf.

Publizieren
Am Ende muss man ein fertiges Projekt ja auch publizieren. Zuerst kommen aber noch die abschliessenden Schritte der Projektverwaltung. Am Ende gehe ich alle Szenarien, die ich mir ausdenken kann noch einmal durch, und schaue ob die Lokalisierung überall passt, keine Fehlermeldungen auftreten und ob alles verständlich Erklärt wird, überhaupt ob alle Funktionen auch mit Sonderzeichen etc. funktionieren. Das kann schonmal Stunden dauern, wenn man viele Winkel in einem Projekt hat. Ich habe dann meine time(t)abel Projekt damit abgeschlossen, einen einfachen Installer zu schreiben, damit auch andere es einfach haben, time(t)able aufzusetzen, aber in erster Linie, weil ich selbst keinen Bock hatte, nochmal die Datenbanken genau so hin zu basteln, alle Strings richtig zu setzen etc.
Als nächstes habe ich die Readme Datei noch einmal ausführlich überarbeite. Dann einen finalen commit gemacht und diesen mit der Version 'v1.0' getagged und alles gen GitHub gepushed. Ich benutze Markdown um das Readme mit allen nötigen Informationen auch in GitHub schön darzustellen. Der größte Vorteil von Markdown ist aber, dass man daraus ganz einfach schönes HTML generieren kann, dass ich dann für meine Projectpage benutzen kann.
Dann habe ich mit dem eigentlichen Releasen begonnen und eben jene erzeugte Projectpage hochgeladen und die entsprechenden Links auf den Seiten gesetzt. Dann habe ich den eigentlichen Projektcode hochgeladen und den Installer benutzt um es zu installieren. Alles noch einmal durchchecken und dann noch schnell die Subdomain setzen und fertig.
Zum krönenden Abschluss noch ein Werbebanner auf der Startseite einblenden und einen völlig verschlafenen Blogpost um 5:40 schreiben und ein bisschen Publicity über Facebook und Twitter machen und dann ist es endlich geschafft.
Ach ja, noch schnell beim eigenen Service registrieren um sich die ID 1 zu sichern. Dann ab ins Bett.
Ja so läuft das öfters bei mir, aber das Gefühl nach getaner Arbeit totmüde ins Bett zu fallen, wenn die Sonne gerade aufgeht, aber zu wissen, dass man echt etwas geschaffen hat, ist wunderbar.