Lebendig(en) Quellcode präsentieren

Prä­sen­tiert man im Bereich der Soft­ware­ent­wick­lung, ist es häu­fig sinn­voll oder gar nötig, „But­ter bei die Fische” zu packen – direkt Quell­code zumin­dest aus­zugs­wei­se zu prä­sen­tie­ren. Ob auf Fach­kon­fe­ren­zen, im Rah­men von Code Reviews oder gar in Prüfungs-​Präsentationen​1: Es hat wohl fast jeder Ent­wick­ler schon hunderte​2 Foli­en vol­ler „totem”, schlecht les­ba­rem und in viel zu klei­ner Schrift gesetz­tem Code über sich erge­hen las­sen müs­sen – weder wirk­li­ch beein­druckend noch ernst­haft ziel­füh­rend. Davon, wie man Source­code bes­ser prä­sen­tiert, han­delt die­ser Arti­kel. Für den Eili­gen fin­det sich am Ende des Arti­kels eine kom­pak­te, prio­ri­sier­te Check­li­ste.

Quellcode auf PowerPoint-Folien ist wie Trockenblumen - totSource­code auf Foli­en ist ein wenig wie Trocken­blu­men: hüb­sch, aber tot. Nur leben­di­ger Quell­code lässt sich leben­dig prä­sen­tie­ren – und das geht nur in der IDE. Mit der eige­nen Ent­wick­lungs­um­ge­bung zu prä­sen­tie­ren, dürf­te fast immer authen­ti­scher wir­ken – und ermög­licht es, fle­xi­bel mit dem Publi­kum und sei­nen Fra­gen zu inter­agie­ren.

Nun könn­te man anneh­men, man könne sich auf diese Weise die unge­lieb­te Vor­trags-Vor­be­rei­tung spa­ren – schnell das Note­book an den Bea­mer anschlie­ßen, aus dem Stand­by auf­wecken und ein­fach nur in der IDE da wei­ter­ma­chen, wo man gera­de auf­ge­hört hat. Das ist lei­der nicht der Fall – ein wenig Vor­be­rei­tung ist unver­meid­bar und das eine oder ande­re ist zu beach­ten:

Den Quellcode für die Präsentation vorbereiten

Nie­mand prä­sen­tiert den Inhalt z. B. eines Papers, indem ein­fach die PDF mit dem Bea­mer an die Wand gewor­fen wird. Eben­so wenig sinn­voll ist es, Quell­code unver­än­dert zu prä­sen­tie­ren – meist sind zumin­dest an den auf jeden Fall zu prä­sen­tie­ren­den Stel­len Anpas­sun­gen not­wen­dig, um den Source­code „prä­sen­ta­bel” zu machen:

  • Der Umbruch soll­te ange­passt wer­den. Was wäh­rend der Ent­wick­lung hilf­reich ist, kostet beim Prä­sen­tie­ren u. U. schlicht zu viel Platz: Die Brei­te der Zei­len soll­te so gering sein, dass eine les­ba­re Schrift­grö­ße mög­li­ch ist – die Tiefe der Ein­rückun­gen soll­te also ggf. redu­ziert wer­den. Mit der Höhe – der Anzahl der Zei­len – muss eben­falls sorg­sam umge­gan­gen werden​3: Öff­nen­de und schlie­ßen­de Klam­mern bei­spiels­wei­se in eige­ne Zei­len zu set­zen, erhöht zwar die Les­bar­keit des Codes am Bild­schirm unge­mein, nimmt aber beim Prä­sen­tie­ren meist zu viel Platz weg – mehr Code am Stück zei­gen zu kön­nen, ist i. d. R. wich­ti­ger und für das Ver­ständ­nis hilf­rei­cher.
{
     abort();
}
{ abort(); }
  • Sie haben wirk­li­ch wenig Platz: Meist sind nur die oberen zwei Drit­tel des Bild­schirms wirk­li­ch für das gesam­te Publi­kum sicht­bar (s. u.).
  • Kom­men­ta­re sind im prä­sen­tier­ten Code aus­nahms­wei­se über­flüs­sig. Auch, wenn man gern zei­gen möch­te, dass man lege artis kom­men­tiert: Die mei­sten Men­schen kön­nen nicht gleich­zei­tig lesen und zuhö­ren – und das, was nor­ma­ler­wei­se in Ihren Kom­men­ta­ren zu lesen sein soll­te, gehört im Falle der Prä­sen­ta­ti­on von Code auf die „Ton­spur”. Eben­so, wie eine Prä­sen­ta­ti­on kein Han­dout ist (vgl. hier), ist prä­sen­tier­ter Source­code eben etwas ande­res als der „echte” Code, den man (natür­li­ch wohl­kom­men­tiert) in das Repo­si­to­ry über­gibt.
  • Zu guter letzt: Der Code soll­te mög­lich­st noch funk­tio­nie­ren. Ein Vor­teil des Prä­sen­tie­rens mit der IDE ist ja gera­de das fle­xi­ble und leben­di­ge Prä­sen­tie­ren – und dazu gehört m. E., quasi in vivo arbei­ten zu kön­nen, bei Bedarf den Code auch aus­füh­ren oder debug­gen zu kön­nen. Wenn irgend mög­li­ch, soll­te der Code also das Umfor­ma­tie­ren „über­le­ben” – „toten” Code kann man auch mit Power­Point prä­sen­tie­ren.

Die IDE für die Präsentation einrichten

Eine IDE ist von Haus aus kein Prä­sen­ta­ti­ons­werk­zeug. Um sinn­voll mit einer IDE zu prä­sen­tie­ren, sind meist Anpas­sun­gen not­wen­dig:

  • Die Schrift soll­te so groß wie irgend mög­li­ch gewählt wer­den. Die maxi­mal sinn­voll nutz­ba­re Schrift­grö­ße hängt natur­ge­mäß sehr stark vom zu prä­sen­tie­ren­den Code ab – die Schrift­grö­ße soll­te also erst end­gül­tig fest­ge­legt wer­den, nach­dem der Code für die Prä­sen­ta­ti­on vor­be­rei­tet wurde (s. o.). Eine „Faust­re­gel” für die mini­ma­le Schrift­grö­ße anzu­ge­ben, erscheint mir übri­gens wenig sinn­voll: Was noch erkenn­bar ist, hängt stark von der Größe des Rau­mes ab.
  • Das GUI der IDE soll­te mini­miert wer­den, es soll­te kein Platz für wäh­rend der Prä­sen­ta­ti­on nicht benö­tig­te Werk­zeuglei­sten o. ä. ver­schwen­det wer­den. Even­tu­ell bie­tet der Edi­tor sogar einen „full-screen mode”, der zum Prä­sen­tie­ren geeig­net ist – dann soll­te man aller­dings beach­ten, dass der unte­re Teil des Bild­schirms u. U. aus den hin­te­ren Rei­hen nicht sicht­bar ist (s. u.).
  • Die Syn­tax­her­vor­he­bung soll­te ggf. ange­passt wer­den. Was am eige­nen Moni­tor gut erkenn­bar und gut unter­scheid­bar ist, ist als pro­ji­zier­tes Bea­mer-Bild unter Umstän­den kaum noch erkenn­bar oder nicht aus­ein­an­der zu hal­ten. Gibt es (z. B. durch die Defaults einer extrem ver­brei­te­ten IDE) einen Stan­dard, soll­te man die­sen aller­dings mög­lich­st nur behut­sam ver­än­dern – die (Code‑)​Lesegewohnheiten des Publi­kums sind meist recht aus­ge­prägt; das Publi­kum zu irri­tie­ren, ist wenig hilf­reich. Exi­stie­ren für die Syn­tax­her­vor­he­bung keine Quasi-Stan­dards, soll­ten erkenn- und unter­scheid­ba­re Far­ben gewählt wer­den. In jedem Fall emp­fiehlt es sich, die Farb­wahl mit dem für die Prä­sen­ta­ti­on vor­ge­se­he­nen Bea­mer zu testen – am besten unter rea­li­sti­schen Licht­ver­hält­nis­sen. Zeigt man „klas­si­sche” Foli­en (und nicht direkt die IDE), emp­fiehlt es sich, Screen­shots aus der IDE zu prä­sen­tie­ren – auf diese Weise kann mit wenig Auf­wand die „nor­ma­le” Syn­tax­her­vor­he­bung über­nom­men wer­den. Auch für Screen­shots aus der IDE gilt übri­gens natür­li­ch alles hier Gesag­te – und zusätz­li­ch der Hin­weis, dass diese am besten in der Ziel-Auf­lö­sung ange­fer­tigt (und nicht nach­träg­li­ch bis zur Unschär­fe ver­grö­ßert) wer­den soll­ten.

Raum und Bildschirm sinnvoll einrichten

Ist es im Falle „nor­ma­ler” Prä­sen­ta­tio­nen manch­mal gera­de­zu eine Gnade, nicht alle Zei­len der über­füll­ten Folie sehen zu müs­sen, ist dies beim Prä­sen­tie­ren von Code fatal: Prä­sen­tiert man Quell­code, kommt es auf jede Zeile an. Pro­ble­ma­ti­sch ist nun, dass (abhän­gig davon, wie hoch die Lein­wand hängt) zumin­dest die hin­te­ren Rei­hen des Publi­kums meist nur die oberen zwei Drit­tel des Bea­mer-Bil­des wirk­li­ch sehen kön­nen – der Rest ist häu­fig von den Köp­fen der wei­ter vorne Sit­zen­den mehr oder min­der ver­deckt. In den mei­sten Vor­trags­räu­men lässt sich dem­entspre­chend nur der obere Teil des Bil­des wirk­li­ch für die Prä­sen­ta­ti­on nut­zen. Beson­ders fatal wirkt die­ses Pro­blem übri­gens bei „Live-Demos” an der Kom­man­do­zei­le: Spä­te­stens nach den ersten paar Befeh­len ist man am unte­ren Rand des Kon­so­len-Fen­sters ange­kom­men und das Gesche­hen fin­det womög­li­ch für große Teile des Publi­kums unsicht­bar statt. Es hilft nur eins: Beschrän­ken Sie sich auf den oberen Teil des Bild­schirms – und testen Sie aus der letz­ten Reihe, wel­chen Teil Sie trotz der vie­len Köpfe zwi­schen Ihnen und der Lein­wand noch sicher sehen kön­nen. Die­ser Hin­weis gilt natür­li­ch auch, falls Sie Source­code mit „klas­si­schen” Folien​4 prä­sen­tie­ren: Jede ein­zel­ne Zeile muss auch von ganz hin­ten sicht- und les­bar sein. 

Gera­de bei „Live-Demos” neige ich dazu, das Pro­blem der hin­te­ren Rei­hen „im Eifer des Gefechts” zu ver­ges­sen. Ich dis­zi­pli­nie­re mich falls nötig, indem ich die (Windows‑)​Taskleiste so ver­grö­ße­re, dass der unte­re Bild­schirm­be­reich davon ver­deckt wird​5. Die „work area”​​6 wird dem­entspre­chend klei­ner und selbst maxi­mier­te Fen­ster wer­den nicht größer​7. Nun ist eine über­di­men­sio­na­le Task­leis­te zuge­ge­be­ner­ma­ßen nicht gera­de eine Zier­de. Ich habe mir des­we­gen ein klei­nes Script geschrie­ben, das die Task­leis­te tem­po­r­är mit einem schwar­zen, rand­lo­sen Fen­ster über­deckt (siehe Anhang 2).

Lebendig(en) Quellcode präsentieren (1)Lebendig(en) Quellcode präsentieren (2)Lebendig(en) Quellcode präsentieren (3)

Das Prä­sen­tie­ren von „leben­di­gem” Quell­code ist eine der weni­gen Prä­sen­ta­ti­ons-Situa­tio­nen, in denen ich ein Red­ner­pult für sinn­voll (wenn nicht gar not­wen­dig) halte: Mit der IDE im Ste­hen zu prä­sen­tie­ren ist ohne Red­ner­pult nahe­zu unmög­li­ch. Ein­zig Ste­hen aber (im Gegen­satz zum Sit­zen des Publi­kums) erscheint mir für den Refe­ren­ten sinn­voll, es unter­streicht die Rolle als Vor­tra­gen­der. Ein sit­zen­der Refe­rent wirkt auf mich, als würde die Rolle nicht wirk­li­ch ange­nom­men oder gar abge­lehnt.

Nicht nur Code

Prä­sen­tiert man mit der IDE, wird der Bild­schirm auf den Bea­mer gespie­gelt. Möch­te man nun zusätz­li­ch Foli­en zei­gen, erfor­dert dies min­de­stens einen Wech­sel des Pro­gramms und meist sogar eine Ände­rung der Bild­schirm-Kon­fi­gu­ra­ti­on – eine Ände­rung, die bspw. Power­Point unter Umstän­den sogar auto­ma­ti­sch durch­führt und die man anschlie­ßend müh­sam rück­gän­gig machen muss. Plant man einen sol­chen „Medi­en-Mix”, ist eine voll­stän­di­ge und rea­li­sti­sche Gene­ral­pro­be drin­gend ange­zeigt.

Sofern der Raum nicht zu groß ist, um dar­auf auch aus den hin­te­ren Rei­hen noch etwas zu erken­nen, emp­fiehlt es sich m. E. immer, ein Flip­chart oder ein Whi­te­board bereit­ste­hen zu haben. Der hoch­gra­dig inter­ak­ti­ve Cha­rak­ter des Prä­sen­tie­rens mit der IDE erfor­dert die Mög­lich­keit, aus dem Steg­reif visua­li­sie­ren zu kön­nen. Damit schließt sich dann auch der Kreis hin zum eigent­li­chen Thema von Buch und Blog: Dem spon­ta­nen Visua­li­sie­ren von IT-The­men an Whi­te­board und Flip­chart. Das Flip­chart steht hier im sel­ben Ver­hält­nis zu Power­Point wie die IDE: Beide ermög­li­chen das spon­tan-inter­ak­ti­ve, leben­di­ge Prä­sen­tie­ren!

Anhang 1: Checkliste „Lebendig(en) Quellcode präsentieren”

Diese Check­li­ste ist der Anhang zum Arti­kel „Lebendig(en) Quell­code prä­sen­tie­ren” – gewis­ser­ma­ßen die extrem ver­kürz­te Zusam­men­fas­sung. Der erste Punkt der Check­li­ste ergibt sich damit quasi auto­ma­ti­sch:

  • Habe ich den voll­stän­di­gen Arti­kel gele­sen?
  • Den Code für die Prä­sen­ta­ti­on anpas­sen:
    • Unnö­ti­ge Zei­len­um­brü­che z. B. bei { } ent­fer­nen
    • Ein­rückun­gen redu­zie­ren
    • Kom­men­ta­re ent­fer­nen
    • Ist der Code noch lauf­fä­hig?
  • Die IDE für die Prä­sen­ta­ti­on ein­rich­ten:
    • Schrift­grö­ße so groß wie irgend mög­li­ch wäh­len
    • Unnö­ti­ge Werk­zeuglei­sten etc. schlie­ßen
    • Die Far­ben der Syn­tax­her­vor­he­bung ggf. für den Bea­mer anpas­sen (testen!)
  • Raum und Bild­schirm ein­rich­ten:
    • Die Unter­gren­ze des aus der letz­ten Reihe noch erkenn­ba­ren Bild­schirm­aus­schnitts testen
    • Die Task­leis­te hoch­zie­hen und den nicht erkenn­ba­ren unte­ren Bereich bedecken las­sen
    • Die Task­leis­te ggf. per Script schwarz über­decken
    • Steht ein Red­ner­pult zur Ver­fü­gung?
    • Steht zusätz­li­ch ein Flip­chart oder Whi­te­board zur Ver­fü­gung?

Anhang 2: Script zum Überdecken der Taskleiste

Vor rund 15 Jah­ren habe ich „die Sei­ten gewech­selt” – weg von der (Datenbank‑)​Softwareentwicklung hin zu IT-Infra­struk­tur-The­men. Seit­dem ist es eher sel­ten gewor­den, dass ich Code schrei­be – und wenn, dann eher kurze und lange Scripts, inzwi­schen meist in PowerS­hell oder wie in die­sem Fall (gera­de beim rela­tiv system­na­hen „Basteln”) auch gern mal mit AutoIt <https://​www​.autoit​script​.com/>. Das fol­gen­de Script ver­deckt die Task­leis­te durch ein schwar­zes, rand­lo­ses Fen­ster, das sich bei Drücken von Esc schließt. Es ist weder „schön” noch beson­ders inno­va­tiv; wie viel­leicht typi­sch für Scrip­te ist es wirk­li­ch nur „fit for pur­po­se” – z. B. geht es davon aus, dass die Task­leis­te sich am unte­ren Bild­schirm­rand befin­det. Mir hilft es – aber viel­leicht fin­det sich ja bei­zei­ten jemand, der sich die Mühe macht, das Pro­blem über eine schwar­ze, rand­lo­se AppBar8 ganz all­ge­mein und deut­li­ch ele­gan­ter zu lösen. Bis dahin kann ein Jeder gern auf eige­ne Gefahr und ohne jede Gewähr den fol­gen­den Code nut­zen, für sich anpas­sen und ggf. sogar der Ein­fach­heit hal­ber kom­pi­lie­ren – wer die­ses Script für seine Prä­sen­ta­ti­on braucht, wird ver­mut­li­ch auch damit klar­kom­men.

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <WinAPIGdi.au3>
#include <WinAPISys.au3>

AutoItSetOption('GUICloseOnESC', 1)

$hWorkArea = _WinAPI_GetWorkArea()
$dwWorkAreaWidth = DllStructGetData($hWorkArea, 'Right') - DllStructGetData($hWorkArea, 'Left')
$dwWorkAreaHeight = DllStructGetData($hWorkArea, 'Bottom') - DllStructGetData($hWorkArea, 'Top')

$aCurrentDisplaySettings = _WinAPI_EnumDisplaySettings('', $ENUM_CURRENT_SETTINGS)
$dwDisplayWidth = $aCurrentDisplaySettings[0]
$dwDisplayHeight = $aCurrentDisplaySettings[1]

Global $dwWindowHeight = $dwDisplayHeight - $dwWorkAreaHeight
Global $dwWindowWidth = $dwDisplayWidth
Global $dwWindowX = 0
Global $dwWindowY = $dwWorkAreaHeight

Global $hWindow = GUICreate('HideTaskBar', _
   $dwWindowWidth, $dwWindowHeight, _
   $dwWindowX, $dwWindowY, _
   $WS_POPUP, _
   $WS_EX_TOPMOST)

GUISetBkColor(0x000000, $hWindow)

GUISetState(@SW_SHOW, $hWindow)

While 1
   $nMsg = GUIGetMsg($hWindow)
   Switch $nMsg
      Case $GUI_EVENT_CLOSE
         Exit
   EndSwitch
WEnd

GUIDelete($hWindow)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*