- Corporate Design ist Pflicht – Mythen der Projektpräsentation
- Die Agenda muss auf jeder Folie stehen – Mythen der Projektpräsentation
- Sourcecode gehört nicht in die Präsentation – Mythen der Projektpräsentation
- Die Wirtschaftlichkeit interessiert niemanden – Mythen der Projektpräsentation
- Technische Inhalte kann man nicht mit Bildern illustrieren – Mythen der Projektpräsentation
- Animationen sind verboten! – Mythen der Projektpräsentation
- Cliparts werten die Folien auf! – Mythen der Projektpräsentation
- Foliennummern bzw. Seitenzahlen gehören auf jede Folie! – Mythen der Projektpräsentation
Nach zwei Beiträgen zur Gestaltung der Projektpräsentation kommen wir in meiner Reihe Mythen der Projektpräsentation nun einmal zu einem inhaltlichen Punkt. Heute nehme ich Stellung zu folgender Aussage:
„Sourcecode (oder auch Quelltext) hat in der Projektpräsentation nichts verloren. Den wollen die Prüfer gar nicht sehen und außerdem kann man ihn eh nicht lesbar darstellen.“
Meiner Meinung nach ist das völliger Quatsch!
Selbstverständlich will ich als Prüfer Quelltext sehen. Vielleicht ist die Dokumentation der geeignetere Platz für lange Listings, aber auch in der Präsentation spricht nichts gegen ein wenig Code.
Ein ganzheitliches Bild eures Projekts
Denkt immer daran: Nicht alle Prüfer haben eure Dokumentation gelesen. Die Arbeit wird meistens aufgeteilt. Das bedeutet, dass einige eurer Zuschauer keine Ahnung haben, was ihr in eurem Projekt gemacht habt.
Eure Aufgabe in der Projektpräsentation ist es nun, allen Zuschauern in kurzer Zeit ein ganzheitliches Bild eures Projekts zu vermitteln. Dazu gehört meiner Meinung nach insb. auch der von euch erstellte Quelltext (sofern euer Projekt die Erstellung eines Programms zum Thema hatte).
Stellt euch doch einmal vor, ein Tischlergeselle müsste seinem Prüfungsausschuss sein Werkstück nur auf dem Papier zeigen oder sogar nur erzählen, wie es aussieht und wie sorgfältig er gearbeitet hat. Was würdet ihr von dieser „Prüfung“ halten?
Genauso möchte ich als Prüfer für Anwendungsentwickler sehen, ob der Prüfling Code schreiben kann und wie dieser aussieht. Programmieren ist doch die zentrale Aufgabe eines Anwendungsentwicklers. Und dann zeigt ihr mir euer „Werkstück“ nicht? Das kann doch nicht richtig sein!
Code ist spannend
Die Prüfer haben allesamt Erfahrung im Bereich Anwendungsentwicklung. Sie sind entweder Lehrer, Ausbilder, Entwickler, IT-Leiter usw. Und alle Prüfer machen ihren Job ehrenamtlich. Das heißt, sie empfinden anscheinend ein gewisses – über das Normale hinausgehende – Maß an Freude an ihrem Job. Und das schließt selbstverständlich auch das Programmieren ein!
Daher werden die meisten Prüfer sich über euren Quelltext freuen! Sie wollen sehen, wie und was „man heute so programmiert“. Sie sind interessiert an neuen Programmiersprachen, klugen Algorithmen und spannenden Problemstellungen. Sie denken gerne darüber nach, wie sie selbst die Aufgabe gelöst hätten. Sie schauen gerne über den Tellerrand ihres Unternehmens oder ihrer Berufsschule hinweg und lassen sich von jungen Entwicklern – euch – inspirieren.
Und diese Freude wollt ihr den Prüfern nehmen?
Code auf dem Prüfstand
Alles, was in der Projektpräsentation gezeigt wird, kann potentiell von den Prüfern hinterfragt werden. Viele Prüflinge vertreten daher anscheinend die Meinung, dass die Prüfer nichts kritisieren können, was sie nicht sehen, und zeigen ihren Code nicht.
Aber die Kritik der Prüfer ist gar nicht böse gemeint. Die Prüflinge sollen ja ihre beste Arbeit zeigen und müssen sie ggfs. auch verteidigen oder Fehler einsehen und Verbesserungen vorschlagen können. Wenn mir ein Prüfling auf einen von mir gefundenen Fehler eine plausible Antwort gibt und erklären kann, wie man den Fehler ausbessern und in Zukunft vermeiden kann, zeigt das gerade seine Fähigkeiten.
Kein Mensch ist perfekt und gerade im Entwickleralltag sind Code Reviews an der Tagesordnung. Soll ich jedes Mal in Tränen ausbrechen, weil ein Kollege meine for-Schleife korrigiert hat? Viel wichtiger ist doch, dass das Programm korrekt läuft und das Unternehmen kein Geld verliert oder Schlimmeres passiert. Um das zu erreichen, muss ich mir gefallen lassen, dass mein Code kontrolliert und ggfs. korrigiert wird.
Und meint ihr, wenn ihr keinen Code zeigt, finden die Prüfer nicht heraus, dass ihr gar nicht richtig programmieren könnt? Mit ein paar gezielten Fragen kann jeder Prüfer in ein paar Minuten klären, ob der Prüfling weiß, wovon er redet. Dazu ist keinerlei Code nötig!
Im Gegenteil: Projekte, von denen ich keine Zeile Code gesehen habe, sind mir automatisch suspekt. Wurde wirklich etwas umgesetzt? Kann der Prüfling überhaupt programmieren? Das sind Fragen, mit denen ihr besser nicht ins Fachgespräch starten solltet!
Code in der Präsentation
Wenn ihr Code in eure Präsentation einbauen wollt, dann achtet bitte unbedingt auf die folgenden Punkte:
- Der Code muss gut lesbar sein.
Für Präsentationsinhalte, die die Prüfer nicht lesen können, gibt es sofort Punktabzug. Das hat auch nichts mit Code zu tun, sondern gilt für alle Inhalte. - Der Code muss schnell verständlich sein.
Zeigt keinen Code, den man 5 Minuten lang analysieren muss, um ihn zu verstehen. Ihr habt nur 15 Minuten Zeit, also sorgt dafür, dass man in wenigen Augenblicken versteht, was euer Code macht. - Der Code sollte interessant sein.
Vermeidet triviale Codebeispiele wie Klassendefinitionen,import-Zeilen und Getter/Setter. Dieser Code ist langweilig und zeigt nicht eure Fähigkeiten. Zeigt spannende Algorithmen und ausgeklügelte Lösungen. Zeigt Code, der es wert ist, programmiert zu werden, und nicht auf Knopfdruck von IDEs generiert werden kann.
Geeignete Darstellung
Schauen wir uns nun einmal an, wie ihr euren Code zur Geltung bringt und dafür sorgt, dass die obigen Punkte eingehalten werden. Starten wir mit einem Negativbeispiel:
- Der Code ist nicht lesbar.
- Er enthält zu über 50% Langweiligkeiten wie
imports. - Es wird viel Platz verschenkt durch Formatierung.
Schauen wir uns nun ein Positivbeispiel an (bewusst ohne Corporate Design, das wie oben sichtbar nur Platz rauben würde):
- Der Code ist deutlich erkennbar und gut lesbar.
- Auf uninteressante Details (sogar auf den Methodenkopf) wird verzichtet.
- Die Formatierung wurde angepasst (zusätzliche Zeilenumbrüche, verringerte Zeileneinrückung, keine separate Zeile für öffnende Klammern), sodass der Code optimal auf die Folie passt.
Zum Abschluss hier noch ein Beispiel aus Gerdas Präsentation. Sie hat Code inkl. Tests gezeigt und ihn mit der Erklärung ihres Entwicklungsprozesses verknüpft. Somit konnte sie gleich zwei Fliegen mit einer Klappe schlagen.
Fazit
Ich hoffe, ich konnte euch davon überzeugen, Code in eure Präsentation einzubauen. Ich persönlich warte bei jeder Präsentation auf ein kleines Stückchen Code, um mir ein besseres Bild des Projekts machen zu können. Und ich denke, dass es vielen Prüfern ähnlich geht.
Was haltet ihr von Code auf den Folien? Habt ihr gute oder schlechte Beispiele für Code in Präsentationen? Ich würde mich über euer Feedback freuen!
Weitere Infos zur Projektpräsentation
Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.
Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.
Hallo Stefan,
Ich habe am Dienstag meine Prüfung und bin für jeden Tipp dankbar.
Zur Präsentation: Ich habe ein UML Diagramm mit einfließen lassen.
Ist es ratsam zu erklären, dass ich meinen Benutzer beispielsweise als Aktuer eingesetzt habe , Lese und Schreibvorgänge von Daten die Anwendungsfälle kennzeichnen und diese immer eine Authentification behinhalten (include), sowie dass mein Webservice die Systemgrenze ist.
Wie würdest du ein Use-Case Diagramm präsentieren.
Vielen dank im Voraus !
Phillip
Hallo Phillip,
du beschreibst schon ganz gut, wie ich ein Use-Case-Diagramm vorstellen würde. Je nach Umfang deiner Use-Cases kann das aber recht lange dauern. Daher würde ich z.B. max. einen konkreten Use-Case beschreiben und die restliche Zeit für andere Inhalte nutzen. Aber eine kurze Einleitung, was die Idee hinter deiner Modellierung ist, finde ich absolut sinnvoll.
Viele Grüße und viel Erfolg bei deiner Präsentation!
Stefan
Hallo Stefan,
Vielen Dank für das schnelle Feedback.
Bei weiteren Fragen würde ich mich wieder bei dir melden!
ich bedanke mich ebenfalls für die Erfolgswünsche ich kann es echt gebrauchen, da ich bei solchen Dingen immer extrem nervös und aufgeregt bin. Ich hoffe ich bekomme das in den Griff :).
Mit Freundlichen Grüßen,
Phillip
Hallo Stefan,
Wie versprochen melde ich mich noch einmal.
Ich bin nun vor dem Problem das ich überlege wie ich meinen Code am besten präsentiere
Meine Entwicklung ging in 3 Schritten von statten.
1. Herstellen der Datenbankverbindung
-soll ich anhand des Codes erklären mit welcher PHP Funktion ich die Verbindung herstelle und welche Parameter ich übergebe oder nur auf den Codeblock verweisen um zusagen „in diesem Codeblock stelle ich meine Datenbankverbindung her.
2.Authentifizierung des Benutzers.
-hier war meine Überlegung gewesen auch wieder genutzte Funktionen und übergebene Parameter anzugeben
oder soll ich auch Explizit erklären was meine SQL Abfrage mach (Welche Tabellen ich anspreche, nach was ich filtere usw.)
3. Abfrage Verarbeitung und Darstellen der Daten.
Entschuldige das ich deine Zeit in Anspruch nehme und ich würde mich wieder über eine Antwort freuen.
Mit Freundlichen Grüßen
Phillip
Hallo Phillip,
deine Ideen hören sich für mich ganz stark nach „Trivialitäten“ an. Einzelne Methodenaufrufe mit den Parametern zu erklären, finde ich immer nicht so spannend. Gerade wenn es um alltägliche Sachen wie Datenbankverbindungen geht. Hast du nicht „coolen“ Code? Irgendwas, das ich nicht in jedem PHP-Projekt so wiederfinden würde? Deine Fachlogik? Irgendeinen zentralen Algorithmus, der dein Projekt ausmacht?
Viele Grüße!
Stefan
Der Code der Mein Projekt eigentlich ausmacht ist der in Punkt 3.
Beispiel anhand Abfrage der Kundendaten:
Die Eigentliche Datenabfrage bzw SQL Anweisung wird in einer Stringvariable gespeichert und mittels der Funktion ibase_query ausgeführt. Damit ich meine Liste der Ergebnisse später einmal ausgeben kann hab ich die erhaltenen Objekte mithilfe einer Schleife an ein Array übergeben. Zum Schluss übergebe ich mein Array an das View welches die Ausgabe der Daten für den Benutzer später ermöglicht
Das ganze sieht so aus:
$stmt =
‚Select * from TAdressen a
left join TStrasse s on a.ID_STRASSE = s.ID
left join TOrt o on s.ID_ORT = o.ID
where a.DEB_KRED = \’D\‘
and a.MDNR = 3′;
$arrayds = array();
$query= ibase_query($this->db,$stmt);
while ($row = ibase_fetch_object($query)) {
$arrayds[] = $row;
}
$this->view->assign('value',$arrayds);
Das ist etwas interessanter, aber halt immer noch recht allgemeiner PHP-Code, den ich schon oft gesehen habe. Aber du kannst ein paar Inhalte daran erklären: Datenbank, SQL, MVC.