Schrei-Helm

Schrei-HelmVielleicht ein Problem, das viele in der IT tätige Leute kennen… und manchmal will man nur noch… man kann gar nicht mehr… *zieht den Schrei-Helm wieder an*.

Was dann im Studium / der Ausbildung langweilig klingt („kommentiert, wendet bekannte Patterns an, wenn möglich, benutzt Frameworks, die euch den Boilerplate-Code abnehmen…“) wirkt sich spätestens dann positiv aus, wenn ein Jahr später der Kunde kommt und gerne nochmal ein Feature erweitert oder umgebaut haben möchte und man dann anfangen muss, sein eigenes Projekt (oder das eines Kollegen, der mittlerweile etwas anderes macht) zu reverse-egineeren um es weiterzuentwickeln.

(Um hier nicht mich mit fremden Lorbeeren zu schmücken: Der Schrei-Helm ist ein Meme, das wir mit Kumpels in der Projektgruppe im Studium entwickelt haben… 😀 )

Zur Entwicklung des Comics hab ich mal ein paar Screenshots / Fotos vom Malprozess gemacht. Vorgehen: Vorskizze auf Schmierpapier (nicht abgebildet), richtige Skizze auf Papier (links), Gescannt und Outlines in MyPaint nachgemalt (Mitte) und dann schattiert und koloriert (rechts). Danach hab die Panels in Gimp zerschnitten und in Inkscape eingefügt, dort dann in vernünftigen Abständen angeordnet und der Rahmen und der Text gesetzt.

Skizze 1Skizze 2

Skizze 3

Schreib also schön hübschen Code und legt euch zur Sicherheit – damit ihr die Kollegen nicht nervt – einen Schrei-Helm in den Schrank.

2 Kommentare zu “Schrei-Helm

  1. TCM1003

    am 02.10.2013 um 07:58

    Da schaut man ’ne Minute nur auf die erste Einblendung mit „Schrei-Helm“ und sucht erstmal die richtige Art und Weise zu lesen. Ala Sextanten… und nach so richtig langer Zeit merkt man dann, oh geht ja weiter… hups… 😛

    Was Programmierung angeht kann ich ja nicht so viel mitreden, machen ja nur Anfänger-Java in der Berufsschule. Wobei wir da schon auf die Probleme des Begriffs „richtig“ kommentieren gekommen sind. Wenn man auch ein wenig Ahnung von dem Programm vor sich hat, was es tun soll, helfen ein paar Kommentare, schön. Aber manchmal wären selbst bei unser Lehrerin Kommentare nach jedem Befehl sinnvoll.

    Wo kann ich den Schrei-Helm eigentlich erwerben, könnte den für einige Kunden und ihr Hardware-Verständnis gebrauchen. 😉
    (Wie, Start > Ausschalten? Ich zieh da immer den Stecker…)

    • Faldrian

      am 02.10.2013 um 10:37

      Es gibt verschiedene Konventionen, was sich bewährt hat zu kommentieren.
      Bei Interfaces wird das Interface ausführlich dokumentiert, so dass für die jeweilige Implementierung schonmal klar ist, was die Funktionen jeweils tun müssten. Ansonsten lohnt eben ein beschreibender Kommentar-Block über jeder Funktion und beschreibende Kommentare inline bei logischen Absätzen.

      Kollegen sagen, ich kommentiere so viel… liegt vermutlich daran, dass sie so wenig kommentieren. 😉 Bei mir ists schon 30% kommentar, 70% code – das hilft auch beim Herausarbeiten der Programmstruktur, wenn man sich eben in Stichpunkten hinschreibt, was da passieren soll.

      Wenn man sich also so eine Klasse anguckt, ist das recht Top-Down kommentiert: Beschreibst du die Klasse, hast du schonmal einen Eindruck, wofür sie da ist und was sie so leisten soll. Beschreibste Funktionen, weißt du dann wie du sie anwenden kannst. Innerhalb Funktionen beschreibste, wie sie das erreichen und wenn etwas nicht intuitiv ist oder du länger gebraucht hattst um das herauszutüfteln, wie du es umsetzt – denn dann wirste auch länger brauchen um das beim nächsen Mal Lesen wieder zu verstehen.

      Soweit jedenfalls meine Faustregeln. 🙂

Schreibe einen Kommentar

Deine Email wird nicht veröffentlicht, Name und Email müssen angegeben werden.