IT-Berufe-Podcast

Weißt du schon, was du nach deiner Ausbildung zum Fachinformatiker machst? Eine tolle Alternative zum Studium bespreche ich mit Simon Stork in der einhundertsiebenundzwanzigsten Episode des Anwendungsentwickler-Podcasts: die IHK-Weiterbildung zum Operative Professional.

TL;DR

Mit Simon Stork schaue ich auf den Operative Professional, eine IHK-Weiterbildung für deinen beruflichen Weg nach der Ausbildung zum/zur Fachinformatiker:in. Du lernst Methoden für die Projektleitung und bereitest dich darauf vor, Mitarbeiter:innen zu führen und Aufgaben im mittleren Management zu übernehmen. Simon hat berufsbegleitend zwei Jahre gebraucht und damals rund 5.900 Euro einschließlich Prüfungsgebühren bezahlt, wobei er über Meister-BAföG einen Teil erlassen bekam. Seine Erfahrungen zeigen, wie der Abschluss bei Bewerbungen helfen und zu einem höheren Gehalt beitragen kann.

Kapitelmarken

[00:00:01] Operative Professional und berufliche Wege nach der Ausbildung

[00:01:54] Simon Stork und seine Arbeit im CAD- und PLM-Bereich

[00:04:24] Von der IT-Ausbildung zur berufsbegleitenden Weiterbildung

[00:09:09] Der Operative Professional und seine vier Ausrichtungen

[00:11:30] Lerninhalte für Projektleitung und mittleres Management

[00:15:20] Erwartungen und persönliche Ziele vor der Weiterbildung

[00:17:16] Blended Learning und Workshops vor Ort

[00:20:11] Projektmethoden im beruflichen Alltag

[00:22:58] Schriftliche Prüfung mit Situationsaufgaben

[00:26:32] Projektdokumentation und Niveau des Abschlusses

[00:28:34] Dauer und Abgabetermine

[00:30:08] Das passende Projekt und Vorgaben der IHK

[00:31:50] Kosten und Finanzierung über Meister-BAföG

[00:34:10] Bildungsträger auswählen und Zusatzkosten einplanen

[00:36:21] Gehalt und beruflicher Aufstieg

[00:38:04] Erfahrungen mit Bewerbungen und Arbeitgebern

[00:41:17] Weiterbildung zum Strategic Professional

[00:43:08] Simons Gründe für den Operative Professional

[00:48:23] Persönlicher und finanzieller Ertrag

[00:50:25] Verkürzter Bachelor nach dem Operative Professional

[00:51:37] Erprobter Zugang zum Masterstudium

[00:53:13] Anerkennung im öffentlichen Dienst

[00:54:09] OP-Blog und Kontakt zu Simon

[00:55:33] Hinweise für deinen weiteren Berufsweg

Inhalt

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du (falls gewünscht)?

Simon Stork, im Consulting tätig, eher Projektleitung und IT, kein Programmierer. 35 Jahre alt, verheiratet, komme aus Paderborn.

An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?

CAD/PLM, Consulting, Einführung von Systemen, Change Management, Requirements Engineering, ca. 50/50 technisch/Projektleitung.

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Ich bin ein Kind der 80er Jahre, war technikinteressiert und bin mit dem C64 über Spiele in den Umgang mit Computern eingestiegen. Mit 13 hatte ich meinen ersten PC. Dann kam das Internet und mein Einstieg in HTML/PHP. Programmieren war mir zu monoton und ich wollte lieber FISI werden und mit Netzwerken arbeiten.

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

2001 habe ich die Ausbildung zum FISI angefangen, dann kurz Lehramt studiert, aber doch wieder zum gewechselt.

Operative Professional (OP)

Wie bist du selbst zu der Weiterbildung gekommen? Welche Alternativen hast du dafür ausgeschlagen?

"Nur" eine Ausbildung reichte mir nicht. Zertifikate (z.B. MCSA) sind aber zeitlich begrenzt und sehr teuer. Ich suchte eine Weiterbildung ohne Verfallsdatum.

Ein Studium war die Alternative. Ich habe den OP im Netz gefunden. Ich war schon Projektleiter und der OP passte inhaltlich sehr gut dazu.

Was ist der Operative Professional?

Der OP ist eine Art "Meister" für ITler.

Offiziell: "Aufstiegsweiterbildung" im Anschluss an die Ausbildung.

Welche Ausrichtungen des OP gibt es?

Entwickler, Ökonom, Berater, Projektleiter

Projektleiter ist mit ca. 80% die verbreitetste Form.

Inhalte der Richtungen gleichen sich zu 90%. Aber die Projektarbeit am Ende unterscheidet sich vom Fokus und es gibt leicht andere Aufgaben in der Prüfung.

Welche Ausrichtung hast du für dich selbst gewählt und warum?

Projektleiter, weil das genau zu meinem Aufgabengebiet passte.

Welche Inhalte werden beim OP vermittelt?

Der OP hat eigentlich nichts mit Technik zu tun. Es geht um die Vorbereitung auf eine Karriere im mittleren Management.

Themen: Personalmanagement, Projektanbahnung, Requirements Engineering, Konfliktmanagement, Projektblockaden auflösen, Methoden, Controlling, Pflichtenheft.

Wir haben z.B. Rollenspiele gemacht, um praktische Erfahrungen im Team zu sammeln.

War dir die fehlende Technik bewusst? Was sagen andere Teilnehmer dazu?

Ja, ich habe mich sogar bewusst dafür entschieden.

Ca. 80% der Teilnehmer wussten ebenfalls bescheid, aber auch der Rest war letztlich mit den Inhalten zufrieden.

In welcher Form hast du die Weiterbildung absolviert (z.B. via Präsenzveranstaltungen oder komplett online)? Würdest du evtl. auch ein komplettes Selbststudium empfehlen?

Ich habe ein "Blended Learning" absolviert, also Vorbereitung Online und Präsenzphasen vor Ort.

Mit einem Tutor hatten wir alle 6-8 Wochen 2 Tage Vollzeit Veranstaltungen vor Ort. Dort haben wir Aufgaben gelöst, präsentiert (!) und Gruppenarbeiten durchgeführt.

Ein Selbststudium ist nicht zu empfehlen, da die Bildungsträger besser wissen, was die IHK hören will, und die Fragestellungen kennen.

Sind die vermittelten Inhalte von Wert und für die Praxis relevant? Wie hoch war der Anteil an Lehrstoff, den du direkt in der Praxis anwenden konntest?

Wichtig ist das Wording: Begriffe (FMEA, RAKI) und Methoden sollte jeder Projektleiter kennen. Sie sind enorm wichtig für eine gute Kommunikation.

Es wurden auch typische Projektmethoden nach PMBOK oder ISO gelernt. Auch Zertifikate wie PRINCE/ITIL/AdA sind möglich.

Wie sieht die Prüfung aus?

Es gibt eine Präsentation, Klausuren und eine Projektdokumentation.

Es wird keine reine Begriffsabfrage durchgeführt, sondern konkrete Fragestellungen zu Beispielprojekten werden bearbeitet. Es wird eher Modellierung/Dokumentation mit EPKs usw. gefordert, die z.B. die Wahl des korrekten Abstraktionslevels erfordern. Es wird Bezug zum konkreten Projekt mit Bewertung und Planung der Projektphasen hergestellt. Es geht um die praktische Anwendung und den Transfer des gelernten Wissens.

Meine Projektdokumentation war ca. 65 Seiten lang. Das Projekt sollte min. 1/2 Jahr, max. 1 Jahr dauern. Das Projekt sollte "echt" sein und nicht hypothetisch.

Wie lange hat deine Fortbildung zum OP gedauert?

Normalerweise dauert der OP 1,5 Jahre. Man hat 1 Jahr Zeit für die Projektdoku.

Was kostet der OP?

Eigentlich fallen nur die Prüfungskosten an, wenn man alles im Selbststudium macht.

Mit Bildungsträger liegt man bei ca. 5.900 EUR (rein Bildungsträger und Prüfung, keine Fahrt-/Hotelkosten).

Eine Finanzierung ist über (Meister-)Bafög möglich. Bei erstmaligem Bestehen der Prüfung werden 50% der Kosten erlassen. Firmen bezahlen auch häufig die Weiterbildung.

Ein Aufstieg im Job ist ja meist das Ziel, also sollte sich der OP amortisieren. Ich selbst hatte eine deutliche Gehaltssteigerung durch den OP. Allerdings ist der konkrete Anteil des OP daran schwer einzuschätzen, da ich mich auch persönlich weiterentwickelt habe.

Welchen Bildungsträger würdest du empfehlen?

Das muss jeder selbst entscheiden. Ich habe meinen (manQ) gewählt, weil er nah an meinem Wohnort lag. Aber viele Teilnehmer kamen auch von weiter weg.

Reine Online-Seminare gibt es auch, da Blended Learning nicht für alle Teilnehmer klappt.

Offiziell ist der OP gleichwertig zu einem Bachelor. Wie schätzt du die tatsächliche Anerkennung in der Arbeitswelt ein?

Ich habe einen sehr positiven Eindruck. Ich habe inzwischen mehrere Jobwechsel vollzogen und der OP war bekannt und anerkannt. Mein erster Jobwechsel fand während des OPs statt und mit einem Nachweis vom Bildungsträger über den zeitlichen Umfang in Stunden in der Bewerbung konnte ich einen guten Eindruck machen. Im Vorstellungsgespräch wurde der OP dann auch direkt angesprochen und hinterließ einen positiven Eindruck beim Arbeitgeber.

Wird der OP tendenziell von Kollegen anerkannt oder wird man eher geliebäugelt?

Ich selbst habe zwei Kollegen, die auch den OP gemacht haben. Viele wissen vom OP, aber denken eher an ein Studium. Der OP ist an den Umfang des Bachelors angelehnt, aber eben nicht das gleiche, da er kein akademischer, sondern ein IHK-Abschluss ist.

Es gibt auch noch die "Strategic Professionals", sprich z.B. den "Geprüften Wirtschaftsinformatiker". Macht das "Upgrade" dazu Sinn?

Die Strategic Professionals sind vergleichbar mit einem Master. Aber sie werden meines Wissens nach nicht so stark nachgefragt. Die genauen Inhalte sind mir auch nicht bekannt, da es sehr wenige Informationen online gibt. Das Ziel ist aber wohl die Vorbereitung auf eine Laufbahn im höheren Management. Technik wird wieder nicht vertieft.

Wovon würdest du die Entscheidung zwischen OP und Studium abhängig machen? Wann wäre ein Studium sinnvoller?

Ich war zum Start des OP schon in der Arbeitswelt und ich wollte nicht mehrere Jahre berufsbegleitend studieren. Der zeitliche Aufwand ist immer interessant. Ein Bachelor läuft 4-5 Jahre berufsbegleitend, was ich sehr lang finde.

Im Bachelor lernt man auch erneut viele Grundlagen, die fertige Fachinformatiker nicht unbedingt weiterbringen.

Der Bachelor ist auf dem Papier schön und zeigt die Fähigkeit zur akademischen Arbeit. Außerdem lernt man Grundlagen wie Mathe/BWL usw.

Die eigene Motivation ist wichtig, auch langfristig! Je länger es dauert, umso wahrscheinlicher bricht man ab. Auch bei 1,5 Jahren hat man mal Hänger!

Wie schätzt du die weitere Entwicklung rund um den OP ein?

Ich glaube, dass viele Firmen aktuell umdenken. Bachelor/Master sind nicht mehr so wichtig wie früher. Die Fachlichkeit ist eher gefragt. Das mag auch am Fachkräftemangel liegen.

...

Über verschiedene Möglichkeiten zur Verbesserung unserer Programmierfähigkeiten spreche ich mit Dennis Dierkes in der einhundertsechsundzwanzigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Ich zeige dir gemeinsam mit Dennis Dierkes, wie du als IT-Azubi deine Programmierfähigkeiten durch Coding Dojos, Fachbücher und kleine eigene Projekte weiterentwickelst und über Meetups Kontakte knüpfst. Dabei gehören Zeit zum Lernen im Betrieb und konkretes Feedback durch dein:e Ausbilder:in ebenso dazu wie deine eigene Neugier, die dich auch nach der Ausbildung begleitet.

Kapitelmarken

[00:00:01] Einführung in Continuous Improvement

[00:01:36] Dennis Dierkes und sein Weg in die Softwareentwicklung

[00:02:49] Spring, Kotlin und aktuelle Projekte

[00:05:26] Warum du nach der Ausbildung weiterlernst

[00:06:35] Eigeninitiative und Zeit zum Lernen im Betrieb

[00:08:09] Tech Fridays und gemeinsame Lernformate

[00:10:58] Lebenslang lernen und neugierig bleiben

[00:12:05] Kotlin mit Übungen und Pair Programming lernen

[00:13:14] Coding Katas und Coding Dojos

[00:14:09] Eigene Lernprojekte überschaubar halten

[00:15:18] Fachbücher lesen und bestehenden Code prüfen

[00:17:19] Dojos und Bücher miteinander verbinden

[00:18:19] Lösungen vergleichen und Design Patterns ausprobieren

[00:19:41] Wie ein Open Space abläuft

[00:22:02] Meetups und die Java User Group

[00:23:56] Programmieren mit den Bielefelder Software Kids

[00:28:08] Anschluss bei Veranstaltungen finden

[00:29:21] Treffen suchen oder selbst organisieren

[00:30:58] Auf Workshops und Meetups vorbereiten

[00:32:06] Notizen, Beispielcode und Sketchnotes

[00:33:17] Fachbücher und Buchclubs in der IT-Ausbildung

[00:36:12] Growing Object-Oriented Software, Guided by Tests

[00:37:49] Pair Programming und konkrete Code Reviews

[00:39:30] Dennis online erreichen

[00:40:50] Weitere Anregungen und Links zur Episode

Inhalt

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du?

Dennis Dierkes, 21 Jahre alt, Prüfung zum Fachinformatiker Anwendungsentwicklung vor 2 Wochen bestanden.

An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?

Java-lastige Sachen wie Spring, Kotlin und funktionale Programmierung mit Vavr, aber auch SOAP, Bootstrap, AWS, Vue.js.

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Klassisch über Computerspiele.

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

Ausbildung FIAE, vorher Realschule.

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Java, Kotlin

Was ist deine Lieblingsprogrammiersprache und warum?

Kotlin bietet enorm viele coole Möglichkeiten für Entwickler.

Continuous Improvement

Warum sollte ich meine Fähigkeiten als Softwareentwickler ständig ausbauen?

Ich kann höhere Qualität abliefern, schneller entwickeln und Probleme lösen, langfristig Zeit sparen.

Liegt Weiterbildung in meiner eigenen Verantwortung oder in der meines Arbeitgebers?

Es sollte Eigeninitiative vorhanden sein, die dann optimalerweise Unterstützung durch das Unternehmen bekommt. Ich persönlich habe auch nach einem vollen Arbeitstag noch Lust, nach Feierabend weiter zu programmieren und zu lernen.

Die Motivation steigt, wenn der Arbeitgeber unterstützt. Wir machen z.B. Coding Dojos gemeinsam mit den Kollegen.

Ist man irgendwann auch mal "fertig" mit der Weiterbildung?

Hoffentlich nicht! Ich würde gerne lebenslang lernen! Ich finde es nicht gut, wenn Kollegen, die kurz vor der Rente stehen, nicht mehr mitmachen.

Womit verbesserst du deine (Programmier-)Fähigkeiten?

Kotlin habe ich über ein Tutorial bei GitHub gelernt. Pair Programming hilft sehr beim Wissenstransfer. In Side Projects kann man ohne Druck lernen und sich ausprobieren.

Aktuell habe ich ein Side Project für die Arbeit erstellt mit Vue.js.

Das Side Project sollte nicht zu groß werden, damit es weiter Spaß macht.

Was ist ein Coding Dojo/Barcamp/Code Retreat und was macht man da konkret?

Coding Katas sind kleine Übungsaufgaben für Programmierer.

Coding Dojos sind Treffen in einer Gruppe, um die Katas gemeinsam zu bearbeiten.

Ich persönlich mag das "Hands On" im Coding Dojo und nehme dann noch ein Buch zur Vertiefung.

Sehr spannend war z.B. das Bearbeiten der Katas von mehreren Programmierpaaren und der anschließende Vergleich der Lösungen. Dabei haben wir dann z.B. Design Pattern angewendet und ihre Vor- und Nachteile besprochen.

Welche Ressourcen verwendest du zur persönlichen Weiterbildung?

Bücher. Mit neuem Wissen auf alten Code schauen. Retrospektiven durchführen.

Kannst du konkrete Bücher/Kurse/Veranstaltungen empfehlen?

Clean Code*, Growing Object-Oriented Software, Guided by Tests*

Was ist ein Open Space?

Eine "Unkonferenz" mit mehreren Räumen. Es gibt eine Tafel für die Themenwahl. Jeder darf eine Session mitbringen oder sich eine wünschen. Man kann jederzeit Vorträge verlassen ("Gesetz der zwei Füße").

Welche Veranstaltungen (für Entwickler) hast du bislang besucht?

Verschiedene Treffen über Meetup.com im Raum Bielefeld, Java User Group (JUG), CloudLab, Socramob.

Ich organisiere auch selbst eine Veranstaltung, um Kinder und Jugendliche an die Programmierung heranzuführen, z.B. mit Little Bits oder dem Calliope. Wir haben auch schonmal einen Minecraft-Bot programmiert.

Wo findest du die Kinder/Jugendlichen, die mitmachen?

Es gab eine Info an die Teilnehmer des Open Spaces, die ihre Kinder angesprochen haben. Außerdem schreibe ich Schulen an.

Was mache ich, wenn ich eher schüchtern/zurückhaltend bin?

Das sind doch alle! Einfach hingehen und mitmachen. Die Teilnehmer sind alle ganz offen. Zur Not einen Kollegen mitnehmen, mit dem man quatschen kann.

Wie findet man Veranstaltungen für Entwickler?

Meetup.com, Softwerkskammer.

Was mache ich, wenn in meiner Region keine Veranstaltungen stattfinden?

Selbst eine organisieren oder halt weiter fahren. Die Softwerkskammer hilft vielleicht.

Wie bereitest du dich auf Veranstaltungen vor?

Meistens gar nicht so viel. Ich gehe einfach hin. Manchmal wird aber empfohlen, etwas mitzubringen (z.B. Repo von GitHub klonen, IDE installieren). Es ist aber immer gut, einen Laptop mitzunehmen.

Wie nimmst du das Optimum aus den Veranstaltungen mit (z.B. Notizen, Ziele setzen)?

Ich nutze eine Notizen-App. Nebenbei probiere ich meist live das Gezeigte aus. Im Nachhinein lade ich den Beispielcode herunter und mache selbst weiter. Aktuell probiere ich Sketchnotes aus.

Aus- und Weiterbildung

Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen?

Zum 01.08. bekommen wir unseren ersten Azubi zum Fachinformatiker Anwendungsentwicklung.

Hast du Tipps für Ausbilder/-innen im IT-Bereich?

Nehmt euch ausreichend Zeit für eure Azubis! Macht z.B. Pair Programming mit ihnen. Wichtig sind auch intensive Code Reviews, bei denen alles angemerkt werden soll, was euch auffällt. Schaut euch detailliert den Code an und nickt nicht einfach alles ab. Nur durch Feedback lernt man.

Abschluss

Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?

Bei Twitter (@deenerin0), Xing, GitHub oder Instagram.

Ansonsten einfach zu einem Meetup im Raum Bielefeld kommen! :-)

Literaturempfehlungen

Robert C. Martin - Clean Code: A Handbook of Agile Software Craftsmanship*

*

Growing Object-Oriented Software, Guided by Tests*

*

Java By Comparison: Become a Java Craftsman in 70 Examples (Affiliate)*. Den erwähnten Podcast zum Buch gibt es hier: InnoQ-Podcast: Java by Comparison.

*

Die Sketchnote Starthilfe: Über 200 Strich-für-Strich-Anleitungen und Schriften zum Nachzeichnen*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Meetup.com

Cloud Lab Bielefeld

Java User Group Bielefeld (Bielefeld, Deutschland) | Meetup

Softwerkskammer

Münster/Osnabrück/Bielefeld

Oldenburger Münsterland

Bielefelder Software Kids

littleBits (Lernprojekt für den Arduino)

CALLIOPE mini* (Microcontroller zum Lernen)

JetBrains Kotlin Workshop Material

Zusammenfassung

Deine Programmierfähigkeiten weiterentwickeln

Dennis Dierkes hat seine Ausbildung zum/zur Fachinformatiker:in für Anwendungsentwicklung gerade abgeschlossen und arbeitet inzwischen in einem kleinen Unternehmen. Dort entwickelt er Webanwendungen mit Spring und beschäftigt sich für kommende Projekte mit Kotlin und Vue.js. Im Gespräch mit ihm greife ich auf, wie du auch nach deinem Abschluss weiterlernst.

Wenn du neue Technologien kennenlernst und deine Fähigkeiten ausbaust, kannst du hochwertigere Software schreiben. Was du lernst, hilft dir auch, wenn du bestehenden Code später erweiterst oder überarbeitest. Für mögliche Arbeitgeber:innen wirst du durch zusätzliche Kenntnisse interessanter.

Dennis möchte seine Neugier über das gesamte Berufsleben behalten. Wie viel Zeit du dafür aufbringen kannst, hängt auch von deinen Lebensumständen ab.

Zeit zum Lernen im Betrieb

Dennis lernt während der Arbeitszeit und beschäftigt sich aus eigenem Interesse auch abends mit Softwareentwicklung. Sein Unternehmen stellt Zeit bereit, um neue Themen kennenzulernen. Persönliche Initiative und die Unterstützung durch den Betrieb gehören dabei zusammen.

Für Technologien, die du bei der Arbeit brauchst, sollte dein:e Arbeitgeber:in Zeit zum Lernen einräumen. Ob du dich zusätzlich in deiner Freizeit damit beschäftigst, entscheidest du selbst.

In Dennis’ Unternehmen wurde ein früherer Tech Friday verändert, nachdem einigen Kolleg:innen Ideen oder Interesse fehlten. Freitags finden inzwischen gemeinsame Coding Dojos und Vorträge aus dem Team statt, etwa zu Vue.js. Auch für neue Themen außerhalb eines konkreten Projekts gibt es Zeit. Die Teilnahme ist freiwillig.

Bei mir im Unternehmen arbeiten sich Kolleg:innen während der Arbeitszeit in Technologien ein, die ein Projekt erfordert. Bei Bedarf sind auch Kurse möglich. Ein festes Format für frei gewählte Lernthemen gibt es zum Zeitpunkt des Gesprächs noch nicht.

Mit Coding Katas und Pair Programming üben

...

Die noch fehlenden Teile der IHK-Sommerprüfung 2018 - Projektdokumentationen und Fachgespräche - bespreche ich in der einhundertfünfundzwanzigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Bei der IHK-Sommerprüfung 2018 habe ich häufig Projektarbeiten gelesen, deren methodisches Vorgehen kaum erkennbar war. Für deine Projektdoku brauchst du klar erfasste Anforderungen und einen begründeten Entwicklungsprozess, während passende Diagramme dein Projekt verständlich machen. Im Fachgespräch musst du die eingesetzten Technologien erklären können und fachliche Grundlagen beherrschen; dazu gehören auch Datenschutz und kaufmännische Themen wie die Kostenrechnung.

Kapitelmarken

[00:00:01] Hinweise zum Fachgespräch

[00:00:37] Rückblick auf die IHK-Sommerprüfung 2018

[00:01:37] Unterschiedliche Projektthemen und Technologien

[00:02:31] Methodisches Vorgehen in der Projektarbeit

[00:05:17] Quelltext lesbar in die Doku einfügen

[00:07:07] Agile Entwicklungsprozesse beschreiben und begründen

[00:09:19] Amortisation aus der passenden Perspektive berechnen

[00:10:53] Projektumfeld und interne Begriffe erklären

[00:13:01] Anforderungen erfassen und priorisieren

[00:14:36] Architektur und Oberflächen visuell darstellen

[00:16:38] Stundensatz und Kosten des eigenen Projekts

[00:18:44] Projektdoku gegenlesen lassen

[00:19:35] Den Betrieb knapp und projektbezogen vorstellen

[00:21:41] Grundlagen im Fachgespräch

[00:23:36] Datenschutz und IT-Sicherheit

[00:24:59] Lambda-Ausdrücke und funktionale Programmierung

[00:25:54] AJAX und asynchrone Aufrufe

[00:27:54] REST und vertiefende Schnittstellenfragen

[00:29:08] Vertraute Technologien für das Prüfungsprojekt wählen

[00:30:00] Betriebsabrechnungsbogen und Kostenrechnung

[00:31:08] Funktionale Anforderungen und Softwarequalität

[00:32:18] TypeScript und Typisierung

[00:33:14] Frameworks und Annotationen verstehen

[00:33:52] Entwurfsmuster erklären

[00:35:50] Domain-Driven Design im Fachgespräch

[00:37:50] Rückblick auf wiederkehrende Prüfungsfehler

[00:38:52] Shownotes und Kommentare

[00:39:14] Newsletter und kostenlose Checklisten

Inhalt

Projektdokumentationen

Fehlende Methodik bleibt das Hauptproblem vieler Projektarbeiten.

Code auf schwarzem Hintergrund in der Dokumentation geht gar nicht.

"Agil" ist das neue "wir wissen nicht, was wir tun".

Bei der Amortisationsrechnung werden häufig fälschlicherweise interne Kosten mit externen Zeiteinsparungen verglichen.

Interne Begriffe werden als allgemein bekannt vorausgesetzt und nicht erklärt.

Für mehrere Projekte wurden die Anforderungen nicht sauber aufgenommen. Stattdessen wurde wohl einfach drauflos programmiert.

Gerade bei komplexen Architekturen oder Oberflächen sagt ein Bild weiterhin mehr als tausend Worte!

Es gibt immer noch Prüflinge, die ihr Bruttogehalt als alleinige Basis für ihren Stundensatz nehmen.

Einige Dokumentationen wurden offensichtlich in keinster Weise korrigiert oder auch nur gelesen.

Unternehmensvorstellung auf einer ganzen Seite mit ganzseitiger Grafik der Standorte im Anhang.

Fachgespräch

Es hakt oft an den Basics! Klasse/Objekt, Kardinalitäten, Lasten-/Pflichtenheft.

Datenschutz war das dominierende Thema (dank DSGVO).

Grundlagen der funktionalen Programmierung sind bei den meisten Prüflingen immer noch nicht vorhanden. Mal abgesehen von Lambda-Ausdrücken.

AJAX wird fast überall benutzt, aber die Abkürzung kennt kaum jemand.

Asynchrone Programmierung wird eingesetzt, ohne sie erklären zu können. Häufig wird synchron mit parallel durcheinandergebracht.

REST bleibt weiterhin eine zentrale Komponente vieler Projekte, aber kann ebenfalls nur selten korrekt erklärt werden.

Viele Prüflinge setzen Technologien für ihr Projekt zum ersten Mal ein. Tiefergehende Fragen können daher meist nicht beantwortet werden.

Der Betriebsabrechnungsbogen ist vielen Prüflingen nicht bekannt.

Funktionale und nicht-funktionale Anforderungen waren oft nicht bekannt.

Typescript scheint sich für die Frontend-Entwicklung zu etablieren. Aber dann sollte man auch erklären können, warum man es einsetzt.

Viele Frameworks -> viele Annotationen -> viel Magie -> viele unerklärliche Abläufe.

Wer viele Pattern einsetzt, sollte sie auch erklären können. Und auch die Grundidee von Pattern an sich.

Domain Driven Design ist toll. Wenn man es erklären kann.

Literaturempfehlungen

Da ich erneut so ziemlich alle erdenklichen Themen angerissen habe, kann ich mal wieder nur das IT-Handbuch für Fachinformatiker* von Sascha Kersken empfehlen.

*(direkt beim Rheinwerk-Verlag bestellen*)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Berechnung des eigenen Stundensatzes in der Projektdokumentation

Zusammensetzung des Stundensatzes - Häufige Fragen im Fachgespräch

Zusammenfassung

Erfahrungen aus der IHK-Sommerprüfung 2018

Bei über 20 Prüflingen habe ich 2018 sehr unterschiedliche Projekte gesehen, die auf das jeweilige Unternehmen zugeschnitten waren. Die Bandbreite reichte von Java und C# bis zu TypeScript oder Visual Basic. Häufig gingen Punkte verloren, weil aus der Projektdoku kaum hervorging, wie die Software planvoll entwickelt wurde. Auch im Fachgespräch zeigten sich wiederkehrende Lücken.

Dein Vorgehen in der Projektdoku zeigen

Eine der Arbeiten enthielt 25 Seiten Quelltext im Anhang, während Belege für das methodische Vorgehen fehlten. Deine Doku muss nachvollziehbar machen, wie du dein Projekt geplant hast und wie du beim Entwickeln vorgegangen bist.

Halte fest, welche Ressourcen du brauchst und wie du deine Arbeit zeitlich planst.

Erfasse die Anforderungen, bevor du die Software entwirfst.

Zeige mit passenden Modellen, wie du Abläufe oder Datenstrukturen durchdacht hast. Dafür kommen beispielsweise Aktivitätsdiagramme oder ein ER-Modell infrage.

Beschreibe deinen Entwicklungsprozess und begründe, warum er zu deinem Projekt passt.

Fehlen zusätzlich die Doku für Benutzer:innen und die Doku für Entwickler:innen, wirkt sich das auf die Note aus.

Anforderungen aufschreiben und priorisieren

In mehreren Arbeiten waren die Anforderungen auf wenige Sätze beschränkt. Schreibe auf, was deine Anwendung leisten soll und welche Qualitätsanforderungen gelten. Du kannst dafür ein Lastenheft und ein Pflichtenheft erstellen oder mit User Stories arbeiten. Prioritäten lassen sich etwa über Muss-, Soll- und Kann-Kriterien festlegen.

Anhand dieser Vereinbarungen kann dein:e Auftraggeber:in später prüfen, ob du das Projekt erfolgreich umgesetzt hast. Ein Pflichtenheft kann zum Vertragsbestandteil werden und damit helfen, Streit über den vereinbarten Umfang zu vermeiden.

Den Entwicklungsprozess konkret beschreiben

Wenn du agil arbeitest, musst du den gewählten Prozess mit seinen Regeln beschreiben. Scrum und Feature Driven Development sind konkrete Vorgehensweisen. Bei Extreme Programming gehören beispielsweise Test Driven Development und Pair Programming zu den Praktiken.

Für die damals vorgesehenen 70 Projektstunden solltest du prüfen, wie sich dein Prozess im verfügbaren Zeitrahmen durchführen lässt. Bereits nach einer Iteration kann das Projekt weitgehend vorbei sein. Auch beim Wasserfallmodell muss erkennbar sein, wie du die Phasen in deinem Projekt durchläufst.

Dein Projekt verständlich darstellen

Das Umfeld knapp erklären

Beschreibe dein Unternehmen in wenigen Sätzen und erläutere anschließend das Umfeld, das für dein Projekt relevant ist. Interne Softwarebezeichnungen und Abkürzungen brauchen eine Erklärung, damit ich als Prüfer:in nachvollziehen kann, woran du arbeitest.

Halte außerdem fest, welche Aufgaben dein Unternehmen übernimmt und welche bei deinen Kund:innen liegen. Unklare Rollen erschweren es, den Zweck des Projekts und seine Wirtschaftlichkeit zu bewerten. Wie ausführlich du deinen Betrieb vorstellst, richtet sich danach, welche Informationen zum Verständnis des Projekts erforderlich sind.

Architektur und Oberflächen zeichnen

Wenn mehrere Systeme zusammenarbeiten, zeigt eine Architekturskizze, wo welche Software läuft und wohin Daten übertragen werden. Dafür eignet sich ein UML-Komponentendiagramm; auch eine einfache Zeichnung mit Pfeilen kann die Zusammenhänge sichtbar machen.

Für eine geplante Oberfläche bietet sich ein Mock-up an. Eine eingescannte Handskizze kann bereits zeigen, wie ein Dialog aufgebaut ist. Solche Darstellungen gehören auch in deine Präsentation, wenn sie dein Projekt verständlich machen.

Quelltext lesbar setzen

Setze Code als Text auf weißem Hintergrund in einer Monospace-Schrift, beispielsweise Courier New. Dabei haben alle Zeichen dieselbe Breite. Farben zum Hervorheben der Syntax sind möglich.

Screenshots mit schwarzem Hintergrund verbrauchen beim Drucken viel Toner und erschweren es mir, Anmerkungen am Code zu machen.

Die Doku gegenlesen lassen

In einigen Arbeiten fand ich zahlreiche Sprachfehler und abgebrochene Sätze. Lass eine andere Person prüfen, ob deine Sätze verständlich und grammatisch korrekt sind. Sie kann auch auf Rechtschreibung und Satzzeichen achten, ohne dein Projekt fachlich beurteilen zu müssen. Schwer lesbare Inhalte erschweren die Bewertung und beeinflussen die Note.

Kosten für dein konkretes Projekt berechnen

Frage im Rechnungswesen deines Unternehmens nach einem passenden Stundensatz. Darin müssen neben deiner Ausbildungsvergütung auch Lohnnebenkosten und Gemeinkosten berücksichtigt werden. Die Beispielrechnungen in meinen Vorlagen sind unvollständig und müssen an dein Projekt angepasst werden.

Wenn du ein Teilprojekt umsetzt, berechne dessen Kosten und Wirtschaftlichkeit. Die Zahlen des Gesamtprojekts liefern dafür keine ausreichende Grundlage.

Bei der Amortisationsrechnung muss die Perspektive durchgehend zusammenpassen:

Für ein internes Projekt berechnest du, wann die internen Einsparungen die internen Projektkosten ausgleichen.

Bei einem verkauften Produkt rechnest du aus Sicht deines Unternehmens mit den Verkaufserlösen. Je nach Geschäftsmodell kann dafür eine bestimmte Zahl verkaufter Lizenzen erforderlich sein.

...

Wie bereits im letzten Jahr gibt es auch für die IHK-Sommerprüfung 2018 einen Rundumschlag über all meine Erfahrungen in der einhundertvierundzwanzigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Bei der IHK-Sommerprüfung 2018 in Oldenburg habe ich wiederkehrende Fehler gesehen, aus denen du für deine eigene Prüfung lernen kannst. Prüfe dein Projektthema mit deinem/deiner Ausbilder:in auf sinnvolle Alternativen und bereite ausgewählte Codeausschnitte lesbar für die Dokumentation auf. Für die schriftliche Prüfung brauchst du sichere SQL-Grundlagen und Übung in WiSo. Deine Projektpräsentation sollte deine eigene Arbeit mit verständlichen Grafiken zeigen, innerhalb von 15 Minuten bleiben und technisch vorbereitet sein; im Fachgespräch zählt, dass du Zusammenhänge anhand von Beispielen erklären kannst.

Kapitelmarken

[00:00:01] Einstieg und Hinweise zur IHK-Prüfung

[00:00:38] Rückblick auf die Sommerprüfung 2018 in Oldenburg

[00:02:26] Wiederkehrende Probleme und Prüfungsergebnisse

[00:04:19] Referenzielle Integrität im Fachgespräch

[00:05:20] Projektthema prüfen und Alternativen besprechen

[00:07:47] Live-Demo vorbereiten und Zeit einhalten

[00:10:12] Quellcode lesbar und druckfreundlich aufbereiten

[00:13:03] Aussagekräftige Codeausschnitte für den Anhang auswählen

[00:14:27] LaTeX-Folien und visuelle Gestaltung

[00:16:09] Beispiel für 100 Prozent in Präsentation und Fachgespräch

[00:18:21] SQL-Syntax und Platzhalter im Prüfungsbeiblatt

[00:22:30] WiSo vorbereiten und Fragestellungen genau lesen

[00:24:36] Corporate Design und Platz für Folieninhalte

[00:26:03] Hintergrundprogramme und Benachrichtigungen ausschalten

[00:27:40] Eigene Projektarbeit und technische Grundlagen

[00:30:16] Standardisierte Diagramme fachgerecht einsetzen

[00:31:52] Diagramme und Punktlisten schrittweise einblenden

[00:34:06] Folienwechsel und umfangreiche Präsentationsnotizen

[00:36:55] Ausblick auf Projektdokumentation und Fachgespräch

[00:37:40] Shownotes und Kommentare

[00:38:17] Newsletter erneut abonnieren und Checklisten herunterladen

Inhalt

Meine Highlights

Frage nach referentieller Integrität, Gegenfrage: "Gehört das zu Datenbanken?"

Projektarbeit, die mit wenigen Zeilen Code erledigt gewesen wäre.

Fremdschämen bei hakeliger Live-Demo mit Tippfehlern, verschobenen Fenstern usw.

25 Seiten Quelltext als einziger Anhang.

Präsentation auf Basis von LaTeX. Leider fast nur Text ohne Bilder.

Eine 100% im Fachgespräch über Lambdas, Generics, Polymorphie, Java 8, Dependency Injection, Typisierung, das Diamond-Problem usw.

Schriftliche Prüfung

SQL sollte jeder Prüfling kennen. Ist aber leider nicht so. Stattdessen wird die Syntax vom Beiblatt ohne Hinterfragen falsch übernommen.

WiSo hat mal wieder vielen guten Kandidaten die Note versaut.

Projektpräsentationen

Corporate Designs verschlingen teilweise 50% der Folien und überdecken (!) Inhalte.

Unerwarteter Sound während der Präsentation verunsichert Prüfling.

Trivialitäten und allgemein bekannte Technologien (z.B. Request/Response bei REST) werden lang und breit erklärt.

Statt UML wurden teils selbst ausgedachte Diagrammformen verwendet.

Komplexe Diagramme und Punktlisten werden als Ganzes dargestellt, anstatt sie schrittweise einzublenden.

Folien werden ohne sichtbaren Unterschied "weitergeklickt" (vermutlich für die Notizen).

Literaturempfehlungen

Da ich erneut so ziemlich alle erdenklichen Themen angerissen habe, kann ich mal wieder nur das IT-Handbuch für Fachinformatiker* von Sascha Kersken empfehlen.

*(direkt beim Rheinwerk-Verlag bestellen*)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Rückblick auf die Sommerprüfung 2017

Themenfindung für das Abschlussprojekt

Live-Demo in der Projektpräsentation

Sourcecode gehört nicht in die Präsentation - Mythen der Projektpräsentation

Verwendung eines Laserpointers bei der Abschlusspräsentation

Zusammenfassung

Erfahrungen aus der Sommerprüfung 2018

In Oldenburg habe ich 2018 an drei Tagen mehr als 20 Prüfungsteilnehmer:innen geprüft und zusätzlich die schriftliche Prüfung korrigiert. Viele Probleme bei den Projektdokumentationen und im Fachgespräch waren mir bereits aus dem Vorjahr bekannt. Die Ergebnisse lagen überwiegend im Bereich einer schwächeren Zwei oder einer guten Drei; bei den mündlichen Prüfungen gab es zwei Einsen sowie einige Vieren.

Dein Projektthema fachlich prüfen

Bei einem Projekt zur Datenbankoptimierung blieb offen, ob wenige Zeilen Programmcode die Aufgabe ebenfalls hätten lösen können. Der/die Prüfungsteilnehmer:in konnte die Fragen dazu nur teilweise beantworten.

Besprich dein Thema vorab mit deinem/deiner Ausbilder:in oder einem/einer erfahrenen Kolleg:in. Dabei solltest du klären, welchen Zweck das Projekt erfüllt und welche anderen Lösungswege infrage kommen. Gehe mögliche kritische Fragen durch, indem du das Projekt aus Sicht eines/einer Prüfer:in hinterfragst. So bereitest du dich darauf vor, deine Entscheidungen fachlich zu begründen.

Quellcode in der Projektdokumentation

Zum Korrigieren drucke ich Projektdokumentationen aus und schreibe Anmerkungen auf das Papier. In einer Dokumentation bestand der Anhang aus 25 Seiten Code, der als Screenshot auf schwarzem Hintergrund eingefügt war. Das verbraucht viel Toner und erschwert handschriftliche Anmerkungen. Screenshots können außerdem beim Skalieren verzerren oder unterschiedlich große Schrift zeigen.

Bereite deine Codeausschnitte als lesbaren Text auf hellem Hintergrund auf. Der schwarze Hintergrund allein blieb bei mir ohne Notenabzug.

Wähle selbst aus, welche Ausschnitte deine Arbeit fachlich zeigen. Als Faustregel empfehle ich drei bis vier Seiten interessanten Code. Ergänzend kommen beispielsweise ein Unit-Test oder ein Build-Skript infrage. Mit einem ER-Modell und passenden UML-Diagrammen kannst du zeigen, wie du methodisch gearbeitet hast.

SQL für die schriftliche Prüfung üben

In mehreren Lösungen zu einer CREATE TABLE-Aufgabe standen die Datentypen in spitzen Klammern. Im Beiblatt kennzeichneten diese Klammern Platzhalter. Beim Übertragen in ausführbaren SQL-Code müssen die Platzhalter durch konkrete Angaben ersetzt werden, wobei die Klammern entfallen. Für die fehlerhafte Syntax gab es Punktabzug.

Übe die grundlegenden SQL-Befehle so, dass du sie selbst schreiben und Angaben aus einem Beiblatt richtig übertragen kannst. In den Prüfungen der vergangenen Jahre kamen SQL-Aufgaben regelmäßig vor. Dazu gehörten Abfragen mit SELECT, Änderungen mit UPDATE und auch das Anlegen von Tabellen mit CREATE TABLE.

WiSo gezielt vorbereiten

Bei einigen Prüfungsteilnehmer:innen verschlechterte WiSo das schriftliche Gesamtergebnis. Eine Person hatte beispielsweise in GA1 und GA2 jeweils eine Eins, kam durch eine schwache Drei in WiSo insgesamt aber auf eine Zwei.

Arbeite frühere Prüfungen durch, etwa aus den letzten fünf Jahren. Wiederkehrende Inhalte lassen sich teilweise auswendig lernen. Auch bei Multiple-Choice-Aufgaben solltest du die Fragestellung genau lesen. WiSo prüft berufsübergreifende Inhalte und beeinflusst deine Note als Fachinformatiker:in.

Deine Projektpräsentation vorbereiten

Live-Demo und Technik

Eine Live-Demo macht dein Ergebnis sichtbar. In einem Prüfungsbeispiel führten Tippfehler und Probleme mit Fenstern auf dem Beamer dazu, dass die Demo stockte. Anschließend überschritt der/die Prüfungsteilnehmer:in die vorgesehenen 15 Minuten, was ebenfalls Punkte kostete.

Übe den Ablauf intensiv und starte die benötigten Programme schon vor der Präsentation. Als Alternative empfehle ich dir ein aufgezeichnetes Video, dessen Dauer du vorab festlegen und zu dem du während der Präsentation sprechen kannst.

Schließe alle Programme, die du während der Präsentation entbehren kannst, und schalte Benachrichtigungen sowie unnötige Töne aus. Bei einer Prüfung unterbrach ein Hintergrundprogramm mit seiner Soundausgabe den Vortrag. Der/die Prüfungsteilnehmer:in verlor dadurch Zeit und wirkte anschließend verunsichert.

Folien verständlich gestalten

Auch mit LaTeX erstellte Folien brauchen eine passende visuelle Gestaltung. Eine Präsentation mit fast ausschließlich Textpunkten und wenigen kleinen Bildern erhielt Punktabzug. Zeige deine Inhalte mit aussagekräftigen Grafiken, beispielsweise einem UML-Diagramm.

Ein umfangreiches Corporate Design kann viel Platz beanspruchen. In einem Beispiel belegte es ungefähr die Hälfte der Folie und verdeckte sogar Teile der Grafiken. Ich empfehle dir, solche Gestaltungselemente wegzulassen, damit deine Inhalte ausreichend Platz haben.

Deine eigene Arbeit zeigen

Mehrere Prüfungsteilnehmer:innen verbrachten viel Zeit damit, grundlegende Technologien wie REST zu erklären. Teilweise gingen dafür fünf Minuten der Präsentation drauf. Zeige, wie du die Technologie in deinem Projekt eingesetzt hast und welche Arbeit du dabei selbst geleistet hast.

Bei den Prüfer:innen kannst du Grundlagenwissen zu HTTP oder AJAX voraussetzen. Eine kurze Erklärung zu einer speziellen Komponente ist sinnvoll, wenn sie hilft, dein Projekt nachzuvollziehen. Dazu gab es ein passendes Beispiel mit React und Redux, bei dem eine frameworkspezifische Besonderheit auf einer Folie knapp erläutert wurde.

Etablierte Diagramme verwenden

Wähle eine standardisierte Darstellung, die zu deinem Inhalt passt. Für Abläufe kommen beispielsweise UML-Aktivitätsdiagramme oder ereignisgesteuerte Prozessketten infrage. Datenstrukturen kannst du mit einem ER-Modell zeigen. Auch Programmablaufpläne und Nassi-Shneiderman-Diagramme wurden als Möglichkeiten genannt.

Achte auf korrekte Syntax. Damit zeigst du, dass du die etablierten Methoden kennst und fachgerecht einsetzen kannst.

Komplexe Inhalte schrittweise zeigen

Wenn ein großes Diagramm vollständig erscheint, beschäftigen sich die Prüfer:innen zunächst damit, es zu verstehen. Bei einer komplett eingeblendeten Punktliste lesen sie häufig schon voraus, während du noch den ersten Punkt erläuterst.

Blende die Bestandteile passend zu deinem Vortrag schrittweise ein....

Mein drittes Wissenshäppchen hat das Single Responsibility Principle zum Thema.

TL;DR

Das Single-Responsibility-Principle (SRP) ist das erste SOLID-Prinzip: Eine Klasse soll genau eine Aufgabe und damit einen Grund haben, geändert zu werden. Ich übertrage diesen Gedanken auch auf Methoden und andere Komponenten, damit du ihren Code leichter verstehen und getrennt testen kannst. Dabei brauchst du einen passenden Ausgleich zwischen hoher Kohäsion und geringer Kopplung, weil viele kleine Komponenten zusätzliche Abhängigkeiten erzeugen und das Gesamtsystem schwerer überschaubar machen können.

Kapitelmarken

[00:00:26] SRP als erstes SOLID-Prinzip

[00:01:37] Kohäsion: Zusammenhang von Methoden und Attributen

[00:02:45] Fehler durch mehrere Aufgaben in einer Klasse

[00:03:37] SRP für Variablen und Methoden

[00:04:33] Datenbankzugriff und E-Mail-Versand getrennt testen

[00:06:30] SRP auf Architekturebene und bei Microservices

[00:08:01] Mehrere Aufgaben an Namen erkennen

[00:08:48] Allgemeine Klassennamen und Repository-Methoden

[00:10:31] Architekturschichten und Wiederverwendung

[00:11:59] Legacy-Software und automatisierte Tests

[00:13:42] Die Gott-Klasse als Anti-Pattern

[00:15:00] Verständlicher Code und isolierte Tests

[00:17:35] Überblick über viele kleine Komponenten behalten

[00:20:06] Zusätzliche Abhängigkeiten durch kleine Klassen

[00:22:11] Hohe Kohäsion und geringe Kopplung abwägen

[00:23:12] Fachbegriffe: Cohesion und Coupling

[00:23:50] Kleine Komponenten früh voneinander trennen

[00:25:42] Weiterführende Links und Feedback

Inhalt

Das SRP ist das erste der sogenannten SOLID-Prinzipien. Robert "Uncle Bob" Martin definiert es so:

There should never be more than one reason for a class to change.

Jede Klasse sollte genau einen einzigen Grund haben, um geändert zu werden. Man kann das Prinzip aber auch auf anderen Ebenen (z.B. Variablen, Methoden oder ganze Komponenten) berücksichtigen.

Erklärung

Nur Dinge, die zusammengehören, werden auch zusammen abgebildet. Jedes Ding (Variable, Methode, Klasse, Komponente) darf nur eine Aufgabe haben. Die Kohäsion der Dinge sollte hoch sein.

Verletzung ist erkennbar an Wörtern wie und oder oder. Unklare Namen wie z.B. Manager oder Verwaltung sind auch häufig ein Anzeichen für die Verletzung des Prinzips.

Wenn viele Abhängigkeiten und Dinge, die nichts miteinander zu tun haben, in einer Klasse zusammengefasst werden, kann beim Anpassen einer (Teil-)Implementierung eventuell eine damit gar nicht in Zusammenhang stehende Implementierung negativ beeinträchtigt werden.

Praxisbeispiel: Klasse, die Daten aus der Datenbank liest und diese direkt in der Oberfläche anzeigt. Klasse hat nicht nur eine Aufgabe, sondern drei verschiedene: Geschäftslogik, Datenzugriff, Anzeige. Ein Test der Logik ohne Datenbank und/oder Oberfläche ist nun unmöglich. Die Wiederverwendbarkeit der Klasse leidet auch, da die Logik nun nicht mehr ohne Datenbank und/oder Oberfläche aufgerufen werden kann. Das ist oft ein großes Problem in Legacy-Anwendungen.

Ein krasses Gegenbeispiel/Antipattern zum SRP wäre eine Gott-Klasse, die alles Mögliche macht.

Vorteile

Die Klassen, Methoden und Variablen sind insgesamt kürzer und besser verständlich.

Entwickler können Anpassungen durchführen, ohne dabei Fehler an anderer Stelle einzubauen.

Komponenten sind einfacher testbar. Das Test-Setup ist kleiner, weil unnötige Abhängigkeiten nicht bereitgestellt werden müssen. Probleme bei der Testbarkeit und Verständlichkeit entstehen häufig, wenn zu viel auf einmal passiert. Zu wenig ist meistens kein Problem.

Nachteile

Durch viele kleine Methoden und Klassen leidet evtl. die Übersicht über das Gesamtsystem und man findet sich schwieriger zurecht. Dem kann man aber entgegenwirken und es ist erstmal nicht schlimm, viele kleine Klassen anzulegen, anstatt eine große. Dateien kosten nichts. Dateien/Klassen können in IDEs mit Shortcuts schnell gefunden/geöffnet werden. Wenn auf eine vernünftige (einheitliche) Benennung geachtet wird, sind Klassen auch so gut auffindbar. Weitere Konventionen (z.B. die Einordnung in Package-Strukturen) helfen auch bei der Organisation.

Wenn Klassen nur eine einzige Aufgabe haben dürfen, steigt automatisch die nötige Kopplung zu anderen Klassen, weil deren Funktionalität benötigt wird, um die Gesamtaufgabe zu erfüllen. Hier gilt es, einen guten Mittelweg zu finden, der eine möglichst hohe Kohäsion bei gleichzeitg geringer Kopplung ermöglicht.

Literaturempfehlungen

Wie zu fast jedem Wissenshäppchen kann ich jeder/m Anwendungsentwickler/in nur wärmstens Clean Code* von Uncle Bob ans Herz legen. Das SRP wird hier auch erklärt und gleich praktisch angewendet.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

SRP: The Single Responsibility Principle

ArticleS.UncleBob.PrinciplesOfOod

Single-Responsibility-Prinzip

Zusammenfassung

Eine Aufgabe pro Komponente

Robert C. Martin, auch als Uncle Bob und Autor von Clean Code bekannt, beschreibt das Single-Responsibility-Principle (SRP) über den Grund, eine Klasse zu ändern: Für jede Klasse soll es genau einen solchen Grund geben. Wenn du ihre Aufgabe anpasst, änderst du den dazugehörigen Code.

Ich übertrage dieses erste SOLID-Prinzip auch auf Variablen und Methoden sowie auf ganze Programme. Jede dieser Einheiten soll eine klar abgegrenzte Aufgabe erfüllen.

Wie gut gehört der Code zusammen?

Wenn du prüfst, welche Attribute die Methoden einer Klasse verwenden, bekommst du Hinweise darauf, wie eng ihre Bestandteile zusammengehören. Der Fachbegriff dafür ist Kohäsion, auf Englisch Cohesion. Über Softwaremetriken lässt sich dieser Zusammenhang messen.

Greifen verschiedene Methoden jeweils auf völlig getrennte Attribute zu, lohnt sich ein genauerer Blick auf die Aufgaben der Klasse. Darin können mehrere Verantwortlichkeiten stecken.

Wenn ich in einer solchen Klasse ein Attribut ändere, kann das eine weitere Funktion beeinflussen, die ebenfalls darauf zugreift. Solche Fehler erschweren es dir, den Code zu pflegen und ihre Ursache nachzuvollziehen.

Beispiel: Daten speichern und eine E-Mail verschicken

Bei einer Registrierung gehören das Speichern eines neuen Kontos und das Verschicken einer Bestätigungs-E-Mail zum selben fachlichen Ablauf. Technisch sind es eigenständige Aufgaben.

Ich verteile sie auf getrennte Methoden. Die Methode für den Datenbankzugriff kann Ergebnisse liefern, die anschließend als Parameter an die Methode für den E-Mail-Versand gehen. Eine übergeordnete Komponente verbindet die Schritte.

Dadurch kannst du den Datenbankzugriff separat testen. Enthält eine Methode beide Aufgaben, hängt ihr Test zusätzlich vom E-Mail-Versand ab. Ein fehlender Mailserver kann dann einen Test scheitern lassen, der das Speichern prüfen soll.

Auch eine boolesche Variable kann mehrere Aussagen bündeln, etwa "Person ist über 18 und bekommt einen Nachlass". Später lassen sich die einzelnen Prüfergebnisse daraus schwer wieder gewinnen. Wenn du die Bedingungen an dieser Stelle immer gemeinsam brauchst, kann ein gemeinsamer Wert sinnvoll sein.

Hinweise auf mehrere Verantwortlichkeiten

Beim Lesen von Namen und Tests kannst du nach folgenden Anzeichen suchen:

"Und" oder "oder" im Namen: Eine Methode wie "Speichere Konto und verschicke Bestätigungs-E-Mail" beschreibt mehrere Aufgaben.

Allgemeine Klassennamen: Begriffe wie "Manager" oder "Verwaltung" können darauf hinweisen, dass die eigentliche fachliche Aufgabe noch unklar ist. Hier fehlt häufig eine passende Abstraktion, etwa eine getrennte Klasse zum Lesen oder Schreiben von Objekten.

Aufwendige Tests: Wenn du für eine kleine Funktion viele Abhängigkeiten bereitstellen musst, solltest du die Verantwortlichkeiten der Klasse prüfen. Besonders verschachtelte Mocks und Stubs können ein Hinweis sein.

Bei einem Repository sollten die CRUD-Aktionen mindestens eigene Methoden bekommen. Eine einzige Methode, die über einen Aktionsparameter und einen großen Switch entscheidet, was sie tun soll, übernimmt mehrere Aufgaben. Bei einer strengen Auslegung des SRP lassen sich Lesen und Schreiben auch auf eigene Klassen verteilen.

Architektur und Wiederverwendung

Wenn Geschäftslogik fest mit einer Weboberfläche verbunden ist, erschwert das ihren Einsatz in einer Konsolenanwendung. Eine fest eingebaute Datenbankabhängigkeit bindet sie außerdem an diese Datenquelle.

Aus meinem Alltag mit Legacy-Software kenne ich Komponenten, die innerhalb einer Datenbankschleife Geschäftslogik ausführen und Ergebnisse direkt auf einer Oberfläche anzeigen. Um die Logik zu testen, brauchst du dann die Datenbank samt passenden Daten. Wartet die Oberfläche auf Eingaben, muss zusätzlich eine Person eingreifen, was automatisierte Tests behindert.

Die Gott-Klasse ist ein Anti-Pattern, bei dem nahezu das gesamte Programm in einer Klasse steckt. Ein Fehler kann große Teile des Programms beeinträchtigen. Einzelne Funktionen lassen sich wegen der vielen verbundenen Aufgaben schwer isoliert prüfen.

Auf Architekturebene lässt sich derselbe Gedanke bei Microservices wiederfinden: Ein Service bildet eine abgegrenzte Fachlichkeit ab. Änderungen innerhalb dieses Bereichs bleiben dadurch zunächst auf die betreffende Komponente begrenzt. Gemeinsam zugängliche Datenfelder können dagegen dazu führen, dass weitere Komponenten Werte verändern, die fachlich zu einem anderen Bereich gehören.

Was kleine Komponenten erleichtern

Wenn eine Komponente eine klar umrissene Aufgabe erfüllt, enthält sie meist weniger Code. Du kannst sie schneller verstehen und die passende Stelle für eine Änderung leichter finden. Getrennte Verantwortlichkeiten erleichtern außerdem, vorhandenen Code erneut einzusetzen.

Für mich spielt besonders das isolierte Testen eine Rolle. Externe Abhängigkeiten lassen sich dabei durch Mocks oder Stubs ersetzen. Je kleiner der Bereich ist, den du prüfst, desto weniger musst du für den Test vorbereiten.

Überblick und Abhängigkeiten

Durch viele kleine Klassen kann es schwieriger werden,...

Elena Hollen hat ihre Bachelorarbeit über Code Reviews und Extreme Programming geschrieben und erzählt mir alles darüber in der einhundertdreiundzwanzigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit Code Reviews findest du Fehler früh und lernst durch den Austausch über fremden Code. Gemeinsam mit Elena Hollen habe ich bei der Alte Oldenburger erprobt, wie sich Reviews im Arbeitsalltag einführen lassen: In drei Wochen entstanden bei 26 Reviews rund 350 Anmerkungen und 18 gefundene Fehler in 30.000 Codezeilen. Als IT-Azubi kannst du dabei auch erfahrenen Entwickler:innen Feedback geben und andere Lösungswege kennenlernen. Für den Einstieg reichen Kommentare im Code und eine Versionsverwaltung, wobei du Zeit für die Reviews einplanen und respektvoll über den Code sprechen solltest.

Kapitelmarken

[00:00:00] Einstieg ins Thema Code Reviews

[00:01:03] Elena Hollen und ihre Arbeit mit technischen Dokumenten

[00:04:02] Weg in die IT und bevorzugte Programmiersprache

[00:06:24] Bachelorarbeit zu Softwarequalität und Extreme Programming

[00:07:34] Werte und Praktiken von Extreme Programming

[00:09:16] Feedback und Kommunikation durch Code Reviews

[00:10:49] Was ein Code Review ist und welche Formen es gibt

[00:12:06] Qualität und Wartbarkeit durch Reviews verbessern

[00:13:33] Offline-Reviews in der ersten Testphase

[00:15:42] Checklisten und gemeinsame Programmierregeln

[00:17:03] Statische Codeanalyse und Best Practices im Wiki

[00:19:09] Fragebogen zum Auswerten der Reviews

[00:20:53] Ergebnisse aus 26 Reviews

[00:22:25] Austausch über Codequalität im Team

[00:23:48] IT-Azubis reviewen erfahrene Entwickler:innen

[00:25:06] Respektvoll über Code sprechen

[00:26:45] Aufwand und mögliche Schwierigkeiten

[00:28:03] Reviews einführen und in den Arbeitsablauf einbauen

[00:29:54] Fachlichen Kontext geben und Code während der Entwicklung prüfen

[00:30:48] Reviews mit Pair Programming und TDD verbinden

[00:31:32] Fachliche Fehler im Code erkennen

[00:32:09] Anforderungen an Review-Werkzeuge

[00:34:37] Erfahrungen mit Agile Review

[00:35:42] Gemeinsame Snippets und einheitliche Review-Kommentare

[00:37:51] Reviews mit Code-Kommentaren und Versionsverwaltung

[00:38:48] Freiwillige Reviews im weiteren Arbeitsalltag

[00:42:06] Wirtschaftliche Gründe und Unterstützung durch Führungskräfte

[00:45:06] Bücher zu Extreme Programming und Soft Skills

[00:47:30] Fachbücher und weitere Quellen zum Lernen

[00:50:33] Regelmäßige Code Reviews in meiner Ausbildung

[00:51:14] Rückblick und Kontaktmöglichkeiten

Inhalt

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du?

Elena Hollen, Technische Redakteurin bei der ALTE OLDENBURGER Krankenversicherung AG

An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?

Technische Redaktion, Toolauswahl für Code Reviews, viel schreiben, Compliance-Anforderungen, DSGVO, Dokumentation für den Fachbereich

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Nach der Realschule bin ich auf ein Fachgymnasium Wirtschaft gewechselt und habe dort im Abitur bereits etwas über Informatik gelernt, z.B. PHP, HTML, CSS, SQL, Excel. Der Bereich BWL hat mir aber auch viel Spaß gemacht. Ich bin kein "klassischer" Nerd! :-) Aber ich mag es sehr, Probleme zu lösen. Meine persönliche Entscheidung war dann aber nach der Ausbildung, dass ich nicht 24/7 programmieren möchte. Daher habe ich die Stelle als technische Redakteurin angenommen.

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

Ausbildung zur Fachinformatikerin Anwendungsentwicklung, dann duales Studium der Wirtschaftsinformatik in Lingen, aktuell Master in Wirtschaftsinformatik an der Ostfalia.

Was ist deine Lieblingsprogrammiersprache und warum?

Java, da in Ausbildung und Studium gelernt und auch aktuell im Einsatz.

Code Reviews und Extreme Programming

Worum geht es in deiner Bacherlorarbeit (z.B. Thema, Zielsetzung)?

Code Reviews zur Steigerung der Codequalität. Ich habe eine Studie zu Code Reviews bei der ALTE OLDENBURGER durchgeführt. Ziel war die Verbesserung der Kommunikation und Feedback.

Was ist Extreme Programming und wer braucht das?

Extreme Programming wurde von Kent Beck entwickelt. Es legt den Fokus auf den Menschen. Die Werte sind u.a. Feedback und Kommunikation, die Prinzipien z.B. Menschlichkeit und Praktiken sind z.B. TDD und Code Reviews.

Was sind Code Reviews?

Eine manuelle Prüfung von Code ohne Automatisierung. Der Code, der von einem Autor erstellt wird, wird von einem Reviewer kontrolliert.

Was sind die Ziele von Code Reviews?

Fehler finden, Selbstkontrolle, Einheitlichkeit des Codes, langfristige Wartbarkeit.

Welche Varianten von Code Reviews gibt es?

Walkthrough, Review mit Checkliste, Inspektion mit detaillierten Phasen.

Was wurde bei der AO gemacht?

Einfache Reviews ohne Checkliste. Es gab einen Leitfaden mit Fragen, z.B. Anzahl Lines of Code gereviewt, Fehler/Anmerkungen gefunden, technischer Mehrwert und was habe ich gelernt? Die Auswertung war auch eine gute Begründung für den Chef. Es gab eine Testphase mit 17 Entwicklern, die 1x pro Woche ein Review durchgeführt haben. Insgesamt wurden 26 Reviews durchgeführt.

Was sind die Vor- und Nachteile von Code Reviews?

Vorteile: Einfacher Start ohne großen Aufwand möglich. Eine Checkliste sollte gemeinsam erarbeitet werden. Best Practices ergeben sich im Prozess.

Nachteile: Gefühl von Kontrolle. Es entstehen Kosten (Arbeitszeit), der Chef sollte also gefragt werden.

Was sind die Ergebnisse deiner praktischen Studie zu Code Reviews in der AO?

30.000 LOC gereviewt, 18 Fehler gefunden, 350 Anmerkungen geschrieben, Wissenssilos aufgebrochen, viel gelernt (jeder Teilnehmer), Anregung über Qualität nachzudenken, Austausch mit anderen Entwicklern, keine Probleme aufgetreten, zwischenmenschlich hat es super geklappt.

Welche praktischen Tipps für die Einführung von Code Reviews hast du?

Zu Beginn muss oft eine ablehnende Haltung der Entwickler überwunden werden. Ein Kümmerer als Ansprechpartner ist nötig. Eine Integration in den Entwicklungsprozess ist nötig. Das Feedback der Teilnehmer muss berücksichtigt werden. Zu Beginn sollte erstmal eine Einführung in den zu reviewenden Code gegeben werden, damit der Reviewer weiß, worum es geht. Perfekter Code ist nicht nötig! Fachliche Fehler können gefunden werden.

Macht Pair Programming Code Reviews überflüssig?

Nein, sie bilden eine Symbiose, auch TDD passt gut dazu.

Können auch Azubis schon Code Reviews durchführen?

Ja! Ein Austausch mit langjährigen Entwicklern war möglich. Andere Meinungen werden diskutiert. Es wurden viele Fragen gestellt. Und sogar Anmerkungen von Azubis wurden umgesetzt.

Welche Tools benötigt man für Code Reviews?

Erstmal sind keine Tools nötig, Kommentare im Code reichen. Tool ist evtl. Overkill im Prozess. Es gibt aber viele Tools am Markt. Zunächst sind die eigenen Anforderungen zu klären und dann ein Tool zu suchen (z.B. IDE-Plugin, Git, keine DB, Gruppenverwaltung). Fehler vs. Anmerkungen sollten unterschieden werden können.

Wie geht es mit den Code Reviews bei der AO weiter?

Jeder Entwickler entscheidet selbst, ob und wie oft Code Reviews durchgeführt werden. Tool suchen. Es gibt keine Kontrolle, die war nur für die Bachelorarbeit nötig. Langfristige Motivation ist nötig, ein Kümmerer ist sinnvoll. Code Reviews werden bereits in die Ausbildung integriert.

Kann man die Einführung von Code Reviews auch monetär begründen?

Na klar! Wann sind Fehler am teuersten? Wenn der Code schon auf der Produktion läuft! Wir haben in 3 Wochen 18 Fehler gefunden, und zwar vor derm Deployment! Das Management muss von Anfang an einbezogen werden.

Aus- und Weiterbildung

Was ist das letzte Fachbuch mit Bezug zur Programmierung, das du selbst gelesen hast?

Soft Skills von John Sonmez.

Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum?

Extreme Programming Explained von Kent Beck (bitte auf Englisch!).

Welche Quellen kannst du für die Aus- und Weiterbildung im Bereich Programmierung empfehlen und warum?

Wissenschaftliches Arbeiten macht Spaß und man lernt sehr viel dabei. Quellen sind u.a. Springerlink und Google Scholar.

Auf GitHub findet man viel Code, an dem man selbst lernen kann.

Abschluss

Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?

Auf Xing, LinkedIn oder Twitter.

Literaturempfehlungen

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Snipmatch

AgileReview

Zusammenfassung

Wie Elena zum Thema kam

Bei der Alte Oldenburger hat Elena Hollen ihre Ausbildung zur Fachinformatiker:in für Anwendungsentwicklung bei mir abgeschlossen und anschließend Wirtschaftsinformatik studiert. Nach ihrem Bachelor begann sie ein berufsbegleitendes Masterstudium. Beruflich schreibt sie technische Dokumente und kümmert sich darum, wie diese geordnet und gepflegt werden. Dabei arbeitet sie mit Fachabteilungen und IT-Kolleg:innen zusammen, etwa wenn Abläufe beschrieben oder rechtliche Vorgaben berücksichtigt werden müssen.

Über den Informatikunterricht am Wirtschaftsgymnasium fand sie zur Anwendungsentwicklung. Java blieb ihre bevorzugte Programmiersprache, auch nachdem sie sich beruflich stärker mit Dokumenten beschäftigte.

Der Bezug zu Extreme Programming

Für ihre Bachelorarbeit untersuchte Elena, wie Praktiken aus Extreme Programming (XP) die Softwarequalität im Unternehmen verbessern können. Das von Kent Beck entwickelte agile Vorgehen richtet sich an kleine bis mittelgroße Projekte und stellt die Menschen, die Software entwickeln, in den Mittelpunkt.

Aus abstrakten Werten ergeben sich Prinzipien, aus denen konkrete Praktiken folgen. Beispielsweise gehört Feedback zu den Werten; Test-Driven Development ist eine konkrete Praktik. Code Reviews greifen den Wunsch nach Rückmeldungen auf und schaffen einen Anlass, mit anderen Entwickler:innen über Code zu sprechen.

Bei der Alte Oldenburger kamen bereits einzelne XP

Über das spannende Thema User Experience (UX) und Usability spreche ich mit Patrick Ziegler in der einhundertzweiundzwanzigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Ich spreche mit Patrick Ziegler darüber, wie du als Fachinformatiker:in Anwendungsentwicklung Software gestaltest, die zu den Aufgaben deiner Benutzer:innen passt. Usability beschreibt die Gebrauchstauglichkeit während der Bedienung; User Experience umfasst auch Erwartungen vorab und Eindrücke danach. Wenn du früh mit deiner Zielgruppe sprichst und einfache Prototypen testest, kannst du Anforderungen genauer bestimmen und Nutzungsprobleme früh erkennen. Für den Einstieg helfen dir die Dialogprinzipien der ISO 9241, UI-Guidelines und überschaubare Usability-Tests im eigenen Betrieb.

Kapitelmarken

[00:00:00] Einführung in Usability und User Experience

[00:00:48] Patrick Ziegler und sein Weg zur UX-Arbeit

[00:05:26] CPUX und berufliche Qualifikation

[00:07:00] Systematisch Produkte gestalten: das PiepEi

[00:10:59] Arbeitsumfeld verstehen und technische Erfahrung einbringen

[00:15:38] Methoden auswählen in der Zertifizierungsprüfung

[00:17:22] Usability und User Experience verstehen

[00:20:06] Zielgruppen und Gebrauchstauglichkeit

[00:22:01] Eindrücke nach dem Gebrauch und Markenimage

[00:23:44] SAP-Beispiel und Oberflächen für unterschiedliche Rollen

[00:26:27] Nutzungsfehler und Dialogprinzipien

[00:28:28] Formulare und Eingaben verständlich gestalten

[00:31:42] User Journey und lautes Denken im Test

[00:33:01] UI-Guidelines und etablierte Interaktionsmuster

[00:37:15] Die Funktionssuche in Microsoft Office

[00:40:10] Ideen finden und konkrete Probleme untersuchen

[00:42:47] Erfordernisse und Anforderungen lösungsneutral formulieren

[00:45:49] Beispiele: Heizung und Flipchart-Marker

[00:49:42] Interviews und Befragungen auswerten

[00:50:24] Anforderungen als Entwickler:in hinterfragen

[00:53:41] Fokusgruppen und früher Kontakt zur Zielgruppe

[00:56:03] Papierprototypen und digitale Entwürfe

[00:58:31] Mit Lego schrittweise zum MVP

[01:00:14] Walking Skeleton und vollständige Anwendungsfälle

[01:02:16] Agile Projekte und agiler Festpreis

[01:04:36] Usability-Tests im eigenen Betrieb

[01:07:37] Anwendungen anhand von Kriterien inspizieren

[01:09:05] Arbeitsergebnisse: Click-Dummy und User Journey

[01:11:58] Wireframes und visuelle Gestaltung

[01:14:49] Affordance und vertraute Bedienmuster

[01:16:56] UX als gesamter Prozess und interdisziplinäre Zusammenarbeit

[01:20:22] Plattformwahl und Internetverbindung im Arbeitsumfeld

[01:21:26] UX in den Entwicklungsprozess einbinden

[01:24:12] Meetups und Don't Make Me Think

[01:27:09] Trainings, Blogs und weitere Quellen für den Einstieg

[01:32:58] Unterschiedliche Perspektiven im Team

[01:34:31] IT-Azubis in echte Aufgaben einbeziehen

[01:37:13] Datenbanken, Sicherheit und Algorithmen praktisch vermitteln

[01:40:38] Ideen von IT-Azubis und Design Thinking

[01:42:53] Patricks technische Arbeit und R für Datenanalysen

[01:45:57] Buchempfehlung: The Clean Coder

[01:47:22] Kontakt zu Patrick Ziegler

[01:49:42] Hinweise zu Shownotes und weiteren Beiträgen

Inhalt

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du (falls gewünscht)?

Patrick Ziegler, Agentur für Design und Beratung mit ~15 MA

An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?

Relaunch einer Webseite (Konzeption, Design, Rollout), Prozessanalysen, Schulgründung

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Umwege über Studium, Lehramt, Soziologie, IT, ursprünglich Zocken, später dann Hinterfragen "Wie geht das eigentlich?"

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

Fachinformatiker Anwendungsentwicklung

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Notgedrungen AppleScript ;-), sonst aber C#, JavaScript (Angular, React), R

Was ist deine Lieblingsprogrammiersprache und warum?

R, weil sie unglaublich schlank und elegant ist, sonst an sich das ETL-Framework SSIS

Usability und User Experience

Was sind Usability und User Experience?

Usability = Gebrauchstauglichkeit, User Experience = Vor Benutzung, Während der Benutzung, Nach der Benutzung

Warum brauchen wir UX?

Weil ohne gute Benutzbarkeit Produkte nicht oder nur ungern genutzt werden. Auch: Fehleranfällig

Welche Beispiele gibt es für gute UX?

Neuland-Marker. Farbe hinten drauf, "Rollböppel"

Welche Beispiele gibt es für schlechte UX und was hätte man anders machen können?

SAP, Norman Doors

Wie misst bzw. testet man die UX seiner Software?

Net Promoter Score, Quantitative und Qualitative Benutzerbefragungen

Hat UX auch etwas mit ansprechendem Design zu tun?

Ja, wobei visuelle "Ästhetik" keine so große Rolle spielt wie ein sauber designter Prozess

Was macht ein UX-Experte?

Konzeption, Entwurf und Umsetzung oder Begleitung von kompletten Projekten oder UX-Teilen aus Projekten, (Wireframes, Prototypen, Workshopplanung und Durchführung, Benchmarking, Interviews, Usability-Tests, Fokusgruppen)

Wie wird man zum UX-Experten?

Da gibt es verschiedene Optionen, zum einen relativ klassisch über das Studium. Es gibt direkt Studiengänge "User Experience Design", die sich mit der Thematik beschäftigen. Oder für den digitalen Background Mensch-Computer-Design. Oder eben Industriedesign, alles Studiengänge mit hohem Grad an Benutzerfokussierung. Alternativ dazu gibt es die Option, den Weg über Zertifizierungen zu gehen. Da ich selbst 3 Kinder habe und für ein Vollzeitstudium momentan keine Kapazitäten vorhanden sind, habe ich diesen Weg gewählt. Das UXQB (User Experience Qualification Board) ist eine Organisation, die aus dem Deutschen Berufsverband der Usability Professionals (UPA) gegründet wurde. Da gibt es verschiedene Trainings, eins davon habe ich im Fachinformatiker-Forum auch schon in einem Blog-Post rezensiert.

Welche Tools oder Methoden setzen UX-Experten ein?

Da gibt es ganz verschiedene Ansätze. Entweder man geht über die emotional-kreative Route, wählt den analytischen Weg, oder nutzt eine Mischung aus beidem. Je nach Problem. Geht es eher um ein konkretes Problem, empfiehlt sich meiner Erfahrung nach eher ein analytischer Ansatz aus Fokusgruppen, A/B-Tests und konkreten, sogenannten kontextuellen Interviews mit vom Problem betroffenen.

Soll eine Innovation geschaffen werden ohne ein konkretes Problem, sind es oft eher Methoden aus dem Bereich Design Thinking und Ideation, die zum Einsatz kommen. Da geht es erstmal darum, zu potentiellen Geschäftsfeldern einer Firma möglichst viel Input zu sammeln, der dann in späteren Runden und Iterationen verdichtet und konkretisiert wird.

Zum Tooling kommt es auch auf das Problem an. Oft zum Einsatz kommen aber verschiedene Tools zum Erstellen von Wireframes oder Klickdummies, zumindest bei Softwareprojekten. Für eher analogere Ansätze tun es oft auch Skizzen oder neuerdings 3D-Drucke. Was man aus dem Rapid Prototyping eben so kennt. Die steigende Menge an Makerspaces, die es in vielen Städten gibt, ist da durchaus von Vorteil.

Was können Softwareentwickler tun, um ihre Software benutzerfreundlicher zu gestalten?

Zu allerst einmal den Benutzern zuhören, deren Problem die Software lösen soll, damit auch alle am Projekt Beteiligten wissen, worum es geht. Bei "neuen" Problemen empfiehlt sich zudem meiner Erfahrung nach eine iterative Vorgehensweise, z.B. Scrum. Was viele Entwickler gar nicht wissen, ist, dass es für so ziemlich alle Systeme und von allen Herstellern sogenannte Styleguides gibt, die schon jahrelang gesammeltes Wissen rund um die Gestaltung von Benutzeroberflächen enthalten. Z.B. von Apple, Microsoft, Google, Oracle und SAP.

Darüberhinaus ist es natürlich immer gut, in regelmäßigen Usability-Tests (idealerweise vor und nach einem Release zu Vergleichsgründen) abzufragen, wie bestimmte Features angenommen werden. Wichtig ist hier meiner Einschätzung nach besonders, mit tatsächlichen potentiellen Nutzern zu sprechen, nicht mit Käufern der Software.

Gibt es konkrete Tipps, um bei der täglichen Arbeit UX miteinzubeziehen?

Es gibt ein großartiges Buch für Entwickler von Software mit dem Namen Don't make me think*, dessen Lektüre ich jedem wärmstens ans Herz legen kann. Das oberste Credo ist hier für mich insgesamt, das eigene Ego hinten anzustellen und das Bedürfnis der Benutzer an oberste Stelle zu setzen. Um bzgl. der Methoden und Co. auf dem aktuellen Stand zu bleiben, lohnt es darüber hinaus, sich mit anderen Leuten zu vernetzen, auf Meetups zu gehen und/oder diverse Newsletter rund um das Thema zu lesen (z.B. Nielsen Norman Group).

Wie sieht ein Entwicklungsprozess aus, der UX optimal einbindet?

Da gibt es tatsächlich einen in der ISO 9214 spezifizierten Prozess für, nämlich den "Prozess für menschzentrierte Gestaltung". Allgemein ist aber jedes Projektvorgehen, das Iterationen und regelmäßige Lieferungen an Benutzer vorsieht gut geeignet, für eine gute Benutzererfahrung zu dienen.

Aus- und Weiterbildung

Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen?

Momentan nicht, bei meinem letzten Arbeitgeber habe ich das aber getan. Mein Vorgehen als solches war, Azubis und Praktikanten so oft wie möglich auf Augenhöhe in Problemlösungen mit einzubeziehen und sie da abzuholen, wo sie grade stehen.

Was ist das letzte Fachbuch mit Bezug zur Programmierung, das du selbst gelesen hast?

Das ist schon eine Weile her und dürfte The Clean Coder* von Robert C. Martin gewesen sein. Wobei das eher ein permanent genutztes Arbeitsbuch als ein "Einmal gelesen und dann weggelegt"-Buch ist. Momentan bin ich eher auf Meta- und Projektebene in Printliteratur unterwegs und lese Beiträge mit Programmierbezug meist online.

Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum?

Ich muss gestehen, so viel technische Literatur mit IT oder Programmierbezug lese ich gar nicht. Das oben schon angesprochene Don't make me think*

Ein spannendes Interview mit Martin Helmich zum Thema Docker gibt es in der einhunderteinundzwanzigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit Martin Helmig gehe ich der Frage nach, wie Docker dir als IT-Azubi beim Entwickeln hilft: Container kapseln Anwendungen samt Laufzeitumgebung, lassen sich schnell starten und über Images automatisiert bereitstellen. Dadurch kannst du deine produktive Umgebung lokal nachbauen und dieselben Images später auf einem Server betreiben. Kubernetes verteilt Container auf mehrere Server, wobei du dich um dauerhaften Speicher und die Netzwerkanbindung kümmern musst. Für deine Anwendungen spielen dabei möglichst zustandslose Prozesse und klar beschriebene Abhängigkeiten eine Rolle.

Kapitelmarken

[00:00:00] Einführung in Docker und Containerisierung

[00:01:12] Martin Helmig und seine Arbeit bei Mittwald

[00:02:22] Ausbildung, Studium und der Einstieg in Docker

[00:05:18] Programmiersprachen im Arbeitsalltag

[00:08:14] Go: Typsicherheit und ausführbare Programme

[00:11:40] Was Docker ist und wie Container funktionieren

[00:14:16] Container und virtuelle Maschinen

[00:15:52] Schnell starten und Abläufe automatisieren

[00:17:23] Infrastructure as Code und Immutable Infrastructure

[00:20:22] Kubernetes und Container-Orchestrierung

[00:22:32] Container-Netzwerke und externe Zugriffe

[00:24:43] Vorteile für deinen Entwicklungsalltag

[00:29:18] Docker unter Windows

[00:32:08] Software aktualisieren und Container ersetzen

[00:33:38] Basis-Images und differenzielle Schichten

[00:36:51] Go, PHP und geeignete Anwendungsarchitekturen

[00:40:32] Desktop-Anwendungen, Kommandozeilentools und Batch-Jobs

[00:43:35] Container-Landschaften und Kubernetes bei Mittwald

[00:45:53] Dauerhafte Daten und Netzwerkspeicher

[00:48:50] Herausforderungen beim produktiven Cluster-Betrieb

[00:50:57] Einarbeiten und mit Minikube ausprobieren

[00:52:31] Anwendungen für Container entwickeln

[00:55:20] Weitere Container-Lösungen: rkt, LXC und LXD

[00:57:27] IT-Ausbildung und interne Trainings

[00:58:32] Barcamps und Austausch im Unternehmen

[01:02:44] Neue Themen praktisch erlernen

[01:04:44] Buchempfehlung: The Clean Coder

[01:06:11] Kontakt zu Martin Helmig

[01:07:44] Docker in der Ausbildung und Shownotes

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du?

Martin Helmich von Mittwald.

An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?

Einsatz von Containern in Hosting-Umgebungen.

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Als Kind schon mit dem Programmieren angefangen.

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

Wirtschaftsinformatik (Bachelor) an der PHWT Vechta und danach Master in Informatik mit Schwerpunkt Mobile Anwendungen an der Hochschule Osnabrück.

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

JavaScript (NodeJS), Go, PHP.

Was ist deine Lieblingsprogrammiersprache und warum?

Go, weil sie Vieles besser/einfacher/sicherer macht als C.

Docker

Was ist Docker?

Eine Software zur Containervirtualisierung.

Warum gibt es aktuell so einen Hype rund um Docker?

Wird viel im Zusammenhang mit DevOps verwendet. Container sind in aller Munde. Viele Buzzwords, die durch die Entwicklerszene geistern.

Warum nimmt man nicht einfach die "guten alten" virtuellen Maschinen?

Zu aufwändig für einzelne Services/Prozesse. Kleiner und leichter zu (ver-)teilen (siehe Docker Hub). Bessere Performance. Einfache Automatisierung.

Was hat das Ganze mit "infrastructure as code" zu tun?

Bei Docker spricht man eher von "immutable infrastructure", also zustandsloser Infrastruktur.

Wozu braucht man in der Praxis Container?

Infrastrukturbetrieb soll einfacher werden. Leicht in die Breite zu skalieren.

Was ist Kubernetes und wofür braucht man das?

Docker kann nicht selbst clustern usw. Kubernetes oder Docker Swarm sind Container Orchestrators, die das übernehmen. Kubernetes ist der de-facto Standard. Die Orchestrierer abstrahieren von der konkreten Infrastruktur (Hardware, Netzwerk usw.). Wichtig, wenn Container untereinander kommunizieren sollen, z.B. Webanwendung mit Datenbank.

Welche Vorteile bieten mir als Softwareentwickler Container?

Entwicklungs-/Produktionsumgebung exakt nachbauen. Versionen und Abhängigkeiten exakt nachstellen. Zielumgebung für Deplyoment kann durch Entwickler vorgegeben werden. Spart Zeit und gibt Sicherheit beim Deployment. Fehler können besser nachgestellt werden. Verhindert das "Works on my machine"-Syndrom.

Ist der Einsatz von Docker auch auf auf Windows möglich?

Man kann Linux-Container unter Windows starten. Man kann auch Windows-Container starten.

Wie (einfach) aktualisiert man vorhandene Container (z.B. bei Betriebssystemupdates)?

Ein Container soll sich eigentlich nicht mehr ändern. Images können auf Basis neuer Images neu gebaut werden. Das Basisimage ist z.B. Ubuntu und nur die Unterschiede werden in den darüberliegenden Containern gespeichert. Docker ist sehr intelligent, wenn es um das Ermitteln der Deltas geht.

Gibt es Programmiersprachen oder -umgebungen, die sich besonders gut zum Einsatz in Containern eignen?

Eigentlich geht alles.

Für welche Applikationen/Unternehmen eignet sich der Einsatz von Containern besonders gut? Nur für Webanwendungen?

Das Schreiben von Daten geht nicht und muss auf externe Speicher umgeleitet werden. Am besten fährt man den Container hoch und fasst ihn nie wieder an. Es gibt auch Kommandozeilentools, die als Container verpackt werden und z.B. ein komplettes Java mit allen Abhängigkeiten mitbringen.

Wofür setzt du konkret Docker ein? Welche Vorteile hast du dadurch?

Aufbau einer Containerlandschaft z.B. für TYPO3-/Wordpress-Hosting. Automatisierung dieser Infrastruktur mit Kubernetes und Erweiterung von Kubernetes um eigene Funktionen.

Wo speichern die Datenbanken ihre Daten?

Extern gemountete Partitionen können persistenten Speicher bereitstellen. Netzwerk-Storages werden auch von Kubernetes angeboten und sind transparent durch Kubernetes vom konkreten Dateisystem abstrahiert.

Gibt es deiner Erfahrung nach auch Probleme/Nachteile beim Einsatz von Docker?

Netzwerkspeicher und Datenbanken können umziehen. (IP-)Adressen ändern sich. Zustandslosigkeit der Services ist Voraussetzung. Das interne Netzwerk führt ggfs. zu Latenzen. Traffic von außen in das Containernetzwerk zu bekommen und Load Balancer einzurichten könnte schwierig sein. Initial ist es ein hoher Aufwand, die Infrastruktur ans Laufen zu bekommen. Es gibt aber z.B. Minikube als Startprojekt oder man startet direkt in der Cloud, z.B. mit AWS oder Azure.

Ist die Architektur der Anwendung betroffen? Was hat Docker z.B. mit Microservices/DDD zu tun?

Das Dateisystem kann wechseln, IP-Adressen ändern sich, root-Rechte sollten nicht erforderlich sein. Microservices passen gut in Container, aber das Umgekehrte gilt nicht zwingend.

Gibt es Alternativen zu Docker?

rkt, LXC, LXD. Aber Docker ist der Platzhirsch.

Aus- und Weiterbildung

Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen?

Nein, ich arbeite eher bei innerbetrieblichen Fortbildungen mit. Wir haben z.B. ein Barcamp bei Mittwald durchgeführt. Außerdem nehme ich an Konferenzen teil.

Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum?

The Clean Coder* von Uncle Bob.

*

Wie bildest du dich selbst weiter?

Einfach anfangen! Z.B. ein Tutorial durcharbeiten. Ich bin eher "hands on", Bücher funktionieren bei mir nicht so gut.

Mehr über Martin und Mittwald

Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?

Auf meiner Website oder bei GitHub.

Mehr über Mittwald gibt es auf der Website und der speziellen Karriereseite.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Zusammenfassung

Martin Helmigs Weg zur Softwarearchitektur

Mein Gesprächspartner Martin Helmig arbeitet als Systemarchitekt bei Mittwald und beschäftigt sich dort mit Container-Infrastrukturen. Er begann als Kind zu programmieren und verband später eine Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung mit einem dualen Studium der Wirtschaftsinformatik. Anschließend absolvierte er einen Informatik-Master mit dem Schwerpunkt verteilte und mobile Anwendungen.

In seiner betrieblichen Masterarbeit untersuchte er, wie sich eine über Jahrzehnte gewachsene PHP-Anwendung in eine moderne Architektur überführen lässt. Dabei beschäftigte er sich mit Microservices und Docker.

Für eigene Projekte arbeitet Martin vor allem mit Node.js samt TypeScript oder mit Go. An Go schätzt er die statische Typisierung, durch die der Compiler Fehler früh erkennen kann. Die Sprache kompiliert zu nativem Maschinencode und kommt mit wenig Speicher aus. Zahlreiche Bibliotheken erleichtern ihm die Arbeit; außerdem übernimmt die Sprache das Speichermanagement. Passend kompilierte Go-Anwendungen lassen sich als eigenständige ausführbare Datei verteilen.

Wie Docker-Container funktionieren

Docker isoliert Prozesse, die auf demselben Rechner laufen. Ein Container erhält dafür eine eigene Umgebung mit einem Dateisystem. Üblicherweise läuft darin ein einzelner Dienst, etwa ein Webserver oder ein Applikationsserver.

Alle Container teilen sich den Betriebssystemkern des Hosts. Eine virtuelle Maschine besitzt einen eigenen Kernel und bringt ein vollständiges Betriebssystem mit. Bei Docker beschränkt sich die Umgebung auf das, was der jeweilige Dienst braucht. Zusätzliche Systemdienste wie ein SSH-Server gehören üblicherweise nicht dazu.

Der gemeinsame Kernel bestimmt, welche Container direkt auf einem Host laufen können. Für einen Windows-Container ist ein Windows-Kernel erforderlich.

Docker stellt Werkzeuge bereit, mit denen du Images bauen und Container daraus starten kannst. Ein Image enthält das Dateisystem und die benötigte Software. Du beschreibst, wie es aufgebaut werden soll, und kannst den Ablauf automatisieren....

Den Abschluss der Episodenreihe zum Thema Cloud Computing bilden die Themen Auswahlkriterien für eine Cloud-Plattform und mögliche IHK-Aufgaben in der einhundertzwanzigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Für die Wahl einer Cloud-Plattform habe ich sechs Kriterien zusammengestellt, mit denen du die Anforderungen deiner Anwendung prüfen kannst: Kosten, Skalierbarkeit, Ausfallsicherheit, Datenschutz, Datensicherheit und Abhängigkeiten vom Anbieter. Nichtmonetäre Kriterien kannst du in einer Nutzwertanalyse gewichten und bewerten. Für deine IHK-Prüfung gehören außerdem die Cloud-Modelle und Service-Level-Agreements zum Lernstoff, wobei viele Aufgaben dein vorhandenes Grundwissen auf einen Cloud-Anwendungsfall beziehen.

Kapitelmarken

[00:00:01] Abschluss der Cloud-Computing-Reihe

[00:01:00] Kriterien für die Wahl einer Cloud-Plattform

[00:01:49] Entscheidungen mit einer Nutzwertanalyse begründen

[00:03:19] Kosten für Hardware, Cloud-Dienste und Personal

[00:06:42] Skalierbarkeit bei Lastspitzen und neuen Projekten

[00:08:52] Ausfallsicherheit und Betrieb rund um die Uhr

[00:12:12] Datenschutz und Serverstandort

[00:14:59] Datensicherheit und mögliche Angriffe

[00:17:40] Abhängigkeiten von Cloud-Anbietern

[00:20:04] Support und Aufwand beim Anbieterwechsel

[00:21:19] Eingestellte Dienste und langfristig verfügbare Laufzeitumgebungen

[00:23:57] Cloud Computing als Thema der IHK-Prüfung

[00:25:37] Grundwissen auf Cloud-Aufgaben anwenden

[00:27:26] Infrastructure, Platform und Software as a Service

[00:27:55] Public, Private und Hybrid Cloud

[00:29:37] Vor- und Nachteile sowie Kosten berechnen

[00:30:37] Rechtliche Aspekte und Service-Level-Agreements

[00:31:38] Neue Cloud-Themen und das Fachgespräch

[00:33:37] Shownotes und Kontakt

Inhalt

Kriterien für die Auswahl einer Plattform/eines Anbieters

Kosten

Wie wichtig ist Kostentransparenz?

Muss evtl. auf eigene Mitarbeiter verzichtet werden?

Wie viel Leerlauf erzeugt die Anwendung?

Wie viel Last erzeugt die Anwendung?

Skalierbarkeit

Gibt es Lastspitzen, die abgefangen werden müssen?

Ist ein großes Kundenwachstum zu erwarten?

Soll vielleicht nur ein Testballon gestartet und danach alles wieder eingestampft werden?

Ausfallsicherheit

Muss die Anwendung im 24/7-Betrieb laufen?

Wie hoch ist der finanzielle Verlust im Fall eines Ausfalls?

Gibt es harte Anforderungen bzgl. Antwortzeiten?

Datenschutz

Werden personenbezogene Daten verarbeitet?

Müssen die Server in Deutschland stehen?

Wurde der eigene Datenschutzbeauftragte befragt?

Datensicherheit

Was passiert, wenn der Anbieter gehackt wird?

Was passiert, wenn wir selbst gehackt werden?

Wie wird Datensicherheit im Unternehmen behandelt?

Ist das nötige Know-How vorhanden?

Abhängigkeit

Dürfen etwaige Kernkompetenzen aus der Hand gegeben werden?

Können wir uns von einem ausländischen Anbieter abhängig machen?

Wie schnell reagiert der Anbieter auf unsere Anfragen?

Was passiert, wenn der Anbieter den Dienst einstellt oder verändert?

Wird die verwendete Programmiersprache überhaupt (langfristig) angeboten?

Mögliche Aufgaben in der IHK-Prüfung

Cloud Computing wird oft als Aufhänger für grundlegende Fragen wie Sicherheit, Datenschutz, Energieverbrauch usw. genommen.

XaaS voneinander abgrenzen und Vor-/Nachteile nennen.

Public vs. Private vs. Hybrid Cloud.

Vor-/Nachteile nennen von Cloud und On Premise nennen, z.B. Auslastung der Server, Skalierbarkeit, Kosten, Time to Market.

Strom- bzw. Betriebskosten berechnen und mit Alternativen vergleichen.

Rechtliche Aspekte: Datenschutz, Service Level Agreements (SLA)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Amazon-Mitarbeiter legte mit Tippfehler Teile des Internets lahm

Warum ein Ausfall bei Amazon große Teile des Internets lahmlegte

Zusammenfassung

Eine Cloud-Plattform auswählen

Wenn du eine Anwendung in die Cloud bringen möchtest, hängt die passende Plattform vom konkreten Projekt ab. Dabei kommen unterschiedliche Betriebsmodelle infrage, vom eigenen Server bis zu Angeboten wie Infrastructure as a Service oder Software as a Service.

Für eine Nutzwertanalyse kannst du nichtmonetäre Kriterien festlegen, die möglichen Lösungen mit Punkten bewerten und diese Punkte gewichten. Aus den gewichteten Werten berechnest du einen Gesamtwert, der deine Entscheidung nachvollziehbar macht. Das Verfahren eignet sich auch für dein Abschlussprojekt und dessen Dokumentation. Die Kosten behandelst du als monetäres Kriterium gesondert.

Kosten

Hardware kaufen: Für eigene Server brauchst du Geld zu Beginn des Projekts. Dieses Geld bleibt in der Hardware gebunden. Gerade bei einem kleinen Unternehmen kann das verfügbare Budget die Entscheidung beeinflussen.

Laufende Cloud-Kosten: Cloud-Dienste werden beispielsweise monatlich oder nach Last abgerechnet. Bei Function as a Service hängt der Preis von den Aufrufen ab. Wenn du deren Anzahl schwer abschätzen kannst, werden auch die Ausgaben schwerer planbar.

Personal einplanen: Eigene Server müssen betreut werden. Dafür brauchst du Administrator:innen oder Entwickler:innen, die während dieser Arbeit weniger Zeit zum Programmieren haben.

Auslastung berücksichtigen: Prüfe, wie viel Last deine Anwendung erzeugt und wie lange Ressourcen unbeschäftigt bleiben. Eine kurze Lastspitze kann dazu führen, dass du leistungsfähige Hardware anschaffst, deren Kapazität während eines großen Teils des Jahres frei bleibt.

Skalierbarkeit

Bei saisonalen Lastspitzen oder einem erwarteten Zuwachs an Kund:innen kann es sinnvoll sein, die Kapazität schnell anzupassen. Wie viel Skalierbarkeit du brauchst, ergibt sich aus dem Verlauf der Last deiner Anwendung.

Auch wenn du eine Produktidee ausprobieren möchtest, kannst du mit wenig Cloud-Kapazität starten. Steigt die Nachfrage, erhöhst du die Ressourcen. Beendest du den Versuch, kannst du den gebuchten Server wieder abbestellen. Berücksichtige bei deiner Entscheidung deshalb auch, wie lange das Projekt laufen soll und wie sicher du die Nachfrage einschätzen kannst.

Ausfallsicherheit und Antwortzeiten

Für eine interne Geschäftsanwendung können die Arbeitszeiten bestimmen, wann sie erreichbar sein muss. Bei einem Online-Shop oder dem Backend einer mobilen App können Kund:innen auch nachts zugreifen.

In meinem Unternehmen können Versicherte über eine App Arztrechnungen einreichen. Weil sie das auch am Wochenende und außerhalb der Geschäftszeiten tun, muss die Anwendung rund um die Uhr erreichbar sein.

Prüfe für dein Projekt:

Zu welchen Zeiten muss die Anwendung laufen?

Welchen finanziellen Schaden verursacht ein Ausfall?

Welche Antwortzeiten wurden vertraglich vereinbart?

Wer kümmert sich um eine Störung, wenn sie nachts auftritt?

Große Cloud-Anbieter beschäftigen Fachleute, die ihre Infrastruktur betreiben und nach Störungen wiederherstellen. Auch dort können ganze Rechenzentren ausfallen. Während einer solchen Störung bist du darauf angewiesen, dass der Anbieter sie behebt; auf dessen Hardware kannst du selbst nicht zugreifen.

Datenschutz

Sobald deine Anwendung personenbezogene Daten verarbeitet, musst du die rechtlichen Vorgaben beachten. Dazu gehören etwa Namen und unter bestimmten Umständen auch IP-Adressen. Der rechtliche Rahmen umfasst das Bundesdatenschutzgesetz und die DSGVO, deren Start im Podcast für Mai 2018 angekündigt wird. Verstöße können hohe finanzielle Folgen haben.

Bevor du dich für einen Anbieter entscheidest, klärst du, welche Daten verarbeitet werden und welche Vorgaben für den Serverstandort gelten. Beziehe deine:n Datenschutzbeauftragte:n ein, sofern dein Unternehmen eine solche Stelle hat. Dabei ist auch zu prüfen, welche Rolle ein ausländisches Unternehmen hinter dem Cloud-Angebot spielt, selbst wenn dessen Rechenzentrum in Deutschland steht.

Datenschutzanforderungen können eine Lösung ausschließen. Für die sensiblen Gesundheitsdaten in meinem Krankenversicherungsunternehmen kommt ein Wechsel in die Cloud unter den beschriebenen Bedingungen kaum infrage.

Datensicherheit

Bei der Entscheidung gehören mögliche Angriffe auf den Cloud-Anbieter ebenso in die Prüfung wie Angriffe auf dein eigenes Unternehmen. Entscheidend sind die internen Sicherheitsrichtlinien und das vorhandene Fachwissen.

Große Anbieter beschäftigen Sicherheitsexpert:innen und betreiben aufwendig abgesicherte Infrastruktur. Ihre Plattformen sind zugleich attraktive Ziele für Angreifer:innen. Für eigene Server musst du klären, ob dein Unternehmen ausreichend Fachwissen hat, um sie abzusichern.

Ein eigenes Servernetz ohne Verbindung zum Internet begrenzt Angriffe von außen. Angriffe durch Mitarbeiter:innen bleiben dabei ein Risiko. Wie sicher eine Lösung ist, hängt von den konkreten Umständen ab.

Abhängigkeiten vom Anbieter

Wenn du Aufgaben an einen Cloud-Anbieter abgibst, solltest du klären, welche Fähigkeiten im Unternehmen bleiben sollen und welche Tätigkeiten ausgelagert werden dürfen. Ein Unternehmen kann sich dadurch stärker auf seine eigentliche Arbeit konzentrieren. Interne Vorgaben können verlangen, bestimmte Aufgaben selbst zu übernehmen.

Weitere Kriterien betreffen den Anbieter und deine technische Umgebung:

Support: Prüfe, wie schnell du bei einem Fehler Hilfe bekommst und welchen Einfluss du als kleine:r Kund:in auf das Angebot hast.

Dienste: Ein Anbieter kann Angebote verändern oder einstellen. Dann brauchst du eine andere Lösung und musst deine Anwendung gegebenenfalls anpassen.

Anbieterwechsel: Besonders bei Serverless Computing können technische Abhängigkeiten einen Wechsel aufwendig machen. Der Aufwand hängt davon ab, wie viel du an den Anbieter ausgelagert hast.

Programmiersprache und Laufzeitumgebung: Die benötigte Umgebung muss verfügbar sein und langfristig unterstützt werden. In meinem Unternehmen wird beispielsweise Natural für das Bestandssystem eingesetzt, wodurch die Auswahl passender Cloud-Angebote eingeschränkt ist. Bei einer großen vorhandenen Codebasis bedeutet ein Sprachwechsel erheblichen Aufwand.

Cloud Computing in der IHK-Prüfung

...

Nach der Einleitung ins Thema Cloud Computing beim letzten Mal geht es heute um die zentralen "Buzzwords" XaaS, Serverless und Edge Computing in der einhundertneunzehnten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Bei Infrastructure as a Service (IaaS) miete ich Infrastruktur, auf der ich meine Anwendung betreibe; Platform as a Service (PaaS) stellt zusätzlich die passende Laufzeitumgebung bereit. Mit Software as a Service (SaaS) arbeitest du direkt mit fertiger Software, während Function as a Service (FaaS) einzelne selbst entwickelte Funktionen ausführt und nach Aufrufen abrechnet. Die Dienste übernehmen technische Aufgaben und binden dich an das Angebot ihres Anbieters. Container machen Laufzeitumgebungen kompakt und automatisierbar; Edge Computing verarbeitet große Mengen an Sensordaten nahe an den Geräten, bevor Ergebnisse in die Cloud gelangen.

Kapitelmarken

[00:00:00] Einstieg und Rückblick auf virtuelle Maschinen

[00:00:59] XaaS und Infrastructure as a Service

[00:02:44] Amazon EC2 und flexible Rechenleistung

[00:04:32] IaaS: Ressourcen anpassen und Hardwarebetrieb abgeben

[00:05:52] IaaS: Anbieterbindung und Internetzugang

[00:08:09] Betriebssysteme und IaaS-Anbieter

[00:09:11] Platform as a Service und fertige Laufzeitumgebungen

[00:10:49] PaaS: Entwickeln und zusätzliche Instanzen starten

[00:12:12] PaaS: Architektur und Anbieterbindung

[00:13:45] PaaS-Anbieter und Elastic Beanstalk

[00:14:14] Container und modulare Laufzeitumgebungen

[00:17:10] Infrastructure as Code und automatisierte Container

[00:18:29] Container: Einstiegshürden und Docker

[00:19:43] Software as a Service und fertige Anwendungen

[00:21:57] SaaS: Kostenmodell und technischer Betrieb

[00:22:49] SaaS: Funktionsumfang und Anbieterbindung

[00:23:32] Datenschutz und Serverstandorte

[00:24:48] Function as a Service und Serverless Computing

[00:27:50] Amazon Lambda und Azure Functions

[00:28:44] FaaS: Einzelne Funktionen skalieren und abrechnen

[00:31:07] FaaS: Anbieterbindung und zusätzliche Komplexität

[00:33:22] Edge Computing im Internet der Dinge

[00:35:23] Sensordaten für ein Dashboard vor Ort verarbeiten

[00:36:44] Rückblick auf die Cloud-Modelle

[00:38:22] Ausblick auf Plattformwahl und IHK-Prüfungsaufgaben

Inhalt

Infrastructure as a Service (IaaS)

Um den Wartungsaufwand für den Endkunden zu reduzieren, kamen IaaS-Anbieter wie Amazon EC2 oder Microsoft Azure auf die Idee, komplette VMs inkl. Betriebssystemen anzubieten.

Vorteile

Sehr leicht zu skalieren.

Wenig/kein Wartungsaufwand.

Kann komplett ohne eigene Hardware in der Cloud betrieben werden.

Geringe Anfangsinvestition.

Nachteile

Abhängigkeit vom konkreten Anbieter.

Nicht offline nutzbar.

Betriebssystem ist ggfs. vorgegeben bzw. nicht alle Betriebssysteme möglich.

Beispiele: Amazon Web Services, Microsoft Azure

Platform as a Service (PaaS)

In vielen Fällen liefert die eigene Konfiguration der Infrastruktur keinen Mehrwert für den Endkunden oder die Entwickler der Anwendung. Wer einfach nur die Plattform zur Ausführung seiner Anwendung braucht, und sich nicht um die Technik darunter kümmern will, der kann sich direkt die nötige Plattform mieten.

Vorteile

Sehr einfach skalierbar.

Keinerlei Administration des Betriebssystems nötig.

Fokus auf die Entwicklung der eigentlichen Anwendung möglich.

Nachteile

Anwendung muss Architekturkonzept der Plattform unterstützen.

Es können nur die angebotenen Infrastruktur-Dienste verwendet werden.

Beispiele: Microsoft Azure, Amazon Elastic Beanstalk.

Container

Um die Konfiguration der Laufzeitumgebung und auch der verschiedenen Komponenten wie Datenbank, Messaging usw. zu vereinfachen, kann man Container-Dienste wie Docker nutzen.

Vorteile

Beschreibung der Laufzeitumgebung als ausführbare Datei (Infrastructure as Code).

Komplett automatisierbar.

Sehr einfach skalierbar.

Nachteile

Initial hoher Aufwand.

Nicht für alle Anwendungen geeignet.

Beispiele: Docker.

Software as a Service (SaaS)

Wer auch die Anwendung selbst nicht mehr entwickeln will, kann sich fertige Applikationen mieten.

Vorteile

Einfaches Abrechnungsmodell.

Keinerlei Administration mehr nötig.

Fokus auf die Fachlickeit.

Nachteile

Kaum Möglichkeiten der individuellen Anpassung.

Starke Bindung an den SaaS-Anbieter.

Ggfs. Datenschutz-Probleme.

Beispiele: Google Docs, Office 365, Gmail, Salesforce.

Function as a Service (FaaS, Serverless Computing)

Wer seine eigene Anwendung aus kleinen funktionalen Bausteinen erstellen möchte, die individuell skalierbar sind, ist mit einem FaaS-Anbieter gut bedient.

Vorteile

Sogar einzelne Teile der Anwendung sind individuell skalierbar.

Neue Anwendungsfälle können schnell aus bestehenden Diensten zusammengebaut werden.

Transparente Abrechnung nach konkreter Nutzung.

Nachteile

Sehr starke Abhängigkeit vom FaaS-Anbieter.

Evtl. komplizierte Architektur.

Beispiele: Amazon Lambda, Azure Functions.

Edge Computing

Gerade das aktuell stark wachsende Internet der Dinge produziert eine enorme Menge an Daten. Wenn diese komplett in die Cloud transferiert werden müssten, um dort verarbeitet zu werden, würde es schnell zu Latenzproblemen kommen. Daher wandert die (Vor-)Verarbeitung dieser Datenströme zurück ins eigene Netz. Die Daten werden "am Rand" (=Edge) des Netzwerkes aggregiert und erst danach in die Cloud geladen (z.B. zur dauerhaften Speicherung oder als Datenbasis für Anwendungen).

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Edge Computing

Läutet Fog Computing das Ende der Cloud ein?

Amazon Elastic Beanstalk Tutorial – The ULTIMATE Guide

Serverless FaaS with AWS Lambda and Java

Serverlos durch die Nacht: Wie gehen Funktionen ohne Server?

Zusammenfassung

Infrastructure as a Service (IaaS)

Bei einem Anbieter wie Amazon miete ich eine virtuelle Maschine, deren Rechenleistung ich nach Bedarf anpassen kann. Dieses Modell heißt Infrastructure as a Service. Es gehört zu den XaaS-Angeboten, bei denen "as a Service" bedeutet, dass ein Anbieter eine Dienstleistung für dich übernimmt.

Du bekommst Infrastruktur einschließlich Betriebssystem und Netzwerk bereitgestellt. Darauf installierst du deine Anwendung und die benötigte Laufzeitumgebung. Der Anbieter kümmert sich um die zugrunde liegende Hardware und deren ausfallsicheren Betrieb.

Amazon EC2, ausgeschrieben "Elastic Compute Cloud", ist ein Beispiel: Für eine Instanz erhältst du eine bestimmte CPU-Leistung und RAM. Wenn deine Anwendung mehr Ressourcen braucht, kannst du eine größere Instanz bezahlen und später wieder heruntergehen.

Weil der Anbieter die Hardware betreibt, entfällt für dich deren Wartung.

Gerade kleine Unternehmen können mit geringen Anfangsinvestitionen schnell starten.

Welche Instanzen und Betriebssysteme verfügbar bleiben, bestimmt der Anbieter. Änderungen am Angebot oder an den Preisen betreffen deinen Betrieb.

Für den Zugriff brauchst du eine Internetverbindung. Wenn Beschäftigte darüber mit ERP- oder CRM-Software arbeiten, muss die Anbindung ausreichend schnell und gegebenenfalls redundant sein.

Eine Anwendung lässt sich zwischen gemieteten Windows-VMs verschiedener Anbieter übertragen. Wie gut ein Angebot passt, hängt auch davon ab, ob das benötigte Betriebssystem verfügbar ist. Große Anbieter haben verschiedene Betriebssysteme im Angebot. Zu den genannten Anbietern gehören Amazon Web Services und Microsoft Azure sowie Google und IBM.

Platform as a Service (PaaS)

Für meine Java-Anwendung kann ich eine fertige Laufzeitumgebung mieten und dort eine JAR- oder WAR-Datei hochladen. Bei Platform as a Service stellt der Anbieter die Plattform bereit, etwa mit JVM, .NET Framework oder Ruby on Rails. Je nach Angebot kommen eine Datenbank und ein Messaging-System hinzu.

Damit übernimmt der Anbieter auch Aufgaben wie das Einrichten und Patchen der Laufzeitumgebung. Als Entwickler:in kannst du dich auf deinen Anwendungscode konzentrieren. Beispiele sind Microsoft Azure und Amazon Elastic Beanstalk, das etwa eine Umgebung mit Java-EE-Application-Server bereitstellt.

Zusätzliche Instanzen ermöglichen es, mehr Anfragen zu verarbeiten. Dafür muss deine Anwendung entsprechend aufgebaut sein: Anfragen sollen auf unterschiedlichen Knoten verarbeitet werden können. Eine zustandslose Architektur unterstützt das, weil einzelne Knoten keinen lokal gespeicherten Zustand für spätere Anfragen voraussetzen.

Durch anbieterspezifische Dienste entsteht eine stärkere Bindung an die Plattform. Wenn deine Anwendung eng mit deren Datenbanken oder Dateiablagen zusammenarbeitet, wird ein Wechsel aufwendiger.

Container und Infrastructure as Code

Meine Anwendung lässt sich zusammen mit der benötigten Laufzeitumgebung in einen Container packen. So entsteht eine definierte Umgebung mit wenig Overhead. Auf einem passenden System mit Containerdienst kannst du sie übertragen und ausführen.

Container lassen sich modular aufbauen, sodass eine vorhandene Basis mit einer bestimmten Laufzeitumgebung für weitere Anwendungen dienen kann. Sie brauchen wenig Speicherplatz und starten sowie stoppen schnell. Als Beispiel wird Docker genannt.

Mit Infrastructure as Code beschreibst du die Umgebung in einer Textdatei. Darin legst du beispielsweise fest, welche Softwareversionen installiert werden sollen. Der Containerdienst baut daraus die passende Umgebung. Diese Beschreibung kannst du in Git ablegen und gemeinsam mit dem Anwendungscode versionieren.

Weitere Instanzen lassen sich über Skripte automatisiert erstellen. Zu Beginn brauchst du Zeit, um dich in Container einzuarbeiten und die Umgebung als Code zu beschreiben. Ob sich eine konkrete Anwendung dafür eignet, hängt von ihren Anforderungen ab.

Software as a Service (SaaS)

Mit Software as a Service arbeite ich mit einer fertigen Anwendung, etwa Google Docs, Office 365, Gmail oder Salesforce. Über einen Zugang im Browser kannst du loslegen. Der Anbieter betreibt die Software und kümmert sich um technische Aufgaben sowie die benötigten Ressourcen.

...