Um die Darstellung von Code in Projektdokumentation und
Projektpräsentation geht es in der sechsten Episode der Shorts des
IT-Berufe-Podcasts. Zusammenfassung der Episode In der aktuellen
Episode meiner Podcast-Shorts dreht sich alles um die Kunst der
Codepräsentation in Dokumentationen und Präsentationen – ein Thema,
das gerade in der Prüfungsphase viele Prüflinge beschäftigt. Ich
gebe praktische Tipps, wie ihr euren Code optimal aufbereitet, um
in euren Dokumentationen und Präsentationen zu glänzen. Wir reden
darüber, wie der Code in Dokumentationen anders aussehen sollte als
in der IDE. Wichtig ist die Lesbarkeit: Setzt auf Struktur und
Kontrast, und überlegt euch, ob der Dark Mode wirklich die beste
Wahl ist. Ich erkläre, wie ihr den Fokus auf relevante
Codeabschnitte legt und unwichtige Details ausblendet. Außerdem
teile ich meine besten Hacks für PowerPoint, damit ihr euren Code
Schritt für Schritt einblenden könnt – so zieht ihr die
Aufmerksamkeit eurer Prüfenden auf eure Erklärungen! Und natürlich
gibt es noch Hinweise zur Farbgestaltung, denn Schwarz auf Weiß ist
meist der beste Kontrast. Hört rein, holt euch nützliche Tipps und
bereitet euch bestens auf eure Prüfungen vor. Ich bin gespannt auf
euer Feedback und wünsche euch viel Erfolg bei euren Projekten!
Inhalt Zusammenfassung Die Episode behandelt die Frage, wie
Quelltext in Projektdokumentationen und Projektpräsentationen einer
Abschlussprüfung für Fachinformatiker Anwendungsentwicklung
sinnvoll dargestellt werden sollte. Ausgangspunkt ist die
Beobachtung, dass in Prüfungsunterlagen häufig Code-Screenshots aus
der IDE verwendet werden, oft zusätzlich im Dark Mode. Die zentrale
Aussage lautet, dass Code in der Prüfung nicht so präsentiert
werden sollte, wie er in der Entwicklungsumgebung für die tägliche
Arbeit angenehm ist, sondern so, dass er im jeweiligen Medium
optimal lesbar, verständlich und bewertbar ist. Ausgangslage und
Prüfungsbezug Im Kontext der AP2 und der anschließenden
Projektdokumentation sowie Projektpräsentation spielt Code eine
zentrale Rolle, da er den Kern der Arbeitsleistung von
Anwendungsentwicklerinnen und Anwendungsentwicklern darstellt.
Dabei wird der Begriff „Code“ weit gefasst: Gemeint ist nicht nur
klassischer Programmcode in Sprachen wie Java, C# oder PHP, sondern
auch andere textbasierte Artefakte wie Jenkinsfiles, Dockerfiles
oder Konfigurationsdateien, sofern sie Teil der technischen Lösung
sind. Da diese Artefakte in Dokumentation und Präsentation bewertet
werden, müssen sie so aufbereitet sein, dass Prüfende sie ohne
unnötige Hürden erfassen können. Zentrale Qualitätsziele Für die
Darstellung von Code in Prüfungsartefakten nennt die Episode drei
Kernziele: Lesbarkeit Der Code muss visuell gut erfassbar sein.
Dazu gehören ausreichende Schriftgröße, geeigneter Kontrast und
eine Darstellung, die sich an das Ausgabemedium anpasst.
Verständlichkeit Der gezeigte Ausschnitt muss in kurzer Zeit
nachvollziehbar sein. Besonders in der Präsentation darf der Umfang
nicht so groß sein, dass das Publikum während der Erklärung den
Überblick verliert. Bewertbarkeit Gezeigt werden sollte genau das,
was die eigene Leistung belegt. Unwichtige oder automatisch
erzeugte Inhalte erschweren die Beurteilung und lenken vom
eigentlichen Beitrag ab. Unterschied zwischen IDE und
Prüfungsmedium Ein zentraler Punkt ist die Trennung zwischen
Entwicklungsumgebung und Prüfungsmedium. In der IDE wird Code unter
anderen Bedingungen gelesen und bearbeitet als in einer
Dokumentation oder Präsentation: In der IDE wird oft an einem
Bildschirm mit individueller Konfiguration gearbeitet. Die
Dokumentation kann auf Papier, Tablet oder Laptop gelesen werden.
Die Präsentation findet typischerweise in einem hellen Raum statt,
oft mit Beamer oder Monitor. Daraus folgt, dass
Formatierungsentscheidungen aus der IDE nicht automatisch für Doku
oder Präsentation geeignet sind. Auch Seitenverhältnisse
unterscheiden sich deutlich: Präsentationen meist im Format 16:9
Dokumentationen typischerweise im DIN-A4-Format Code sollte deshalb
für jedes Medium separat aufbereitet werden, etwa durch angepasste
Zeilenumbrüche und kompaktere Formatierung. Kritik an Screenshots
Von Screenshots aus der IDE wird klar abgeraten. Dafür werden
mehrere technische Gründe genannt: Screenshots sind nicht
verlustfrei skalierbar; beim Zoomen werden sie unscharf oder
pixelig. Text bleibt bei Vergrößerung nicht sauber lesbar.
Screenshots enthalten oft störende IDE-Elemente wie
Fehlermarkierungen, Warnungen, Refactoring-Hinweise oder Hinweise
zur Code-Historie. Solche Einblendungen lenken von der eigentlichen
Aussage ab und können im Prüfungskontext sogar unerwünschte Fragen
auslösen. Empfohlen wird daher, Code als echten Text in
Dokumentation oder Präsentation einzufügen. Das verbessert
Skalierbarkeit, Lesbarkeit und Bearbeitbarkeit deutlich.
Empfehlungen zur Formatierung Für die Formatierung des Codes werden
mehrere konkrete Hinweise gegeben: Verwendung einer
Monospace-Schriftart, damit Einrückungen und Ausrichtung korrekt
bleiben Anpassung von Zeilenlängen und Umbrüchen an das Zielmedium
Gegebenenfalls Änderung von Code-Konventionen für die Darstellung,
etwa geschweifte Klammern ans Zeilenende statt in eine separate
Zeile zu setzen, um Platz zu sparen Nur die relevanten Ausschnitte
zeigen, nicht vollständige, kompilierbare Dateien Schlüsselwörter
oder Modifier wie public, static, final weglassen, wenn sie für die
Aussage nicht relevant sind Syntax-Highlighting verwenden, aber nur
in einer Form, die die Lesbarkeit unterstützt Die Episode betont,
dass Prüfungsunterlagen keine originalgetreue Abbildung der IDE
sein müssen. Erlaubt und sinnvoll ist vielmehr eine auf das
Publikum optimierte Darstellung. Bewertung des Dark Mode Ein
Schwerpunkt der Episode ist die Kritik am Dark Mode in
Dokumentation und Präsentation. Dabei wird ausdrücklich nicht der
Dark Mode im Entwicklungsalltag kritisiert, sondern dessen
Übertragung in Prüfungsunterlagen. Für Dokumentationen Gegen dunkle
Hintergründe in der Dokumentation sprechen laut Episode mehrere
Gründe: Schwarzer Text auf weißem Hintergrund bietet den besten
Kontrast für das Lesen. Weißer oder farbiger Text auf schwarzem
Hintergrund ist schlechter lesbar, insbesondere mit
Syntax-Highlighting. Ausdrucke mit schwarzem Hintergrund
verbrauchen unnötig viel Toner oder Tinte. Kommentare und
Korrekturen auf ausgedruckten Seiten sind auf dunklem Hintergrund
schlechter sichtbar. Für Präsentationen Auch in Präsentationen wird
der Dark Mode als problematisch beschrieben: In hellen Räumen
erscheint Schwarz oft eher grau, wodurch der Kontrast sinkt. Bei
Displays oder Monitoren können dunkle Flächen stärker spiegeln.
Reflektionen können die Sicht auf den Code zusätzlich erschweren.
Die pragmatische Empfehlung lautet daher: Code für die Prüfung
möglichst dunkel auf hellem Hintergrund darstellen.
Verständlichkeit in der Präsentation Für die Präsentation wird
empfohlen, Code nicht in großen Blöcken auf einer Folie zu zeigen.
Stattdessen sollte er schrittweise eingeblendet werden, etwa
zeilenweise. Begründung: Das Publikum liest sonst sofort den
gesamten Code und hört der Erklärung nicht mehr zu. Die
Aufmerksamkeit lässt sich besser steuern. Relevante Teile können
gezielt erläutert werden. Diese Vorgehensweise ist mit Textobjekten
in Präsentationstools deutlich einfacher als mit Screenshots.
Auswahl des gezeigten Codes Besonders wichtig ist die Auswahl der
Inhalte. Gezeigt werden sollte nur Code, der die eigene fachliche
Leistung sichtbar macht. Nicht geeignet sind laut Episode
insbesondere: generierte Getter und Setter Standard-Konstruktoren
triviale Framework- oder Binding-Logik austauschbare
Konfigurationsausschnitte ohne inhaltliche Tiefe
HTML-Standardmarkup ohne projektspezifische Aussage Stattdessen
sollte der Fokus auf dem fachlich interessanten Teil des Projekts
liegen, zum Beispiel: projektspezifische Logik ein selbst
entwickelter Algorithmus zentrale Teile der Domäne nicht triviale
Datenverarbeitung Logik, die klar die eigene Denk- und
Entwicklungsleistung zeigt Fazit der Episode Die Episode versteht
Code-Darstellung als Teil der Prüfungsleistung. Ziel ist nicht, die
gewohnte IDE-Darstellung zu reproduzieren, sondern die Inhalte so
aufzubereiten, dass Prüfende sie schnell erfassen und fair bewerten
können. Entscheidend sind dabei eine textbasierte statt
bildbasierte Darstellung, hohe Lesbarkeit, reduzierte und
zielgerichtete Ausschnitte sowie die Konzentration auf den
individuellen fachlichen Beitrag. Die Kernaussage lässt sich so
zusammenfassen: Für Dokumentation und Präsentation sollte Code
mediengerecht vereinfacht, formatiert und ausgewählt werden, damit
er die eigene Leistung klar und ohne Ablenkung zeigt. Höre dir
jetzt die Podcast-Episode an! Links Permalink zu dieser
Podcast-Episode RSS-Feed des Podcasts Kontrast und Farben
Transkription der gesamten Episode Automatisch erzeugte
Transkription der Episode [0:20] Während ich das hier aufnehme,
sind schon wieder viele Prüflinge im Prüfungsstress, denn die AP2
steht an. Und direkt danach ist bei vielen IHK ja schon die Abgabe
der Projektdokumentation. Und danach kommt dann die
Projektpräsentation und dann ist endlich die Ausbildung beendet.
Und ich werde auch dieses Jahr wieder einige Artefakte mir
anschauen dürfen, Projektdokumentation lesen, Projektpräsentation
anschauen und natürlich dann bewerten. Und da ich ja nun mal
Anwendungsentwicklerinnen prüfe, werde ich da natürlich, solange
wir noch Code schreiben müssen, als Anwendungsentwicklerinnen auch
Code präsentiert bekommen. Entweder in der Doku oder in der Präsi
oder im besten Fall in beiden. Denn das ist ja nun mal der Kern
unseres Ausführungsberufs und das gehört natürlich dazu. [1:03] Und
Code, damit meine ich nicht nur Programmiersprachencode, Java, C
Sharp, PHP, was auch immer....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.