Du sollst deine Arbeit dokumentieren

Von Karim Geiger — unter Development am 16.12.2016

Ich bin noch nicht sehr alt. Trotzdem habe ich eine wichtige Erfahrung in meinem Leben gemacht, welche meiner Meinung nach elementar für die berufliche Karriere als Informatiker ist.

Egal, ob du ein Entwickler, Sysadmin oder Supporter bist, dieser simple Tipp wird dein Leben verändern. Hier erfährst du ihn!

Entschuldigung. Das klang vielleicht etwas Clickbaitiger als gedacht. Aber nunja, es ist ein einfacher Trick, wie man sich das Leben und die berufliche Laufbahn einfacher gestalten kann: Dokumentiert, was ihr getan habt.

That’s it. Danke fürs Lesen.


 

Ich denke ich muss nicht viel über Dokumentation sagen. Jeder ITler hat seine eigene Meinung dazu entwickelt. Manche lieben Dokumentation, die meisten aber hassen sie. Es macht keinen Spaß sie zu erstellen, durchlesen wird sie sowieso keiner und in drei Monaten ist sie sowieso wieder veraltet. Warum also überhaupt damit anfangen? Absolut verschwendete Zeit.

Eben nicht.

Dokumentation ist wichtig. Ich sage das nicht aus Manager- oder Sales-Sicht, sondern aus der Engineering-Perspektive. Warum du dokumentieren solltest? Weil du dir nicht alles merken kannst. Du dokumentierst nicht für andere. Du dokumentierst nicht, um dich später einmal ersetzbar zu machen, sondern du dokumentierst, damit du später weißt, was du da genau getan hast. Und das wirst du früher oder später wissen müssen:

  • Wenn du im Support arbeitest und dokumentierst, wie du den Drucker eingerichtet hast, und welche Probleme es dabei gab, wirst du es dir in zwei Monaten, wenn du ihn nochmal einrichten musst, danken.
  • Wenn du Sysadmin bist und in einem halben Jahr einen zweiten Cluster-Server aufsetzen sollst, wirst du es dir danken, wenn du alles dokumentiert hast. Auch, wenn du das Deployment automatisiert hast.
  • Wenn du Entwickler bist und in einem Jahr ein komplexes System erweitern musst, welches du selbst entwickelt hast, wirst du es dir danken.

Auch, wenn du im Moment ganz genau weißt, wie das, was du dokumentieren würdest, funktioniert, dann dokumentiere es trotzdem. Alleine aus zwei Gründen: Offensichtlich vergisst man Details. Und Details sind im Job des Informatikers ungeheuer wichtig. Aber auch das eigene Verständnis der Materie wird besser, während du dokumentierst. Es ist ein Unterschied, ob du nur Gedanken in deinem Kopf hast, oder ob du sie sortiert, strukturiert und organisiert niederschreibst. Kennst du das, wenn du versucht etwas zu schreiben, du es aber nicht so wiedergeben kannst, wie du es im Kopf hast? Das liegt daran, dass Kopf und Papier zwei unterschiedliche Dinge sind. Der Kopf kann Zusammenhänge ohne dass wir es merken auflösen. Schreiben wir sie nieder, wird erst ersichtlich, dass an dieser Stelle ein Zusammenhang – und damit eventuell Klärungsbedarf – besteht.

Hab außerdem keine Angst, dass Dokumentation dich ersetzbar macht. Ich habe noch niemanden gesehen, der entlassen wurde, weil er dafür gesorgt hat, dass jemand anderes seinen Job machen kann. Und selbst wenn du deswegen entlassen wirst, wärst du in dieser Firma nicht glücklich geworden. Außerdem ist es in der IT-Branche wirklich keine Kunst einen Job zu bekommen. Zudem werden Menschen, die dokumentieren in der Regel nicht entlassen, sondern vielmehr befördert, da sie dafür sorgen, dass die gesamte Firma davon profitiert.

Kommen wir zum vorletzten Punkt: Wie schaffe ich es, dass meine Dokumentation nicht veraltet? Nun, du musst sie natürlich pflegen. Dokumentation wächst. Mit jedem Problem kommen neue Lösungen hinzu, und genauso muss nach jeder Änderung die Dokumentation angepasst werden. Das mag zu Anfang aufwendig sein, aber schon bald hast du das Schreiben der Dokumentation in deinen Workflow mit aufgenommen. Und das kann sogar Spaß machen.

Mir persönlich macht das Schreiben von Dokumentation in der Tat Spaß. Ich würde es nicht den ganzen Tag tun wollen, aber es ist zum einen eine nette Abwechslung zum IT-Alltag, hilft die Gedanken zu sortieren und zeigt am Ende, was man geschafft hat. Nach dem Schreiben oder Pflegen einer Dokumentation sieht man nämlich sofort das Resultat. Man sieht das fertige Dokument, aber auch die dokumentierte Arbeit. Man sieht, dass man etwas geleistet hat, und hat es für die Ewigkeit festgehalten.

Und hier folgt der letzte Punkt: Warum ist mir Dokumentation so wichtig?

Ganz einfach, weil es die Arbeitsweise wiederspiegelt. Es macht keinen Spaß mit jemandem zu arbeiten, dem seine Arbeit nicht wichtig ist. Ein für mich absolut abstoßendes Zitat ist:

I throw together things until it works then I move on.

Genau das ist der Grund, warum es so viele Probleme in der IT gibt. Kein Architekt geht hin, entwirft ein Haus, das bei Optimalbedingungen stehen bleibt, und geht wieder. In der IT ist das gang und gäbe. “Hauptsache es läuft”, könnten sich einige aufs T-Shirt drucken. Und damit machen sie nur Probleme. Es mag auf kurze Sicht funktionieren und den größten Profit für einen selbst bringen, ist aber einfach nur asozial. Außerdem versalzt man sich auf lange Sicht selbst die Suppe.

Deswegen: Dokumentiere deine Arbeit. Wenn du daran Freude hast, kannst du stolz auf dich sein. Wenn die Dokumentation so komplex ist, dass du selbst beim Schreiben Probleme hast, setz dich hin und mach das, was du gerade versucht zu dokumentieren, erneut. Nichts muss auf Anhieb richtig sein. Aber mit der Zeit wird es immer besser. Und das sollte unser aller Ziel sein.

Produkt oder Code?

Von Karim Geiger — unter Development am 04.12.2016

Es gibt zwei Entwickler-Typen. Die, die versuchen ihren Programmcode möglichst strukturiert und sauber aufzubauen und die, die möglichst schnell versuchen ein Produkt zu veröffentlichen. Man könnte sie also durch die folgende Frage definieren:

Ist dir das Produkt wichtiger, oder der Code?

Wem das Produkt wichtiger ist, der sieht das Programmieren selbst nur als Mittel zum Zweck. Der Entwickler kümmert sich nicht um Objektorientierung, Designpatterns, Testing und Ähnliches. Der Entwickler schreibt einfach seinen Code Zeile für Zeile herunter, packt ein paar Funktionen darum und nennt es dann Functional Programming. Am Ende kommt ein Produkt heraus, das mehr oder weniger gut funktioniert, dafür aber sehr viele Features bietet und vor allem in kürzester Zeit entstanden ist. Der Vorteil ist klar: Quantität.

Wer Wert auf guten Code legt, denkt bei jeder Zeile, die er schreibt, meist zweimal nach. Er formatiert um und strukturiert das Programm so, dass es auch in Zukunft einfach erweitert und gewartet werden kann. Er schreibt Tests und sorgt dafür, dass alle Features so funktionieren, wie sie sollen. Aber all das kostet Zeit, was zur Folge hat, dass das Produkt am Ende länger braucht und mit weniger Features auskommt. Für diesen Typ zählt also Qualität.

Was bist du?

Stell dir bitte einmal die Frage, in welche Kategorie du dich einordnen würdest. Ich selbst habe in meiner Entwicklerkarriere beide Typen durchlebt. Angefangen habe ich – wie so viele – mit einfachen PHP-Scripts. Ich hatte keine Ahnung was Objekte sind, ich wusste nicht einmal wirklich wie Funktionen funktionieren und habe mir so das Skripten mit PHP beigebracht. Meine ersten Projekte sind entstanden. Von Sicherheit, OOP, TDD, usw. hatte ich keine Ahnung, aber meine Produkte hatten viele Features und mit den Problemen bin ich irgendwie klargekommen.

Diese Produkte sind übrigens die erfolgreichsten Produkte gewesen.

Dank Ausbildung und Selbstlernen ist mir mittlerweile der Code wichtiger. Das soll nicht heißen, dass mir das Produkt egal geworden ist. Im Gegenteil. Man könnte sagen das Produkt ist mir so wichtig, dass mir auch die Basis – der Programmcode – wichtig ist. Deswegen möchte ich kein Produkt anbieten, welches nicht auch eine solide Basis hat.

Das Problem

Hier bin ich also. Ich schreibe “schönen” Code, welcher sich testen, erweitern, modularisieren und anpassen lässt. Code, der solide, sicher und simpel ist. Natürlich ist mein Code noch lange nicht perfekt – wenn das überhaupt möglich ist – und ich habe noch viel zu lernen, aber ich bin nicht mehr das typische “Scriptkiddie”, das den Code für das fertige Produkt “hinrotzt”. Trotzdem sehe ich immer wieder, dass genau dieser Typ Entwickler am meisten Erfolg hat. So gut wie jedes Produkt, dessen Quellcode ich gesehen habe, ist genau aus dieser Grütze entstanden. Warum? Genau aus den oben genannten Gründen. Dem Endandwender ist es egal, ob dein Code getestet, sicher oder flexibel ist. Dem Endanwender ist es auch egal, ob der Code aus einer einzigen index.php-Datei mit 100.000 Zeilen Spaghetticode besteht. Den Endanwender interessiert das Produkt und dessen Features. Und diese kosten nunmal wenn sie “richtig” gemacht werden wesentlich mehr Entwicklungszeit. Zeit, die wir in der heutigen Welt nicht haben.

Dass solche Produkte nicht wirklich skalieren, ist zu Anfang egal. Wichtig ist der Beginn des Produkts. Wenn es einmal etabliert ist und das Geld für die richtige Weiterentwicklung da wäre, ist es meist schon so verworren und eingefahren, dass das Ablösen nicht mehr wirklich möglich ist. Was bleibt ist ein Wirrwarr aus abertausend Zeilen Code, welcher sofort anfängt zu bröckeln, wenn auch nur eine Kleinigkeit verändert wird. Aber das ist nicht so wichtig. Scriptkiddies sind günstig. Sie machen das Problem zwar nicht besser, aber es funktioniert.

Bis zu einem gewissen Punkt…

Irgendwann ist das ganze System dann aber so verworren, dass sich der Spaghetticode bemerkbar macht. Plötzlich werden die einfachsten Dinge zum Riesenproblem. Microsoft spürt das zum Beispiel aktuell sehr gut. Es geht bergab, weil man einfach nicht mehr so flexibel ist wie die Konkurrenz. Bill Gates dürfte das mittlerweile aber relativ egal sein.

Bildquelle: IcyApril – Refactoring Legacy PHP

Fazit

Ja, was ist das Fazit? Ist das Fazit, dass man als Entwickler keinen Wert auf guten Code legen sollte, wenn man Erfolg haben möchte? Ist das Fazit, dass sich etwas grundlegendes an der Art wie wir Software entwickeln ändern muss? Ich weiß es nicht. Ich wüsste es gerne. Aber vielleicht habe ich ja den ein oder anderen zum Denken angeregt. Wenn du ein gutes Fazit oder eine Meinung hast, dann lass es mich wissen.

Regular Expressions: Alternative Syntax und Builder

Von Karim Geiger — unter Development am 21.08.2016

Regular Expressions – oder zu Deutsch Reguläre Ausdrücke – sind gerade in der Softwareentwicklung ein mächtiges Hilfsmittel, wenn es um Filtern, Validieren, Suchen und Ersetzen geht. Leider sind sie eines ganz bestimmt nicht: Einfach zu lesen und zu schreiben.

Eine simple Regular Expression zum Validieren einer E-Mail-Adresse könnte zum Beispiel so aussehen:

/^([A-Z0-9._%+-])+@[A-Z0-9.-]+\.[A-Z]{2,}$/i

Wer noch nie versucht hat, Regular Expressions zu verstehen, oder diese schlichtweg nicht kennt, schaltet nach einer solchen Zeile definitiv auf Durchzug. Sie ist kryptisch, unverständlich, hässlich und durcheinander. Nur, wer sich gut mit der Materie auskennt und genau weiß, wofür die einzelnen Zeichen stehen, kann – sofern er sich konzentriert in die Sache hineindenkt – verstehen, worum es geht.

Aber warum so kompliziert? Es gibt in der heutigen Zeit viele einfachere Wege, einen regulären Ausdruck zu definieren. Letztendlich lässt sich ein solches Statement ja doch recht einfach in Worte fassen:

Beginne mit einem oder mehreren Zeichen zwischen A-Z, 0-9 oder ., _, %, + oder -. Dann erwarte ein @. Dann...

Und so weiter. Wer einen Schritt weiter denkt, kennt schon jetzt eine Sprache, die so aufgebaut ist: SQL. Die Sprache zum Kommunizieren mit den relationalen Datenbanken dieser Welt ist logisch und verständlich. Warum also kein SQL für Regular Expressions? Warum kein S”R”L?

SRL – Simple Regex Language

Das habe ich mich auch gefragt. Und es einfach gemacht. Darf ich vorstellen: SRL – Simple* Regex Language!

Ein Beispiel gefällig? Ihr erinnert euch an das Beispiel mit der E-Mail-Validierung? In PHP würde das Ganze aktuell so aussehen:

$regex ='/^([A-Z0-9._%+-])+@[A-Z0-9.-]+\.[A-Z]{2,}$/i';
if (preg_match($regex, [email protected]') === 1) { }

Hiermit lässt sich prüfen, ob die gegebene E-Mail-Adresse gültig ist. Wesentlich schöner geht es aber so:

$regex = new SRL('BEGIN WITH EITHER OF (NUMBER, LETTER, ONE OF "._%+-") ONCE OR MORE,
LITERALLY "@",
EITHER OF (NUMBER, LETTER, ONE OF ".-") ONCE OR MORE,
LITERALLY ".",
LETTER AT LEAST 2,
MUST END, CASE INSENSITIVE');
if ($regex->isMatching([email protected]')) { }

Ohne Zweifel ist das SRL-Beispiel wesentlich länger, aber sind wir mal ehrlich… wer keine Ahnung von Regular Expressions hat, kann sich hier denken, was passiert. Besonders, wenn die Person es nicht geschrieben hat und es einen Bug geben sollte, kann dieser einfach behoben werden, da klar ist, worum es geht.

SRL Query Builder – LINQ für Regular Expressions

Doch das ist noch lange nicht alles. Wer Query Builder für MySQL und Co. kennt, wie zum Beispiel LINQ oder Laravels Query Builder, dürfte den SRL Query Builder gut verstehen. Dasselbe Beispiel wie oben, lässt sich hiermit wie folgt in PHP umsetzen:

$query = SRL::startsWith()
    ->eitherOf(function (Builder $query) {
        $query->number()
            ->letter()
            ->oneOf('._%+-');
    })->onceOrMore()
    ->literally('@')
    ->eitherOf(function (Builder $query) {
        $query->number()
            ->letter()
            ->oneOf('.-');
    })->onceOrMore()
    ->literally('.')
    ->letter()->atLeast(2)
    ->mustEnd()->caseInsensitive();

Wie ihr seht, ist die Syntax der SRL Syntax sehr ähnlich. Nur lässt sich damit relativ einfach eine dynamische Regular Expression aufbauen, wenn die Bedingungen erst zur Laufzeit bekannt werden. Am Ende purzelt bei beiden Versionen (SRL und Query Builder) ein Objekt heraus, welches viele tolle Features bietet, wie zum Beispiel das schon gezeigte “isMatching”.

Capture Groups und Lookarounds

Wer sich mit Regular Expressions auskennt, der weiß, dass noch ein paar wichtige Features in SRL bisher nicht erwähnt wurden. Darunter Capture Groups, welche es ermöglichen, Resultate zu filtern, und Lookarounds, welche Bedingungen vor oder nach dem Filter erfüllen müssen. Doch selbstverständlich ist auch dies mit ein paar einfachen Worten zu definieren:

$regex = new SRL('CAPTURE (LITERALLY "foo", OPTIONAL "bi") AS "sample" IF FOLLOWED BY (LITERALLY "bar")');

Das CAPTURE-Keyword definiert eine Capture Group unter dem Namen “sample”, welche auf die Sub-Expression in den Klammern matcht. Dies passiert jedoch nur, wenn auf diese Gruppe direkt die kommende Sub-Expression, nämlich “bar” folgt.

Die folgenden Beispiele würden daraus also resultieren:

$regex->isMatching('foobar'); // true, da auf "foo" direkt "bar" folgt.
$regex->isMatching('foobiboo'); // false, da auf "foobi" kein "bar" folgt.

Da “foobibar” ebenfalls matchen würde, können wir uns mit der “getMatches”-Methode nun ein Array aller Matches ausgeben lassen. Unsere Capture-Group hat den Namen “sample” bekommen, weswegen wir unseren ersten Match nun über diesen Namen abrufen können:

$regex->getMatches('foobibar')[0]->get('sample'); // "foobi"

Auch Dinge wie Replace lassen sich ganz einfach abbilden:

$regex->replace('wunder', 'foobar'); // "wunderbar"

Neben Replace gibt es dann auch noch “filter” und “split”, welche ähnlich funktionieren. Und wem das noch nicht genug ist, der darf sich gerne auch die im Hintergrund erstellte Regular Expression ausgeben lassen und damit alles anstellen, was mit normalen Regular Expressions auch möglich ist.

Viel Spaß

Wer das Ganze einmal selbst ausprobieren möchte, darf gerne das SRL GitHub-Projekt klonen, forken, kopieren, löffeln, runterladen, anpassen, mergen oder was euch sonst noch so alles einfällt.

Natürlich sind auch Implementierungen in anderen Sprachen oder Contributions und Bugfixes sehr gerne gesehen.

 

* Jaja, das S in SQL steht für Structured, aber um ehrlich zu sein finde ich trifft es Simple im Falle der Regular Expressions einfach besser.

Die richtige Programmiersprache

Von Karim Geiger — unter Development, Privat am 15.04.2016

Alles scheiße.

Aber was ist am wenigsten scheiße? Das hier soll kein Blogpost werden, der für irgendjemanden außer mir informativ oder weiterführend sein soll. Es ist lediglich ein Blogpost darüber, wie ich versuche eine neue Programmiersprache zu finden. Wenn ihr also eine Programmiersprache habt, von der ihr genau wisst, dass sie mir gefallen wird, dann gerne her damit. Entweder als Kommentar oder auf Twitter.

Folgende Programmiersprachen kommen für mich (wahrscheinlich) nicht infrage:

  • PHP – Verwende ich aktuell.
  • C# und alles mit .NET – Leider zu Microsoft-Lastig und damit für mich nicht geeignet.
  • Objective-C – Zu “besonders”.
  • Java – Zu unperformant und inkonsequent.
  • JavaScript/NodeJS – Ja genau :D
  • Python – Wirklich schön. Leider ist die Objektorientierung einfach total lieblos integriert.
  • Ruby – Syntaktisch nicht meins, außerdem zu modular.
  • Perl – Zu alt, syntaktisch unschön.
  • C und C++ – Zu systemnah.

Folgende Programmiersprachen könnten eventuell infrage kommen, ganz überzeugt bin ich aber nicht:

  • Go – Die Projektverwaltung gefällt mir nicht, und auch die enge Verknüpfung mit Modulen sieht nicht unbedingt vorteilhaft aus.
  • Swift – ???
  • Rust – ???
  • TypeScript – Frontend…

Und was soll das jetzt?

Weiß ich auch nicht. Aber ist das wirklich relevant?