IT-Berufe-Podcast

Die Vor- und Nachteile eines dualen Studiums diskutiere ich mit Gerda Feldhaus, Elena Hollen und Markus Amshove in der einhundertzehnten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit meinen ehemaligen Azubis und Studierenden bespreche ich, wie du eine Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung mit einem dualen Studium verbinden kannst. Eine abgeschlossene Ausbildung erleichtert dir viele Studieninhalte; wenn du beide Abschlüsse gleichzeitig anstrebst, brauchst du Zeit zum Lernen und eine:n Ausbilder:in, der/die dich begleitet. Das duale Studium bietet dir Berufspraxis und kleine Lerngruppen, wobei Prüfungsphasen, Praxistransferberichte und das Leben an zwei Standorten viel Zeit beanspruchen. Schau dir vor deiner Wahl die Modulhandbücher an, damit der Studiengang zu deinen beruflichen Zielen und einem späteren Master passt.

Kapitelmarken

[00:00:00] Thema und unterschiedliche Ausbildungswege

[00:01:49] Gerda, Markus und Elena stellen sich vor

[00:02:58] Wie die Gäste zur Informatik gekommen sind

[00:04:31] Programmiersprachen in Ausbildung und Studium

[00:06:57] Studiengänge und angestrebte Abschlüsse

[00:08:26] Gründe für ein duales Studium

[00:10:22] Praxisbezug der Lehre und kleine Studiengruppen

[00:13:06] Angewandte Informatik und Wirtschaftsinformatik wählen

[00:15:18] Informatikanteil und Voraussetzungen für einen Master

[00:16:57] Module und fachliche Anforderungen

[00:20:00] Netzwerke und Themen der Systemintegration

[00:21:18] Schwierige Prüfungen und Studienabbrüche

[00:24:25] Größe und Zusammensetzung der Studiengruppen

[00:26:37] Theorie und Praxis im Blockmodell

[00:29:13] Betriebliche Projekte während der Praxisphasen

[00:32:33] Ausbildung parallel zum Studium und hilfreiches Vorwissen

[00:35:23] Ausbildungswege der Mitstudierenden

[00:36:59] Lerntempo und unterschiedliche Vorkenntnisse

[00:41:18] Programmieranteil und Softwarequalität

[00:47:32] Praxistransferprojekte in Lingen

[00:53:22] Praxistransferberichte an der Nordakademie

[00:56:32] Studium und Vorbereitung auf die IHK-Prüfung

[00:59:25] Studienwissen im betrieblichen Alltag

[01:03:33] Smalltalk und der Einstieg in neue Programmiersprachen

[01:06:07] Moodle-Kurse, Lernvideos und Pair Programming

[01:12:19] Zeitaufwand und Klausurenphasen

[01:18:44] Module, Projektstudium und wissenschaftliches Arbeiten

[01:22:27] Skripte, Bücher und praktische Übungen zur Softwarequalität

[01:27:12] Präsentationen und Referate als Prüfungsleistungen

[01:30:10] Was die Gäste am dualen Studium schätzen

[01:34:31] Belastung und Seminare zum Zeitmanagement

[01:36:42] Wohnen und Alltag an zwei Standorten

[01:37:43] Kritik an Praxistransferprojekten

[01:39:20] Würden die Gäste ihren Studiengang erneut wählen?

[01:42:12] Duales Studium aus meiner Sicht als Ausbilder

[01:44:00] Freizeit und Feiern während des Studiums

[01:46:05] Buchtipps und Gedanken zur Bachelorarbeit

[01:48:46] Kontaktmöglichkeiten der Gäste

[01:50:08] Shownotes und weiterführende Informationen

Inhalt

Gerda Feldhaus studiert Angewandte Informatik an der Nordakademie in Elmshorn und Elena Hollen und Markus Amshove studieren Wirtschaftsinformatik an der Hochschule Osnabrück am Standort Lingen. Beide Studiengänge werden dual absolviert. Das heißt, dass die drei neben dem Studium noch in einem Unternehmen arbeiten - in ihrem Fall bei der ALTE OLDENBURGER Krankenversicherung AG in Vechta. Nebenbei lasse ich noch meine Erfahrungen als Dozent im dualen Studiengang Business Administration & IT an der PHWT in Vechta mit einfließen.

Wenn du selbst überlegst, ob ein duales Studium - egal ob als Alternative zur Ausbildung oder im Anschluss an eine solche - für dich das Richtige ist, können wir dir vielleicht eine Orientierungshilfe geben.

Ich habe mit Gerda, Elena und Markus u.a. über die folgenden Fragen zum dualen Studium gesprochen.

Duales Studium

Was und wo studierst du?

Welchen Ausbildungsberuf lernst du im Unternehmen?

Welchen Abschluss erreichst du mit Abschluss des Studiums?

Warum hast du dich für ein duales Studium entschieden?

Warum hast du gerade deinen Studiengang und deine Hochschule gewählt?

Wie ist der Ablauf (zeitlich/organisatorisch) des Studium?

Wie groß und diversifiziert ist deine Studiengruppe?

Welche Inhalte werden im Studium allgemein vermittelt?

Welche technischen Inhalte werden im Studium vermittelt?

Wie groß ist deine zeitliche Belastung während des Studiums?

Welche Prüfungen (Anzahl/Art) musst du im Studium absolvieren?

Welche Strategien hast du für die Vorbereitung auf Prüfungen?

Wie wird der Praxistransfer der gelernten Theorieinhalte gewährleistet?

Wie ist die IHK-Ausbildung in das duale Studium integriert?

Wie (gut) bereitet das duale Studium auf die IHK-Prüfung vor?

Wie würdest du das duale Studium im Vergleich zur Ausbildung bewerten?

Was gefällt dir am dualen Studium besonders gut?

Was gefällt dir am dualen Studium nicht?

Würdest du noch einmal ein duales Studium absolvieren?

Studiengänge

Über diese drei Studiengänge sprechen wir während der Diskussion.

Angewandte Informatik an der Nordakademie in Elmshorn

Wirtschaftsinformatik an der Hochschule Osnabrück am Standort Lingen

Duales Studium Wirtschaftsinformatik

Literaturempfehlungen

Gerda hat an der Nordakademie mit dem "Standardwerk" The Pragmatic Programmer* von Andy Hunt und Dave Thomas gearbeitet. Das finde ich richtig klasse! Und persönlich kann ich das Buch auch absolut empfehlen.

*

Elena hat für ihre Bachelorarbeit ein weiteres Standardwerk gelesen: Extreme Programming Explained* von Kent Beck. Auch hierfür eine klare Leseempfehlung von mir!

*

Gerda hat im Studium auch die Pomodoro-Technik gelernt. Darüber habe ich hier auch schon öfter berichtet und kann Pomodoro Technique Illustrated* von Staffan Noteberg zum Einstieg empfehlen.

*

Außerdem empfiehlt sie Introduction to the Design and Analysis of Algorithms* von Anany Levitin für den Einstieg in Algorithmen und Datenstrukturen.

*

Und da ich mit all meinen Azubis das IT-Handbuch für Fachinformatiker* durcharbeite, darf es natürlich auf der Literatusliste nicht fehlen! ;-)

*(direkt beim Rheinwerk-Verlag bestellen*)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Gerda Feldhaus bei Facebook

Markus Amshove bei XING

Maria Elena Hollen bei XING

Projektdokumentation von Gerda Feldhaus (mit 100% bewertet)

Projektdokumentation von Markus Amshove (mit 100% bewertet)

Projektdokumentation von Elena Hollen (mit 98% bewertet)

Zusammenfassung

Welche Ausbildungswege meine Gäste gewählt haben

Mit Gerda, Elena und Markus habe ich Erfahrungen aus der Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung und dem dualen Studium besprochen. Alle haben ihre IHK-Prüfung bestanden und ihre Projektarbeiten mit der Note eins abgeschlossen. Ihre Erfahrungen beziehen sich auf die jeweiligen Studiengänge und Prüfungsordnungen zum Zeitpunkt des Gesprächs.

Gerda hat zuerst ihre Ausbildung abgeschlossen und studiert anschließend Angewandte Informatik an der Nordakademie in Elmshorn.

Markus hat ebenfalls zuerst die Ausbildung gemacht. Danach hat er Wirtschaftsinformatik am Campus Lingen der Hochschule Osnabrück begonnen.

Elena ist direkt ins duale Studium Wirtschaftsinformatik in Lingen eingestiegen und hat parallel den Ausbildungsabschluss erworben. Zum Zeitpunkt des Gesprächs hat sie auch ihr Studium abgeschlossen.

Als Studienabschluss wird der Bachelor of Science genannt.

Gerda hat über Einblicke beim Girls’ Day Interesse an der IT gefunden. Markus kam während seiner vorherigen Ausbildung zum/zur Metallbauer:in durch ein Programmierbuch zur Softwareentwicklung. Elena lernte Informatik am Wirtschaftsgymnasium kennen und entschied sich nach einem Praktikum für diesen Bereich.

Warum ein duales Studium infrage kommt

Gerda und Markus wollten nach ihrer Ausbildung weiterlernen und im Unternehmen bleiben. Für Elena waren der Standort Lingen und Empfehlungen aus ihrem Umfeld Gründe für ihre Wahl.

Durch die Praxisphasen lernst du Abläufe im Unternehmen kennen und arbeitest schon während des Studiums mit Kolleg:innen zusammen. Die Gäste schätzen außerdem, dass sie Geld verdienen. Kleine Studiengruppen ermöglichen persönlichen Kontakt zu Dozent:innen und Raum für Fragen.

In den beschriebenen Gruppen lernen ungefähr 19 bis 25 Personen zusammen. Frauen sind unterschiedlich stark vertreten: Die Gäste nennen eine Frau unter 19 Studierenden sowie vier beziehungsweise fünf Frauen in anderen Gruppen. Aus meiner Erfahrung als Dozent hängt auch von den Unternehmen ab, wer ins Studium einsteigt und wie klar die späteren Aufgaben erklärt werden.

Studieninhalte vor der Wahl prüfen

Gerda hat Angewandte Informatik gewählt, weil sie sich stärker mit Informatik beschäftigen wollte. Der Studiengang enthält technische und formale Grundlagen, darunter Automatentheorie und Grammatiken. Dazu kommen diskrete und angewandte Mathematik sowie ein kleiner Anteil BWL. Gerade die Mathematikmodule beschreibt sie als anspruchsvoll.

Markus und Elena wollten auch wirtschaftliche Themen kennenlernen. Für das Grundstudium in Lingen nennt Markus ungefähr ein Drittel Informatik und zwei Drittel BWL. Er versucht, im Schwerpunktstudium möglichst viele Informatikmodule zu wählen. Elena findet den Umfang der wirtschaftlichen Inhalte passend und wünscht sich Fächer, die Wirtschaft und IT enger verbinden, etwa IT-Controlling.

Zu den genannten Modulen in Lingen gehören unter anderem:

Mathematik und VWL

IT-Sicherheit und Digitaltechnik

Projektmanagement

Rechnungswesen und Wirtschaftsrecht

Grundlagen der Programmiersprachen beziehungsweise objektorientierte Programmierung, abhängig von der Prüfungsordnung

Bei Digitaltechnik geht es beispielsweise darum, wie eine CPU funktioniert. Netzwerkthemen sind je nach Studiengang und Schwerpunkt unterschiedlich vertreten. Gerda berichtet von technischen Grundlagen und Übungen im Netzwerklabor. In Lingen lassen sich entsprechende Inhalte teilweise im Schwerpunkt wählen; Elena musste Netzwerkthemen zusätzlich für die IHK-

Einen Rundumschlag über all meine Erfahrungen aus der Sommerprüfung 2017 gibt es in der einhundertneunten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Aus der Sommerprüfung 2017 nehme ich für dich mit: Als Fachinformatiker:in Anwendungsentwicklung musst du den Code und die Technologien deines Abschlussprojekts im Fachgespräch erklären können. Für die Bewertung zählen außerdem ein nachvollziehbar begründetes Projekt und dein methodisches Vorgehen, das du in der Dokumentation verständlich beschreibst. In der Präsentation helfen passende Bilder und ein eingeübter Screencast dabei, die Inhalte zu vermitteln. Bereite dich auch auf Datenmodelle und SQL vor und beschäftige dich mit den Fragen zu Sicherheit und Datenschutz, die dein Projekt aufwirft.

Kapitelmarken

[00:00:00] Hinweis zur Projektdokumentation

[00:00:18] Rückblick auf die Sommerprüfung 2017

[00:01:29] Funktionale Konzepte und den eigenen Code verstehen

[00:04:45] Asynchroner Code und seine Besonderheiten

[00:06:38] REST und die Hintergründe der Schnittstelle

[00:08:03] Ein SAP-Projekt mit sehr guter Bewertung

[00:09:21] Ein Backend-Dienst als Abschlussprojekt

[00:10:24] Zeiterfassung und die Gründe für eigene Software

[00:11:56] SOLID und das Liskov Substitution Principle

[00:14:28] Förmliche Anrede im Prüfungsausschuss

[00:15:17] Amortisation und plausible Kostenkurven

[00:17:13] Passende Diagrammtypen wählen

[00:18:39] Schriftliche Prüfung: Datenmodelle und SQL

[00:20:34] Exceptions im Projektcode behandeln

[00:22:19] Helle Hintergründe für Code-Screenshots

[00:23:10] Lastenheft und Pflichtenheft verstehen

[00:23:43] Das Layout der Dokumentation prüfen

[00:25:29] Projektverlauf und Unterlagen verständlich beschreiben

[00:27:29] Sinnvolle Auszüge im Anhang

[00:30:11] Vorlagen an das eigene Projekt anpassen

[00:31:12] Ausgangslage und Projektproblem vermitteln

[00:32:37] Fachliche Inhalte und passende Bilder in der Präsentation

[00:36:45] Screencasts für die Anwendung vorführen

[00:37:53] Fachgespräch: Mobile Apps und mögliche Alternativen

[00:39:34] Dependency Injection und Testbarkeit

[00:40:26] IT-Sicherheit und Datenschutz im Fachgespräch

[00:41:22] Weiterführende Materialien und Vorlagen

Inhalt

Meine allgemeinen Eindrücke

Funktionale Programmierung wird eingesetzt, aber nicht verstanden (Grundlagen der FP fehlen).

Asynchrone Programmierung wird immer wichtiger (async und await in C#, Promises in JavaScript).

REST, REST, REST!

SAP kann auch cool sein (mit Java und MVC im Frontend).

Man kann auch ohne Webanwendung eine 1 bekommen.

Meine Highlights

Ein Prüfling konnte die SOLID-Prinzipien erklären.

Den Ausschuss zu duzen geht gar nicht.

Lustige "Kurve" zur Visualisierung der Amortisation.

Diagramme müssen passend zur darzustellenden Information gewählt werden (z.B. Kreis statt Balken).

Schriftliche Prüfung

Datenbankmodellierung ist manchmal abenteuerlich.

SQL sollte jeder Prüfling kennen. Ist aber leider nicht so.

Projektdokumentationen

Exception Handling heißt in vielen Unternehmen wohl Logging auf die Konsole.

Code auf schwarzem Hintergrund in der Dokumentation geht gar nicht.

Der Unterschied zwischen Lasten- und Pflichtenheft ist nicht allen Prüflingen klar.

Eine vernünftige Formatierung der Dokumentation ist anscheinend nicht so wichtig (Zeilenumbruch nach jedem Verweis, offensichtlich kein zweites Mal gelesen).

"Auszug aus" nimmt Überhand (Hightlight: Lastenheft aus drei Sätzen).

Stumpfes Abarbeiten meiner Vorlagen für die Projektdokumentation wird leider immer häufiger.

Eine dumme Liste aus Verweisen im Text der Dokumentation reicht nicht aus.

Viele Prüflinge schaffen es nicht, ein Verständnis des zu lösenden Problems zu schaffen (z.B. Screenshots der bisherigen Anwendung zeigen).

Projektpräsentationen

Keine reine Bildershow veranstalten, sondern Inhalt transportieren!

Videos der Endergebnisse kamen sehr gut an.

Häufige Fragen

Was sind die Alternativen zu hybriden Apps?

Was ist Dependency Injection?

Alles rund um die IT-Sicherheit

Datenschutz, Datensicherheit, Datensicherung

Literaturempfehlungen

Da ich hier 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

Zusammenfassung

Erfahrungen aus der Sommerprüfung 2017

Für deine Prüfung als Fachinformatiker:in Anwendungsentwicklung habe ich Erfahrungen aus der Sommerprüfung 2017 zusammengestellt. Sie betreffen das Abschlussprojekt ebenso wie die schriftlichen Aufgaben und das Fachgespräch.

Den eigenen Code verstehen

In den Abschlussprojekten begegneten mir zunehmend funktionale Konzepte, etwa Lambda-Ausdrücke sowie Streams in Java. Auch LINQ-Abfragen in C# tauchten auf. In der damaligen schriftlichen Prüfung war funktionale Programmierung noch kein Thema.

Schau dir vor deiner Prüfung jeden Bestandteil deines Beispielcodes an. Du musst erklären können, wie er funktioniert und weshalb du ihn einsetzt. Das gilt auch für generische Klassen oder Funktionen, die dein Framework vorgibt.

Bei JavaScript-Promises solltest du verstehen, dass sie für das zukünftige Ergebnis einer asynchronen Operation stehen. Sobald das Ergebnis vorliegt, kann eine Funktion damit aufgerufen werden.

Asynchronen Code erklären

Mit asynchronem Code kann deine Anwendung während eines längeren Vorgangs bedienbar bleiben, etwa wenn sie eine große Datei herunterlädt. Der Hauptthread bleibt dabei frei. Als Beispiele kamen Promises in JavaScript und async beziehungsweise await in .NET vor; in Java gibt es dafür unter anderem CompletableFuture.

Durch Callbacks und zeitlich versetzte Ergebnisse wird der Ablauf schwerer vorhersehbar. async und await erleichtern es, solchen Code zu schreiben und zu lesen. Wenn du diese Techniken einsetzt, gehört ihr Verhalten zur Vorbereitung auf dein Fachgespräch.

REST verstehen

In vielen Projekten kommunizierten Single-Page-Applications oder hybride mobile Anwendungen über eine REST-Schnittstelle mit dem Backend. REST steht für Representational State Transfer und bezeichnet ein Architekturkonzept, zu dem Roy Fielding seine Dissertation geschrieben hat. Beschäftige dich mit den Hintergründen, damit du deine Schnittstelle fachlich erläutern kannst.

Ein passendes Projektthema wählen

Ein SAP-Projekt wurde mit einer Eins bewertet. Es verband eine moderne Weboberfläche mit einem SAP-System im Hintergrund und zeigte das MVC-Pattern sowie objektorientierten Code. Auch die Arbeit mit einer Datenbank war enthalten. Bei einem SAP-Abschlussprojekt muss die eigene Leistung beim Programmieren erkennbar sein.

Bei einem Dienst, der im Backend Aufgaben erledigte, erhielten Dokumentation und Präsentation ebenfalls eine Eins. Das Projekt kam ohne grafische Oberfläche und ohne Datenbank aus. Für ein solches Thema musst du dein methodisches Vorgehen genauso nachvollziehbar zeigen, etwa mit geeigneten Diagrammen.

Zeiterfassungen kamen mehrfach als Projektthema vor. Bei einer eigenen Software für diesen Zweck muss nachvollziehbar sein, weshalb du sie entwickelst und welches Standardprodukt als Alternative infrage kommt. Prüfer:innen achten dabei auf die Gründe für dein Projekt.

Für die Bewertung kommt es darauf an, wie du dein Projekt begründest und methodisch umsetzt. In der Dokumentation muss sich dieser Weg nachvollziehen lassen.

Fachwissen im Gespräch anwenden

Ein:e Prüfungsteilnehmer:in konnte das Liskov Substitution Principle aus den SOLID-Prinzipien erklären und mit Polymorphie verbinden. Das Fachgespräch wurde mit einer Eins bewertet.

Das Prinzip besagt, dass eine Unterklasse überall dort eingesetzt werden kann, wo ihre Basisklasse erwartet wird. Dabei muss sie das erwartete Verhalten erfüllen. Problematisch ist beispielsweise eine überschriebene Methode, die eine unerwartete Exception wirft, weil die Unterklasse die Methode nicht umsetzen kann.

Wenn du SOLID oder Clean Code in deiner Dokumentation erwähnst, bereite dich auf Fragen zu den fachlichen Hintergründen vor. Dazu gehört auch, Zusammenhänge mit anderen Themen der Objektorientierung erklären zu können.

Für die förmliche Prüfungssituation empfehle ich dir, die Mitglieder des Prüfungsausschusses zu siezen. Das gilt auch bei einer Lehrkraft, die du persönlich kennst.

Kosten und Diagramme nachvollziehbar darstellen

Amortisation berechnen

Mit einer Amortisationsrechnung zeigst du, wann sich die Projektkosten durch Einsparungen oder Gewinne ausgeglichen haben. Bei den beschriebenen üblichen Kostenmodellen ergeben sich Geraden, deren Schnittpunkt diesen Zeitpunkt zeigt.

In einer Präsentation hatte die Software durch wenige eingetragene Werte eine geschwungene Kurve gelegt. Die Prüfungsteilnehmerin konnte deren mathematische Bedeutung nicht erklären. Prüfe deshalb, ob die gezeichnete Kurve zu deinen Zahlen und zum zugrunde liegenden Kostenmodell passt.

Einen geeigneten Diagrammtyp wählen

Balken- oder Säulendiagramme eignen sich, um Größenverhältnisse darzustellen.

Ein Kreisdiagramm zeigt prozentuale Anteile an einem Ganzen mit insgesamt 100 Prozent.

Für einen Ablauf oder eine Entwicklung über die Zeit brauchst du einen passenden anderen Diagrammtyp.

Lass dein:e Ausbilder:in auf deine Diagramme schauen, wenn du Hilfe bei der Auswahl brauchst.

Datenmodelle und SQL üben

Beim Korrigieren der schriftlichen Prüfung fielen mir Lücken bei grundlegenden Aufgaben zu Datenbanken auf. Datenmodelle und SQL waren bereits seit Jahren wiederkehrende Prüfungsthemen.

Übe, ein ER-Modell mit korrekter Syntax zu zeichnen, und schreibe selbst SQL-Anweisungen. Mit alten Prüfungen kannst du erkennen, welche Aufgaben regelmäßig vorkommen. Das Beiblatt zur SQL-Syntax gehört zu den Hilfsmitteln; die Aufgaben musst du selbst lösen können.

Die Projektdokumentation sorgfältig schreiben

Fehler im Code behandeln

Wenn du eine Exception abfängst, muss dein Programm angemessen darauf reagieren. Es kann den Fehler behandeln und mit einem sauberen Zustand w

Ein sehr interessantes Interview zum Thema Objektrelationale Mapper mit Stephan Görgens gibt es in der einhundertachten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Am Beispiel von Microsofts Entity Framework zeige ich dir, wie objektrelationale Mapper Klassen und Objekte mit Tabellen und Datensätzen verbinden. Mit Code-first entsteht das Datenbankschema aus deinen Klassen, während der DbContext den Zugriff auf die Datenbank und das Speichern übernimmt. SQL gehört weiterhin zu deinem Handwerkszeug, weil große Datenmengen und zeitkritische Aufgaben gezielte Eingriffe erfordern. Für deine Projekte empfehle ich etablierte Frameworks und eigene Tests mit einer Datenbank; zusätzliche Schichten hängen davon ab, wie umfangreich dein Projekt wird.

Kapitelmarken

[00:00:00] Einstieg ins Thema objektrelationale Mapper

[00:01:39] Stefan Görgens und das Berichtswesen bei BMW

[00:03:31] Von der Elektrotechnik zur Informatik

[00:07:48] Clean Code und die Arbeit mit C# und .NET

[00:12:37] Was ein ORM macht

[00:14:13] Klassen und Objekte auf Tabellen und Datensätze abbilden

[00:17:06] Entity Framework, NHibernate und JPA

[00:19:11] Kosten, Installation und die Wahl eines Frameworks

[00:22:06] Grafische Designer und Code-first

[00:23:53] Das Datenmodell aus Klassen erstellen

[00:25:56] Schrittweise entwickeln und Migrationen verwalten

[00:27:42] Connection-String und DbContext

[00:29:39] Konventionen und Annotationen

[00:34:49] Beziehungen und Kardinalitäten abbilden

[00:37:50] Änderungen speichern und den Kontext freigeben

[00:38:54] Große Datenmengen und direkte SQL-Befehle

[00:39:53] LINQ to Entities und weitere Abfragemöglichkeiten

[00:43:49] SQL verstehen und bei Performance-Problemen eingreifen

[00:46:24] SQL-Ausgaben und Logging

[00:50:07] Aufwand und Grenzen eines ORMs

[00:52:07] Architektur und Schichten im Projekt

[00:55:53] ORM und Datenbank austauschen

[01:03:16] Den DbContext erzeugen und seine Lebensdauer steuern

[01:06:35] Tests mit einer In-Memory-Datenbank

[01:09:11] Integrationstests und Fehler eingrenzen

[01:13:01] Etablierte Frameworks für eigene Projekte

[01:13:56] Domänenmodell und Data-Access-Layer

[01:17:19] Quellen zu Entity Framework und Literaturtipps

[01:21:05] Clean Code und weitere prägende Bücher

[01:22:38] Weiterlernen während der Arbeitszeit

[01:26:29] Studierende betreuen und Wissen weitergeben

[01:28:52] Kontakt, Praktikum und Abschlussarbeit bei BMW

[01:31:08] Verabschiedung

[01:31:47] Shownotes zur Episode

Inhalt

Die folgenden Fragen zum Bereich der objektrelationalen Mapper gehen wir im Verlauf des Interviews durch.

Objektrelationale Mapper

Was ist ein ORM?

Warum braucht man einen ORM bzw. sollte ihn verwenden?

Was sind Beispiele für bekannte ORMs?

Mit welchen ORMs hast du selbst schon gearbeitet?

Was ist dein Lieblings-ORM und warum?

Was sollte ein ORM mindestens können?

Wie konfiguriert man einen ORM?

Wie setzt man komplexe Datenbankabfragen mit einem ORM um?

Wie integriert man einen ORM am besten in eine Anwendungsarchitektur?

Ab wann "lohnt" sich der Einsatz eines ORMs im Projekt?

Wie stark macht man sich beim Einsatz eines ORMs von diesem abhängig?

Sollte man einen ORM einfach austauschen können?

Wie wichtig ist das Beherrschen von SQL, wenn man mit ORMs arbeitet?

Sollten auch Azubis schon mit ORMs arbeiten und warum (nicht)?

Welche Nachteile haben ORMs?

Welche Literaturempfehlungen hast du für den Bereich ORMs?

Literaturempfehlungen

Stephan empfiehlt für Einsteiger ins Thema Moderne Datenzugriffslösungen mit Entity Framework 6: Datenbankprogrammierung mit .NET und C#* von Dr. Holger Schwichtenberg.

*

Und hier gibt es den ".NET-Doktor" live zu sehen.

Außerdem ist Stephan - genau wie ich - der Meinung, dass Clean Code* auf keinem Entwicklernachttisch fehlen sollte ;-)

*

Links

Stephan erreichst du am Besten über Xing: Stephan Görgens

Das Karriereportal von BMW findest du hier, falls du Interesse an einem Praktikum oder einer Abschlussarbeit hast: BMW Group - Karriere.

Der .NET-Doktor (Dr. Holger Schwichtenberg)

Die BASTA! ist sicherlich eine der interessantesten Konferenzen im .NET-Umfeld.

Und das ist die Beispielanwendung zum Entity Framework: World Wide Wings (WWWings).

Zusammenfassung

Aus der Praxis bei BMW

Für den Einstieg in objektrelationale Mapper greife ich auf das Gespräch mit Stefan Görgens zurück, der bei BMW im Berichtswesen für die Qualität während der Produktion arbeitet. Seine Abteilung entwickelt Software, mit der Qualitätsdaten erfasst und für Berichte aus Datenbanken gelesen werden. Ein ORM gehört dort zum Standard neuer Softwareprojekte.

Görgens kam über eine elektrotechnische Ausbildung und ein Elektrotechnikstudium zur Softwareentwicklung. Nach einem Softwareprojekt für seine Abschlussarbeit bei BMW studierte er angewandte Informatik bis zum Master. Durch das Buch Clean Code beschäftigte er sich stärker damit, wie sich Software testen und später weiterentwickeln lässt. Im beruflichen Alltag arbeitet er vor allem mit C#, weil sein Unternehmen auf .NET setzt.

Wie ein ORM deine Objekte mit der Datenbank verbindet

Wenn du als Fachinformatiker:in Anwendungsentwicklung mit einer relationalen Datenbank arbeitest, müssen deine Objekte dauerhaft gespeichert werden. Ein objektrelationaler Mapper, kurz ORM, übernimmt dabei das Zuordnen zwischen der objektorientierten Programmiersprache und der relationalen Datenbank.

Für den einfachen Fall gelten folgende Beziehungen:

Eine Klasse entspricht einer Tabelle.

Ein Objekt entspricht einem Datensatz.

Die Eigenschaften der Klasse entsprechen den Spalten.

Beziehungen zwischen Objekten werden als Beziehungen in der Datenbank abgebildet.

Dadurch kannst du mit den Daten als Objekte arbeiten und sie beispielsweise in Listen verwalten. Das Framework übernimmt Aufgaben, die du sonst selbst programmieren müsstest, etwa Daten aus der Datenbank in passende Objekte zu übertragen und Änderungen zurückzuschreiben. Das spart Arbeit und verringert Fehler beim Datenzugriff. Ein einmal erarbeiteter Ansatz lässt sich in weiteren Projekten wieder einsetzen.

Entity Framework und andere ORMs

Im .NET-Umfeld arbeitet Görgens mit Microsofts Entity Framework. Für seine Abteilung sprechen die laufende Entwicklung und die verfügbaren Informationen dafür. Auch interne Freigaben sind bei einem Produkt von Microsoft unter den dortigen Bedingungen leichter zu bekommen.

Als Alternative nennt er NHibernate, das aus der Java-Welt stammt. Kenntnisse daraus lassen sich auf Hibernate in Java übertragen. Im Java-Umfeld gibt es außerdem JPA, die Java Persistence API: Sie legt eine Schnittstelle fest, hinter der unterschiedliche ORM-Provider wie Hibernate oder EclipseLink arbeiten können.

Entity Framework ist kostenfrei und wird als eigenes Paket installiert, beispielsweise über NuGet in Visual Studio. Im Gespräch wird auch die damals noch junge Core-Variante angesprochen, mit der plattformübergreifendes Entwickeln möglich wird. Die grundlegenden ORM-Konzepte gelten über .NET hinaus.

Mit Code-first das Datenmodell entwickeln

Bei Code-first schreibst du deine Klassen und legst einen Datenbankkontext an. Aus diesem Code erstellt Entity Framework die Tabellen. Vorher solltest du dir Gedanken über dein Datenmodell machen und es grob aufzeichnen.

Für neue Projekte empfiehlt Görgens diesen Weg, weil sich die Klassen im Code gut überblicken lassen. Verständliche Namen und passende Ordner helfen dir, später wieder ins Projekt einzusteigen. Die Dateien bleiben als Text zugänglich.

Ein grafischer Designer liefert beim Lernen schnell ein Ergebnis. Görgens sieht dabei das Problem, dass viele Schritte im Hintergrund ablaufen und Details erst in den jeweiligen Eigenschaften sichtbar werden.

Mit Code-first kannst du dein Modell während der Arbeit weiterentwickeln. Migrationen übertragen Änderungen auf die Datenbank. Entity Framework hält dabei fest, welche Versionen angewendet wurden; Änderungen lassen sich auch wieder zurücknehmen. Das passt zu einem schrittweisen oder testgetriebenen Vorgehen.

Konventionen und Beziehungen

Entity Framework erkennt vieles anhand seiner Konventionen. Eine passend benannte ID-Eigenschaft wird beispielsweise als Schlüssel erkannt. Über Annotationen oder Einstellungen im DbContext kannst du die Zuordnung verändern, etwa wenn Tabellen anders heißen sollen. Auch das automatische Bilden englischer Pluralformen für Tabellennamen lässt sich beeinflussen.

Ich empfehle dir, dich zunächst an die vorgesehenen Konventionen zu halten. Dadurch bleibt leichter nachvollziehbar, wie eine Klasse mit ihrer Tabelle zusammenhängt, und du sparst dir zusätzliche Einstellungen.

Beziehungen kannst du über Eigenschaften und Sammlungen ausdrücken. Eine Liste von Kursen in einer Klasse für eine:n Student:in stellt beispielsweise einen Bezug zu diesen Kursen her. Bei n:m-Beziehungen kommt eine Zwischentabelle ins Spiel. Hat die Beziehung eigene Eigenschaften, etwa eine Uhrzeit, wird im Gespräch eine eigene Klasse dafür vorgeschlagen.

Wie viel du zusätzlich festlegen musst, hängt vom Datenmodell ab. Ein über viele Jahre gewachsenes Schema kann mehr Anpassungen erfordern.

Mit dem DbContext arbeiten und Änderungen speichern

Der DbContext ist die zentrale Schnittstelle beim Arbeiten mit Entity Framework. Er verwaltet die Entities und kümmert sich um die Verbindung zur Datenbank. Dafür braucht er einen Connection-String, der im beschriebenen Beispiel in der Anwendungskonfiguration steht.

Du kannst einen Kontext mit new erzeugen und innerhalb eines using-Blocks damit arbeiten. Weil er IDisposable implementiert, werden seine Ressourcen beim Verlassen des Blocks freigegeben. Mehrere Kontexte können unabhängig voneinander existieren.

Änderungen werden zunächst lokal verwaltet. Zum dauerhaften Speichern musst du ausdrücklich den entsprechenden Aufruf auslösen, damit die geänderten Daten in die Datenbank geschrieben werden.

SQL, LINQ und große Datenmengen

SQL-Kenntnisse brauchst du auch beim Arbeiten mit einem ORM....

Ein Interview mit Markus Amshove zum Thema Domänenspezifische Sprachen gibt es in der einhundersiebten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit meinem ehemaligen Azubi Markus bespreche ich, wie du domänenspezifische Sprachen (DSLs) für fachliche Aufgaben entwickelst. Sein IHK-Abschlussprojekt zeigt, wie eine eigene Sprache Regeln für eingescannte Dokumente verständlich abbildet und daraus C#-Code samt Unit Tests erzeugt. Xtext übernimmt dabei viele technische Aufgaben und liefert einen passenden Editor. Dazu kommen Erfahrungen mit Konferenzvorträgen sowie Empfehlungen, wie du dich in DSLs und die Grundlagen von Programmiersprachen einarbeitest.

Kapitelmarken

[00:00:01] Thema und Anlass des Interviews

[00:01:24] Markus und sein Weg in die IT

[00:03:49] Programmiersprachen im Beruf und privat

[00:05:41] Sprachmerkmale und Entwicklungsumgebungen

[00:08:42] Was ist eine domänenspezifische Sprache?

[00:10:44] Domäne und Sprachumfang festlegen

[00:11:27] Zielgruppe und fachliche Begriffe

[00:14:24] Dokumente mit einer DSL zuweisen

[00:17:07] Regeln verständlich und nachvollziehbar gestalten

[00:18:34] Eine DSL gemeinsam mit dem Fachbereich entwerfen

[00:20:44] Grammatik und Backus-Naur-Form

[00:23:05] Was Xtext aus der Grammatik erzeugt

[00:24:34] Editorfunktionen und Verweise zwischen Elementen

[00:26:56] Code mit Java und Xtend erzeugen

[00:29:33] Einstieg und Erfahrungen beim Lernen

[00:32:27] Programmiersprachen besser verstehen

[00:34:15] Die DSL als IHK-Abschlussprojekt

[00:35:36] Feedback der Prüfer:innen und Projektdokumentation

[00:36:36] Zeit sparen und Unit Tests generieren

[00:38:44] Parser und Codegenerator testen

[00:40:14] Formelmanager für Versicherungsmathematik

[00:41:44] Grenzen und Updates von Xtext

[00:43:35] DSL-Vortrag auf der JavaLand

[00:45:40] Begleitung durch einen Mentor

[00:47:20] Eigene Themen für Konferenzvorträge finden

[00:49:12] Weitere DSL-Plattformen: MPS und Nitra

[00:50:43] Einstieg mit Büchern und Tutorials

[00:52:00] ANTLR und die Grundlagen hinter dem Framework

[00:53:05] Weitere Bücher zu Sprachen und Laufzeitumgebungen

[00:56:30] Geplanter Vortrag über Mutation Testing

[00:59:21] Kontaktmöglichkeiten von Markus

[01:00:49] Rückblick und Shownotes

Inhalt

Wir haben uns u.a. über die folgenden Fragen ausgetauscht.

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du?

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

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

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

Was ist deine Lieblingsprogrammiersprache und warum?

Domänenspezifische Sprachen

Was ist eine domänenspezifische Sprache?

Was unterscheidet DSLs von "normalen" Programmiersprachen?

Was sind interne und externe DSLs?

Womit kann man DSLs entwickeln?

Welche DSLs hast du bisher entwickelt und wofür werden sie eingesetzt?

Welche Plattform nutzt du für deine DSLs und warum?

Wie geht man bei der Umsetzung einer DSL vor?

Was sind Grammatik, Parser und Lexer?

Bringen DSLs wirklich so viel Mehrwert, dass sich eine Entwicklung lohnt?

Wie schwierig ist die Entwicklung einer eigenen Programmiersprache?

Was macht dir am Entwickeln von DSLs Spaß?

Was stört dich beim Entwickeln von DSLs?

Wie bist du zum Thema DSLs gekommen?

Können auch schon Azubis eigene DSLs entwickeln?

War das Thema nicht zu schwierig für ein IHK-Abschlussprojekt?

Welche Literaturempfehlungen hast du für den Bereich DSLs?

Vorträge auf Konferenzen

Wie kam es zu deinem Vortrag auf der JavaLand?

Was kann man sich unter dem "Newcomer-Track" vorstellen und wie wurdest du dort betreut?

Wie hast du das Thema deines Vortrags gefunden?

Wie hast du dich auf deinen Vortrag vorbereitet?

Was hast du selbst durch den Vortrag gelernt?

Was hat dir der Vortrag rückblickend gebracht?

Sollten auch Azubis oder Berufseinsteiger schon Vorträge halten?

Aus- und Weiterbildung

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

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

Literaturempfehlungen

*

Implementing Domain-Specific Languages with Xtext and Xtend*

*

CLR Via C#*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Markus' Blog

Meine praktische Abschlussprüfung – Markus Amshove

Markus' IHK-Projektarbeit über DSLs

Projektdokumentation von Markus Amshove (mit 100% bewertet)

Projektpräsentation von Markus Amshove (mit 100% bewertet)

Markus Amshove bei GitHub

Presentations by Markus Amshove // Speaker Deck

SEROM – Softwareentwicklung im Mittelstand

Markus' Vortrag: Domänenspezifische Sprachen mit Xtext

Xtext - Language Engineering Made Easy!

ANTLR

Zusammenfassung

Markus und sein Weg zur Softwareentwicklung

Mein ehemaliger Azubi Markus arbeitet bei der Alten Oldenburger und studiert nach seiner Ausbildung dual Wirtschaftsinformatik. Über Gaming und Delphi-Bücher seines Vaters kam er zum Programmieren. Im Unternehmen entwickelt er domänenspezifische Sprachen und Werkzeuge für Entwickler:innen.

Beruflich arbeitet er hauptsächlich auf der Java-Plattform, wobei auch Xtend und Groovy dazugehören. Privat programmiert er gern mit C# und beschäftigt sich mit Kotlin. Dabei gefallen ihm funktionale Sprachmittel und die Möglichkeit, ausdrücklich festzulegen, ob ein Wert null sein darf. Bei Entwicklungsumgebungen legt er Wert darauf, viel mit der Tastatur erledigen zu können. Vim-Erweiterungen und eine Command Palette helfen ihm dabei.

Was eine domänenspezifische Sprache abbildet

An SQL lässt sich das Prinzip einer domänenspezifischen Sprache, kurz DSL, nachvollziehen: Du beschreibst Aufgaben aus einem bestimmten Bereich, während die Technik dahinter deine Angaben auswertet. Bei SQL betrifft das den Zugriff auf Datenbanken.

Eine DSL kann auch Bedingungen oder Schleifen enthalten. Welche Sprachmittel dazugehören, hängt davon ab, welche Aufgaben du lösen möchtest. Wenn du zusätzliche Funktionen einbaust, wächst die Komplexität der Sprache.

Beim Entwerfen klärst du deshalb zuerst, welche fachlichen Aufgaben deine Sprache abbilden soll und wer damit arbeiten wird. Als Zielgruppe kommen Entwickler:innen ebenso infrage wie Mitarbeiter:innen eines Fachbereichs. Deren Anforderungen fließen in den Sprachumfang ein.

Du kannst deutsche Schlüsselwörter verwenden und sogar ganze Sätze zulassen. Ein Satz wie "Ein Vertrag hat viele Versicherte" könnte eine Struktur beschreiben, aus der später eine Liste von Versicherten entsteht. Wenn du die Begriffe des Fachbereichs übernimmst, erleichtert das den Austausch mit deinen Ansprechpartner:innen. Dieser Gedanke findet sich auch im Domain-driven Design.

Eine DSL als IHK-Abschlussprojekt

Für sein Abschlussprojekt entwickelte Markus eine Sprache, die festlegt, welche:r Mitarbeiter:in ein eingescanntes Dokument erhält. Die Regeln dafür standen zuvor direkt in einem .NET-Programm und waren mit der Zeit unübersichtlich geworden.

In der DSL erscheinen fachliche Begriffe wie "Regel" und "Zuweisung". Aus den beschriebenen Regeln entsteht C#-Code. Wer eine Regel verfasst, kann sie dadurch deklarativ mit den Begriffen des Fachbereichs ausdrücken.

Auf Wunsch des Fachbereichs beschreibt jede Regel einen einzelnen Fall. Für alternative Bedingungen werden separate Regeln angelegt. Soll etwa ein Vorname mit A oder B beginnen dürfen, entstehen dafür zwei Regeln. Über deren Namen lässt sich nachvollziehen, warum ein Dokument einer bestimmten Person zugewiesen wurde.

Beim Entwerfen ging Markus gemeinsam mit einem Ansprechpartner aus dem Fachbereich die vorhandenen C#-Regeln durch. Sie schrieben diese direkt in einer geordneten Textform auf, aus der sich die spätere Sprache entwickelte.

Mit Xtext eine eigene Sprache entwickeln

Zum Einstieg definierst du in Xtext die Grammatik deiner Sprache in einer Form, die auf der Backus-Naur-Form beruht. Darin legst du fest, wie gültige Texte aufgebaut sind. Die Grammatik des Abschlussprojekts umfasste ungefähr 40 bis 50 Zeilen.

Aus dieser Grammatik erzeugt Xtext unter anderem:

Lexer und Parser, die den eingegebenen Text verarbeiten.

Ein Eclipse-Plugin beziehungsweise einen Language Server für die Arbeit etwa in Visual Studio Code.

Einen Editor mit Syntax-Highlighting und kontextbezogener Code-Vervollständigung. In Eclipse gehört auch eine Outline dazu.

Xtext bildet die beschriebenen Elemente als Java-Objekte ab und kann Verweise zwischen ihnen auflösen. Dadurch kannst du im erzeugten Editor ausprobieren, ob deine Sprache so funktioniert, wie du sie entworfen hast.

Anschließend programmierst du, welcher Code aus den Angaben entstehen soll. Für eine Routingregel kann der Generator beispielsweise eine C#-Klasse schreiben. Das Eclipse-Plugin lässt sich um eigene Prüfungen oder Refactorings erweitern.

Code mit Xtend erzeugen

Für den Generator kannst du Java oder andere Sprachen auf der JVM verwenden. Xtend wurde ebenfalls mit Xtext entwickelt und bietet Funktionen, die das Erzeugen von Code erleichtern. Es ist eine allgemeine Programmiersprache, aus der Java-Code entsteht.

In mehrzeiligen Textvorlagen kannst du Werte oder Ergebnisse von Methodenaufrufen einsetzen. Xtend berücksichtigt dabei die Einrückung, sodass sich auch der erzeugte Code übersichtlich formatieren lässt.

Markus empfand das Lernen während seiner Ausbildung zunächst als anspruchsvoll. Mit Tutorials erschloss er sich die Grammatikbeschreibung; bei Xtend half ihm später, die Nähe zu Java zu erkennen. Durch die weitere Arbeit verstand er besser, wie Sprachen übersetzt werden und weshalb ihre Syntax eindeutig sein muss. Dieses Wissen konnte er auch im Studium einbringen.

Projektwahl und Ergebnisse in der Praxis

Als Markus sein Abschlussprojekt auswählte, hatte er bereits eine DSL entwickelt und kannte Xtext aus seiner täglichen Arbeit. Der damals vorgegebene Rahmen von 70 Stunden musste realistisch einzuhalten sein. Für dein eigenes Projekt empfehle ich dir deshalb ein Thema, bei dem du auf vorhandene Erfahrungen aufbauen kannst.

...

Funktionale Programmierung, Konferenzvorträge und Fachartikel im Gespräch mit Gregor Trefs sind das Thema der einhundertsechsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit Gregor Trefs bespreche ich, wie du als IT-Azubi funktionale Programmierung lernen und in Java einsetzen kannst. Reine Funktionen machen das Verhalten deines Codes nachvollziehbar, während unveränderliche Werte und kombinierbare Funktionen helfen, Verantwortlichkeiten aufzuteilen. Am Combinator-Pattern und an FizzBuzz wird deutlich, wie sich diese Konzepte praktisch ausprobieren lassen. Ein eigenes Blog und der Austausch in einer User Group helfen dir, dein Wissen zu vertiefen und erste Fachartikel oder Vorträge vorzubereiten.

Kapitelmarken

[00:00:01] Thema und Einführung

[00:01:36] Gregor Trefs und sein Weg zur Softwareentwicklung

[00:05:35] Erfahrungen mit Java, Scala, Kotlin und Haskell

[00:10:42] Kotlin, Typsysteme und IDE-Werkzeuge

[00:14:17] Neue Konzepte in vertrauter Java-Syntax lernen

[00:15:40] Einstieg mit Onlinekursen, Büchern und einer Lerngruppe

[00:20:14] Reine Funktionen und das Substitutionsmodell

[00:23:52] Memoization und Effekte getrennt ausführen

[00:26:39] Funktionen höherer Ordnung und Composability

[00:31:08] Unveränderliche Werte und persistente Datenstrukturen

[00:36:03] Funktionale Werkzeuge mit Vavr

[00:39:57] Funktionale Konzepte im Entwicklungsteam

[00:43:23] Monaden und Berechnungen in einem Kontext

[00:45:46] Gesetze, Lambda-Kalkül und Ein- und Ausgabe

[00:50:32] Praktisch anfangen und Fachbegriffe verstehen

[00:53:31] Das Combinator-Pattern am Beispiel von Prüfregeln

[00:58:41] JavaLand-Newcomer-Track und den Vortrag vorbereiten

[01:04:00] Java User Group Mannheim und erste eigene Vorträge

[01:08:14] Functional FizzBuzz und die Regeln der Aufgabe

[01:10:09] Funktionaler Kern und Pattern Matching

[01:12:56] FizzBuzz mit Strömen und Funktionen lösen

[01:16:52] Wiederkehrende Muster und FizzBuzz in Interviews

[01:20:03] FizzBuzz in der IT-Ausbildung

[01:20:44] Feedback und Umgang mit harter Kritik

[01:24:09] Vom Blog zum Fachartikel und durch Schreiben lernen

[01:28:19] Als Einsteiger:in Wissen veröffentlichen

[01:29:59] Bücher zu funktionaler Programmierung und Softwaredesign

[01:36:54] Kontakt zu Gregor und Konzepte im Team ausprobieren

[01:39:30] Eigene Beiträge veröffentlichen und Feedback geben

Inhalt

Folgende Fragen gehen wir im Verlaufe des Interviews durch.

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du?

Gregor Trefs, 31 Jahre alt

Momentan bin ich freiberuflich unterwegs

Themen: Java und Security

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Computer fand ich interessant

Erster Rechner: 486

Erstes Programm mit 12 Jahren geschrieben: Text-Adventure in Basic

Viel Macromedia Flash: ActionScript 2 (ECMA Script Derivat)

Mit 16 auf ein technisches Gymnasium gegangen

Software und Hardware

Design

Hauptsächlich Java

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

Studium Wirtschaftsinformatik

Viel Abwechslung

Nie das Interesse verloren

Tutorentätigkeit in Softwaretechnik

Masterarbeit im Bereich künstliche Intelligenz

Semantic Web Technolgies

Hadoop

Mit welcher Programmiersprache arbeitest du im Alltag?

Hauptsächlich Java

Nebenbei Kotlin und Scala

Lieblingsprogrammiersprache

Klar man arbeitet mit manchen Sprachen lieber als mit anderen.

Jedoch ist das nicht einfach

Immer eine Frage wie vertraut man mit der Sprache ist

Faszinierend finde ich Scala

Sehr viel dabei

Stichwort: Typelevel Programming

Jedoch: Steile Lernkurve und manchmal eine Sytax zum Wegrennen

Auch sehr wissenschaftlich orientiert

Forschungssprache etc.

Compiler finde ich toll

Tolle Inferenz

Hier möchte ich noch mehr lernen

Praktikabel finde ich Kotlin

Kompatibel mit Java und der Compiler hilft mehr

Typinferenz val/var etc.

Nulltypes ist interessant

Kein Fan der Lamdba-Syntax, da geschweifte Klammer für mich zu überladen wirkt

Geht schnell voran

Coroutines sehen toll aus

Bessere Abstraktion für parallele Programmierung im Vergleich mit Java

JavaScript

Ich möchte mal wirklich was Nettes mit machen

Leider nie wirklich die Zeit gefunden

Ich finde Flow Types toll und auch normale Linter

JSON in Javascript fühlt sich einfach besser an

Haskell

Verdreht einem den Kopf ;-)

Gut zum Lernen von FP

Verständnis für Equational Reasoning steigt

Angst vor Monaden wird genommen, da Monaden einen klaren Zweck erfüllen

Bspw. pure functional IO -> IO Monade

Nie produktiv eingesetzt

Java

Kenne ich am besten

Entdecke doch immer was Neues (z.B. java.nio)

Lambda-Syntax sehr angenehm

Leider etwas komplexes Typsystem

Referenz- vs. primitive Typen

Type Erasure

Sehr große Community

Funktionale Programmierung

Wie würdest du die funktionale Programmierung (FP) einem Einsteiger erklären?

FP ist ein Programmierparadigma

Eine bestimmte Ansicht wie ein Computerprogramm gestaltet wird

Grundlegendes Element: Funktion

Es basiert auf dem Lambda-Kalkül von Alonzo Church

Formale Sprache zur Untersuchung von Funktionen

Formal: Grammatik und Alphabet unwidersprüchlich durch Mathematik ausgedrückt

Beschreibt Umwandlungsregeln wie Funktionen bspw. auf Argumente angewendet werden

Verzicht auf die Änderung eines globalen Zustands

Unterschied zu imperativ: Zustandsänderung durch Imperative

Erleichtert semantische Analyse

Bedeutung? Ersetze Funktionen rekursiv durch ihren Rückgabewert

Form der Auswertung: Subsitutionsmodell

Problem: I/O

Im Lambda-Calculus geht es um die Anwendung von Umformungsregeln auf Lambda-Ausdrücken bis keine Regel mehr anwendbar ist

Wenn wir aber nur Umformungsregeln haben, wie modellieren wir dann Input und Output und bleiben dem Lambda-Kalkül treu?

Anders gefragt, wie bleibt eine funktionale Sprache mit I/O pur?

Verschiedene Lösungen

Prozeduren kümmern sich um Input und Output und "füttern" einen funktionelen Kern

Beschreibung des Effektes mit puren Funktionen welche dann mit einem Interpreter ausgeführt werden (Stichwort: Monaden)

Seiteneffekte am Rand der Applikation und wohldefiniert

Ohne Angst an die Materie herangehen und Verständnisfehler akzeptieren

Welche wichtigen Konzepte zeichnen die FP aus?

Einfaches Nachvollziehen von Verhalten (Substitutionsmodell)

Trennung von Beschreibung und eigentlicher Ausführung

Kein geteilter globaler Zustand

Komposition von Funktionen

Funktionen höherer Ordnung

Klare Trennung von Verantwortlichkeiten

Implizite Informationen können explizit modelliert werden

FP ist ja eigentlich schon uralt! Warum sollte man sich heute (wieder) damit beschäftigen?

Neues Paradigma: Neue Lösungen für alte Probleme

Mehrkern-Prozessoren: Funktionen auf je einem Kern ausführen

Vgl. John Carmack: "My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."

Spaß

Welche Vorteile hat FP gegenüber der Objektorientierung (OO)?

Meine Meinung

Keine Seiteneffekte, dadurch einfacheres Nachvollziehen

Funktionen sind per se kompositionierbar

Keine Seiteneffekte, dadurch bessere Testbarkeit

Input -> Output

Funktionen in einem Kontext ausführen

Beispiel: Transaktionen

Imperativ: begin -> code -> end

Funktional: Transaction(f) map(g) flatMap(Transaction(h)) run

Man arbeitet mit Werten

Einmal erstellt ändern sich diese nicht

Gegenargumente

Mit OOP lassen sich Klassen modellieren, die einer Funktion ähneln

Specification Pattern: Create Specification and run against Candidate

Veränderbare Strukturen dominant in Java

Immutables keine Alternative: Speicher

Lösung: Purely functional data structures (siehe vavr)

Immutable: Keine Änderung -> neue Instanz, jedoch Structural Sharing

Persistent: Alte Struktur bleibt erhalten

Wie schwer fiel/fällt dir der Wechsel zwischen FP und OOP?

Ökonomische Sicht: Solange FP bis Kosten größer als anderes Paradigma

Sprache?

FP Wissen?

Am Anfang eine riesen Lernkurve

Viele Konzepte, die erst verstanden werden müssen und eingeordnet

Historische Recherche hat mir auch ein bisschen dabei geholfen

Ich kann nicht alles in FP

Das FP gibt es auch nicht

Bspw. sind LISP und Clojure untypisiert

OCAML und Haskell stark typisiert

Ähnlicher Kampf wie bspw. JavaScript vs. Java

Aber auch Scala vs. Java

Ziel: Produktiv arbeiten. Code der unseren Ansprüchen genügt.

Ich benutze FP da, wo es Sinn macht und soweit mein Verständnis mich trägt

Nutzt du im Alltag nur Konzepte der FP in OO-Sprachen oder rein funktionale Sprachen?

Primäre Sprache: Java

Java ist keine funktionale Sprache

Die Bedeutung eines Java-Programs ist definiert durch das Memory Model

Das Memory Model regelt, wie Threads durch Speicher miteinander kommunizieren

D.h. per se gibt es shared mutable state

Jedoch funktionale Konzepte

Unveränderliche Werte

Funktionen benutzen

Monaden

Combinatoren

Ich nutze Kotlin und Java

Magst du persönlich lieber FP, OO oder eine Kombination aus beiden und warum?

Mir gefällt die Idee von FP besser

OOP hatte ein paar Versprechen die nicht ganz eingehalten wurden

siehe lambdafy

Code Reuse: Compose functions

Wie können auch unerfahrene Entwickler mit FP beginnen?

Code-Katas: Probleme mit Funktionen lösen

Online Kurse: Coursera, EDX, etc.

Bücher: Learn you a Haskell for a greater good (Miran Lipovaca) Functional Programming in Scala (Paul Chiusano, Rúnar Bjarnason)

Vorträge auf Konferenzen

Worum ging es in deinem Vortrag auf der JavaLand?

Es ging um das Combinator Pattern in Java 8

Wie kam es zu deinem Vortag auf der Javaland?

Ich war letztes Jahr auf der Javaland und habe Leute auf dem Newcomer-T

Ich spreche mit Sascha Kersken über sein IT-Handbuch für Fachinformatiker in der einhunderfünften Episode des Anwendungsentwickler-Podcasts.

TL;DR

Ich spreche mit Sascha Kersken über das IT-Handbuch für Fachinformatiker:innen, das aus seinen Kursunterlagen entstanden ist und dich durch die Themen der IT-Ausbildung begleitet. Die besprochene achte Auflage bringt überarbeitete Inhalte zur Webentwicklung sowie zu Virtualisierung und Mobile Development. Du erfährst, wie Sascha Beispiele erprobt und Hinweise von Leser:innen in spätere Auflagen einarbeitet. Für deine Ausbildung stehen das eigene Ausprobieren, ein breites Grundlagenwissen und das Prüfen von Quellen im Mittelpunkt.

Kapitelmarken

[00:00:01] Einstieg und Vorstellung des Interviews

[00:01:12] Sascha Kerskens beruflicher Hintergrund

[00:01:59] Vom Kursmaterial zum IT-Handbuch

[00:05:05] Praxiserfahrungen und Programmiersprachen im Buch

[00:06:21] Ruby, Python und PHP

[00:09:16] Historische Hintergründe der Informatik

[00:12:57] Erste Programme und Informatikunterricht

[00:15:38] Programmierwettbewerb mit Turbo Pascal

[00:16:35] Von der Bankausbildung zum Quereinstieg in die IT

[00:20:04] Neue Inhalte der achten Auflage

[00:21:41] Swift-Beispiel und Fehlersuche zwischen Client und Server

[00:23:34] Ein Fachbuch mit Word schreiben

[00:25:01] Änderungen verfolgen und Dateien austauschen

[00:26:39] Satzfahnen, gedruckte Bücher und E-Books

[00:29:30] Buch und E-Book als Bundle

[00:30:26] Inhalte aktualisieren und ältere Themen entfernen

[00:33:53] Rezensionen und Hinweise von Leser:innen

[00:36:22] Das Handbuch für IT-Azubis

[00:38:00] Docker und Microservices im Berufsalltag

[00:39:42] Programmiergrundlagen und unterschiedliche Typsysteme

[00:42:26] IDEs für PHP und Python

[00:43:36] Ruby, Performance und die passende Sprache fürs Projekt

[00:47:00] Aufwendige Kapitel und Probleme mit Formeln

[00:49:22] Neue Themen beobachten und fürs Buch auswählen

[00:52:01] Breites Grundlagenwissen für Ausbildung und Prüfung

[00:53:10] Fachbücher als Leitfaden beim Lernen

[00:56:20] Fachlich prüfen, korrigieren und lektorieren

[00:58:47] Der Roman Göttersommer

[01:02:20] Figuren und Handlungsstränge beim Schreiben verfolgen

[01:05:16] Empfehlungen für weitere Fachbücher

[01:09:43] Tipps für IT-Azubis und Ausbilder:innen

[01:11:52] Quellen prüfen und Verantwortung in der IT

[01:15:08] Kontakt zu Sascha Kersken

[01:17:25] Shownotes und Feedback

Inhalt

Dies sind einige Fragen, die wir im Verlauf unseres Gesprächs durchgehen:

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

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

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

Was ist deine Lieblingsprogrammiersprache und warum?

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

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

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

Was sind die Neuerungen in der aktuellen Auflage des IT-Handbuchs für Fachinformatiker und warum wurden sie eingebaut?

Welches ist dein Lieblingskapitel und warum?

Welches Kapitel hat am meisten Arbeit gemacht und warum?

Wie kam es zur ersten Auflage? Gab es z.B. einen Auftrag oder hast du einfach selbstständig angefangen?

Warum sind Bücher in der heutigen Zeit und gerade im Bereich der IT noch für die Ausbildung relevant?

Sollte man das Buch von vorne bis hinten durcharbeiten oder es eher als Nachschlagewerk sehen?

Welches Feedback hast du von Auszubildenden zum Buch bekommen und vielleicht sogar in neue Auflagen einfließen lassen?

Welche Strategien hast du, um für dein Buch selbst in den verschiedenen Technologien auf dem Laufenden zu bleiben?

Macht das Schreiben und Aktualisieren nach all den Jahren noch Spaß?

Macht es dir mehr Spaß, Fachbücher oder Romane zu schreiben, und warum?

Gibt es Unterschiede beim Vorgehen beim Schreiben von Sachbüchern bzw. Romanen?

Hast du Tipps zur Aus-/Weiterbildung für angehende Softwareentwickler/-innen?

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

Literaturempfehlungen

Die neue Auflage 8 des IT-Handbuchs für Fachinformatiker ist schon beim Rheinwerk-Verlag vorbestellbar. Und wie im Podcast erwähnt gibt es ein Bundle aus Buch und eBook für einen geringen Aufpreis.

*

Und falls du es nicht mehr abwarten kannst, kommt hier noch die "alte" Auflage.

*(direkt beim Rheinwerk-Verlag bestellen*)

Und das hier ist Saschas Roman "Göttersommer", über den wir auch im Interview sprechen.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Sascha Kersken | Autor von Fachbüchern und Belletristik, Softwareentwickler

Sascha Kersken (@theNeo42) | Twitter

Sascha Kersken - Bücher

Sascha Kersken - Autor - Facebook

IT-Handbuch für Fachinformatiker - Facebook

Zusammenfassung

Wie das IT-Handbuch entstanden ist

Ich habe das rund 1.300 Seiten umfassende IT-Handbuch für Fachinformatiker:innen bereits in einem Buchclub mit 14 Folgen durchgearbeitet und empfehle es als Begleiter für deine Ausbildung. Im Gespräch mit seinem Autor Sascha Kersken geht es auch darum, wie seine Erfahrungen aus IT-Kursen in das Buch eingeflossen sind.

Sascha arbeitet als Softwareentwickler in einer Kölner Webagentur. Er hat über viele Jahre IT-Kurse gegeben und schreibt beziehungsweise übersetzt nebenberuflich Fachbücher. Während seiner ersten sieben Jahre als Trainer sammelte er zahlreiche selbst erstellte Kursunterlagen, aus denen später das Handbuch entstand.

Anfangs richtete sich seine Buchidee an Mediengestalter:innen, denen er technische Grundlagen und Webentwicklung vermittelte. Beim damaligen Verlag Galileo Computing, heute Rheinwerk, erschien daraus das Kompendium der Informationstechnik. Es enthielt auch Themen wie Bildbearbeitung und Grafik. In späteren Auflagen rückte die Ausbildung zum/zur Fachinformatiker:in stärker in den Mittelpunkt, wodurch sich der Umfang der behandelten Themen veränderte.

Die Erfahrungen mit Fragen von Kursteilnehmer:innen halfen Sascha dabei, Inhalte verständlich anzuordnen. IT-Azubis in seiner Firma erhalten das Buch zu Beginn ihrer Ausbildung; ihre Erfahrungen bespricht er mit ihnen, obwohl er dort keine offizielle Rolle als Ausbilder hat.

Saschas Weg in die IT

Mit zwölf Jahren begann Sascha auf einem BASIC-basierten Heimcomputer zu programmieren. Er tippte Programme aus einem Handbuch ab und veränderte sie anschließend. Ein Informatiklehrer ermöglichte ihm schon früh, im Computerraum seiner Schule weiterzulernen.

Mit 17 entwickelte er gemeinsam mit einem Mitschüler in Turbo Pascal Programme für die Oberstufenkurswahl und Kursblockung. Bei einem Wettbewerb von Nixdorf gewannen sie damit eine Reise nach Helsinki.

Nach dem Abitur absolvierte Sascha eine Ausbildung zum Bankkaufmann. Seine Fähigkeiten mit Excel führten bereits dort dazu, dass verschiedene Abteilungen ihn für entsprechende Aufgaben einsetzten. Über einen späteren Kontakt zu einer Weiterbildungsfirma kam er zum Unterrichten und wechselte als Quereinsteiger in die IT. Sein persönlicher Zugang zum Programmieren liegt im Verständnis von Programmiersprachen als Kommunikationsmittel.

Was die besprochene achte Auflage verändert

Die im Gespräch angekündigte achte Auflage überarbeitet mehrere Bereiche:

Webentwicklung: Die Inhalte zu HTML5 und CSS3 wurden zusammen mit den JavaScript-Beispielen erneuert. Responsive Design kommt ebenfalls vor.

Virtualisierung: Das Kapitel wurde erweitert und enthält VirtualBox als Beispiel. Docker ergänzt den Bereich um Container.

Mobile Development: Änderungen in Swift 3 machten es erforderlich, die entsprechenden Inhalte neu zu schreiben.

Darüber hinaus prüft Sascha bei jeder Auflage die beschriebenen Programme anhand ihrer aktuellen Versionen. Dazu gehört, ob sich die Software noch wie beschrieben installieren lässt. Hardwareangaben brauchen ebenfalls regelmäßige Aufmerksamkeit, weil sich etwa übliche RAM-Größen und Bildschirmauflösungen verändern.

Die achte Auflage wächst gegenüber ihrer Vorgängerin um ungefähr zehn Seiten. Zugleich entfallen ältere oder weniger relevante Abschnitte. Frühere Inhalte zu Netzwerkprotokollen außerhalb von TCP/IP und zu Token Ring wurden beispielsweise entfernt. Einige historische Grundlagen, darunter Koaxialkabel, bleiben enthalten.

Die angekündigte Ausgabe soll Ende Juni erscheinen und anschließend für ungefähr zwei Jahre die aktuelle Auflage bleiben. Diese Angaben beziehen sich auf den Zeitpunkt des Gesprächs.

Wie Beispiele entstehen und Fehler auffallen

Sascha setzt die Programmierbeispiele selbst um und übernimmt den Code aus seiner IDE ins Manuskript. Bei Themen außerhalb seines täglichen Arbeitsbereichs arbeitet er sich zusätzlich ein. Python lernte er für eine frühere Auflage, in der es Perl und Ruby ersetzte. Anschließend konnte er das Wissen auch in einem beruflichen Django-Projekt einsetzen.

Beim Überarbeiten des Swift-Beispiels suchte er etwa anderthalb Tage nach einem Fehler auf der Clientseite. Die Ursache lag in der Serverkonfiguration: Apache lieferte die Daten gzip-komprimiert aus, womit das verwendete Beispiel Schwierigkeiten hatte. Diese Erfahrung steht als Infokasten im Buch und zeigt dir, weshalb du beim Debuggen auch die beteiligten Systeme und die übertragenen Daten prüfen solltest.

Schreiben und fachliches Prüfen

Für das Manuskript stellt der Verlag eine Word-Vorlage bereit. Jedes Kapitel liegt in einer eigenen Datei. Die Vorlage enthält passende Formatvorlagen und Makros, beispielsweise für Abbildungen und Tabellen. Für Code gibt es sprachabhängige Formate, mit denen die farbige E-Book-Ausgabe Syntax-Highlighting erhält.

Korrektor:innen und Lektor:innen arbeiten mit der Änderungsverfolgung und Kommentaren. Die Dateien werden über Nextcloud ausgetauscht. Sascha würde sich dafür ein System mit Versionsverwaltung wünschen. Die gesetzten Seiten prüft er inzwischen als PDF.

Besondere Aufmerksamkeit verlangt das Kapitel zu mathematischen und technischen Grund

Ein kostenloses Probekapitel meines neuen Hörbuchs zur Vorbereitung auf das Fachgespräch zum Thema NoSQL gibt es in der einhundertvierten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Für dein Fachgespräch als Fachinformatiker:in Anwendungsentwicklung gehe ich die fünf im Hörbuch behandelten NoSQL-Datenbankmodelle durch und zeige dir passende Einsatzgebiete. NoSQL steht für "Not Only SQL" und umfasst Konzepte, die du je nach Aufgabe gemeinsam mit relationalen Datenbanken einsetzen kannst. Du erfährst, wie die einzelnen Modelle Daten speichern und welche Systeme du im Fachgespräch als Beispiele nennen kannst. Mein neues Datenbank-Hörbuch enthält außerdem allgemeine Hinweise dazu, wie du dich auf Fragen vorbereitest und auf Prüfer:innen reagierst.

Kapitelmarken

[00:00:01] Einstieg ins Fachgespräch

[00:00:37] Neues Datenbank-Hörbuch und Umfang

[00:01:41] Allgemeine Hinweise zu Fragen im Fachgespräch

[00:02:48] NoSQL-Kapitel als Hörprobe

[00:04:16] Was NoSQL bedeutet und wofür es eingesetzt wird

[00:08:23] Fünf Arten von NoSQL-Datenbanken

[00:09:10] Spaltenorientierte Datenbanken

[00:12:04] Objektorientierte Datenbanken

[00:13:59] Key-Value-Stores und In-Memory-Caches

[00:16:04] Dokumentendatenbanken

[00:19:28] Graphdatenbanken und Cypher

[00:23:05] Bekannte NoSQL-Systeme und Antworten im Fachgespräch

[00:24:55] Umfang und Download der Hörbücher

[00:26:12] Preise und Rabattaktion bis Mai 2017

[00:27:45] Fragenlisten, Hörproben und Rückgaberecht

[00:28:45] Website und weitere Inhalte der Hörbücher

Inhalt

Das Hörbuch findest du hier: Das perfekte Fachgespräch.

NoSQL

Was ist NoSQL und wofür braucht man das?

Steht für "Not only SQL". Fasst die "modernen" Datenbanken zusammen. Sinnvolle Ergänzung zu relationalen Datenbanken.

Welche Arten von NoSQL-Datenbanken gibt es?

spaltenorientierte Datenbanken

objektorientierte Datenbanken

Key-Value-Stores

Dokumentendatenbanken

Graphendatenbanken

Wie funktionieren spaltenorientierte Datenbanken?

Die Datenbank speichert ihre Datensätze nicht zeilenweise, sondern spaltenweise. Dadurch sind bestimmte Auswertungen (wie z.B. die Summe über alle Werte einer Spalte) einfacher und performanter durchführbar.

Wie funktionieren objektorientierte Datenbanken?

Die Datenbank legt Objekte im Sinne der Objektorientierung direkt ab.

Wie funktionieren Key-Value-Stores?

Sie bilden ein assoziatives Array (Schlüssel-/Wert-Paare, auch Hash bzw. Dictionary genannt) ab.

Wie funktionieren Dokumentendatenbanken?

Die Datenbank speichert komplette unstrukturierte Dokumente ggfs. mit eingebetteten Unterdokumenten.

Wie funktionieren Graphendatenbanken?

Die Datenbank speichert vernetzte Informationen in Form von Graphen, die aus Knoten und Kanten bestehen. So kann sie Gebrauch von etablierten Graphenalgorithmen machen, um bspw. die kürzeste Verbindung zwischen zwei Knoten zu finden.

Welche bekannten NoSQL-Datenbanken gibt es und wie heißen ggfs. die Hersteller?

spaltenorientierte Datenbanken

Cassandra von Apache

HBase von Apache

objektorientierte Datenbanken

db4o

Key-Value-Stores

Riak

Redis

Dokumentendatenbanken

Lotus Notes

MongoDB

CouchDB von Apache

Graphendatenbanken

Neo4J

Literaturempfehlungen

Eine kurze und gut verständliche Einführung in verschiedene NoSQL-Datenbanken und ihre Stärken und Schwächen.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Weitere Infos zum FachgesprächDu suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt anmelden!

Zusammenfassung

NoSQL im Fachgespräch

Mit einem Kapitel aus meinem Datenbank-Hörbuch bereite ich dich auf mögliche Fragen zu NoSQL vor. Der Begriff steht für "Not Only SQL", ausgeschrieben "Not Only Structured Query Language". SQL steht dabei stellvertretend für relationale Datenbanken.

Unter NoSQL werden je nach Literatur verschiedene Datenbankmodelle zusammengefasst. Die fünf hier behandelten Modelle haben jeweils eigene Eigenschaften und Einsatzgebiete. Einige lassen sich mit SQL abfragen; andere bringen eigene Abfragesprachen mit.

In einer Anwendung können mehrere Datenbankmodelle zusammenarbeiten. Wenn ich etwa einen Warenkorb aus zahlreichen relationalen Tabellen zusammenstelle, kann ich das Ergebnis in einem Key-Value-Store zwischenspeichern. Bei späteren Anfragen lässt sich der gesamte Warenkorb über einen Schlüssel abrufen, wodurch die relationale Datenbank entlastet wird. Für die zugrunde liegenden Daten kann sie weiterhin zuständig bleiben.

Auch die Struktur der Daten spielt bei der Wahl eine Rolle. Beziehungen zwischen Personen in einem sozialen Netzwerk lassen sich beispielsweise als Graph darstellen.

Spaltenorientierte Datenbanken

Wenn du den Durchschnittspreis aller Artikel berechnen möchtest, brauchst du die Werte einer bestimmten Spalte. Eine spaltenorientierte Datenbank legt solche Werte physisch hintereinander ab, sodass sie sich effizient lesen und auswerten lassen.

Um einen vollständigen Datensatz zusammenzustellen, muss die Datenbank die zugehörigen Werte aus den einzelnen Spalten zusammenführen. Welche Ablage geeignet ist, hängt deshalb davon ab, welche Abfragen du durchführen möchtest.

Typische Einsatzgebiete sind Data Warehouses und Anwendungen, in denen du regelmäßig Statistiken über ganze Spalten berechnest. Spaltenorientierte Datenbanken lassen sich häufig mit SQL abfragen.

Als Beispiele für diesen Bereich nenne ich Apache Cassandra und Apache HBase.

Objektorientierte Datenbanken

Beim Speichern von Objekten in einer relationalen Datenbank müssen Objektreferenzen auf Fremdschlüssel abgebildet werden. Beim Lesen werden daraus wieder Referenzen. Diese Unterschiede zwischen den Datenmodellen werden als Impedance-Mismatch bezeichnet.

Eine objektorientierte Datenbank speichert Objekte samt ihren Referenzen direkt. Dadurch entfällt das Mapping zwischen der objektorientierten Anwendung und der relationalen Ablage. Du kannst einen Objektbaum speichern und später wieder einlesen.

Das passt zu Anwendungen, die du objektorientiert entwickelst, weil sich das Datenmodell deiner Programmiersprache unmittelbar ablegen lässt. Ein genannter Vertreter ist db4o, ausgeschrieben "Database for Objects".

Key-Value-Stores

Aus einer HashMap oder einem Dictionary kennst du das Prinzip bereits: Unter einem eindeutigen Schlüssel liegt ein Wert, auf den du über diesen Schlüssel zugreifst.

Der Wert kann ein umfangreiches JSON-Dokument sein, das einen komplexen Objektbaum enthält. Beim hier beschriebenen Modell erfolgt der Zugriff über den Schlüssel.

Key-Value-Stores werden häufig als Cache eingesetzt. Darin lassen sich Ergebnisse aufwendiger Datenbankabfragen oder Berechnungen ablegen, damit sie bei einer späteren Anfrage mit einem Zugriff verfügbar sind.

Bei einem In-Memory-Cache liegen die Inhalte im Arbeitsspeicher. Dadurch lassen sich häufig angefragte Werte schnell bereitstellen. Als Beispiele nenne ich Riak und Redis.

Dokumentendatenbanken

In einer Dokumentendatenbank werden zusammengehörige Daten als Dokumente abgelegt. Die Sammlung solcher Dokumente heißt je nach System beispielsweise Collection.

Ein Dokument kann Unterdokumente und Arrays enthalten, wodurch sich hierarchische Strukturen speichern lassen. Auch Referenzen auf andere Dokumente sind möglich. Wenn alle zugehörigen Daten eingebettet sind, stehen sie beim Lesen mit einem Zugriff bereit.

Innerhalb einer Collection können Dokumente unterschiedliche Attribute besitzen. In einer Sammlung von Personen könnte beispielsweise ein Dokument Hobbys enthalten, während ein anderes einen zusätzlichen Namensbestandteil führt. Über die Attribute lassen sich dennoch Daten suchen und Indizes anlegen.

Diese Flexibilität eignet sich für Rapid Prototyping, wenn sich die benötigte Datenstruktur während des Entwickelns noch verändert. Attribute lassen sich ergänzen oder umbenennen, ohne dafür jedes Mal eine starre Tabellenstruktur anzupassen.

JSON-Dokumente lassen sich zudem gut mit JavaScript verarbeiten, weil die eingelesenen Daten als Objekte weiterverwendet werden können. Genannte Systeme sind MongoDB und Apache CouchDB. Auch Lotus Notes, das vielen als E-Mail-Anwendung bekannt ist, basiert auf einer Dokumentendatenbank.

Graphdatenbanken

Mit einem Graphen kannst du beispielsweise darstellen, welche Person eine andere kennt. Die Personen bilden Knoten, ihre Beziehungen werden als Kanten gespeichert. Eine Kante kann eine Bezeichnung wie "kennt" tragen.

Sowohl Knoten als auch Kanten können Eigenschaften besitzen. Bei einer Person wären das etwa Name und Alter; an der Beziehung könnte das Datum stehen, an dem sich beide kennengelernt haben.

Graphalgorithmen helfen dabei, Verbindungen zwischen Knoten zu untersuchen. In einem sozialen Netzwerk lässt sich damit beispielsweise ermitteln, über welche Kontakte zwei Personen miteinander verbunden sind.

Weitere Einsatzgebiete sind Navigationssysteme mit Verbindungen zwischen Städten sowie Fertigungsanlagen, deren Stationen über Transportbänder miteinander verbunden sind.

Ein bekanntes System ist Neo4j. Dessen Abfragesprache heißt Cypher und stellt Beziehungen mit Zeichen dar, die an gezeichnete Graphen erinnern.

Antworten im Fachgespräch vertiefen

Wenn du nach NoSQL oder bekannten Datenbanksystemen gefragt wirst, kannst du deine Antwort mit einem konkreten Modell und einem passenden Anwendungsfall ausbauen. Dazu gehören die Eigenschaften des Modells und die Gründe, aus denen es für die jeweilige Aufgabe geeignet ist.

Bei einer Frage nach bekannten Produkten würde ich nach den Namen auf die betreffenden Modelle eingehen und

Eine Einführung in Test Driven Development (TDD) gibt es in der einhundertdritten Folge des Anwendungsentwickler-Podcasts.

TL;DR

Bei Test-Driven Development (TDD) schreibst du automatisierte Tests vor dem Produktivcode und entwickelst in kleinen Schritten. Jeder neue Test muss zunächst aus dem passenden Grund fehlschlagen, bevor du ihn mit möglichst wenig Code erfolgreich ausführst und den Code anschließend überarbeitest. Dadurch entsteht ein Testnetz, das Fehler nach Änderungen aufdeckt und einen modularen Softwareentwurf fördert. Aus meiner Praxis zeige ich dir auch, wie du passende Testfälle findest und welche Hürden beim Einstieg sowie bei bestehendem Code auftreten.

Kapitelmarken

[00:00:00] Einstieg in Test-Driven Development

[00:01:33] Meine Masterarbeit und NATUnit

[00:02:31] Was ist testgetriebenes Entwickeln?

[00:03:56] Der klassische TDD-Zyklus

[00:05:11] Die TDD-Ampel und kompilierbare Tests

[00:07:09] Tests als Sicherheitsnetz beim Refactoring

[00:08:01] Regressionen nach Änderungen

[00:09:03] Warum Tests aus dem richtigen Grund fehlschlagen müssen

[00:12:11] Mit möglichst wenig Code einen Test erfüllen

[00:13:33] Refactoring am Beispiel einer Wurzelfunktion

[00:14:45] YAGNI und kleine Entwicklungsschritte

[00:18:05] Schnelles Feedback beim Überarbeiten von Code

[00:20:30] Mein erweiterter TDD-Zyklus

[00:21:39] Aussagekräftige Fehlermeldungen

[00:24:16] Auch Testcode refaktorisieren

[00:26:52] Hürden und zusätzlicher Zeitaufwand

[00:28:28] Legacy Code und schwer testbare Abhängigkeiten

[00:30:09] Vorteile für Testabdeckung und Softwareentwurf

[00:32:49] Zeit sparen und mit Code experimentieren

[00:35:37] Praktisch mit TDD anfangen

[00:37:06] Erste Testfälle und der Happy Path

[00:38:06] Grenzwerte und Fehlersituationen testen

[00:39:50] Testfälle aus Äquivalenzklassen auswählen

[00:41:40] Was ist ein Regressionstest?

[00:43:00] Video und Bücher für den Einstieg

[00:46:41] Weiterführende Literatur und meine Masterarbeit

[00:48:07] TDD in der Ausbildung und im Arbeitsalltag

Inhalt

Was ist Test Driven Development (TDD)?

Beim TDD werden die Tests vor dem Produktivcode geschrieben.

Wie läuft der TDD-Zyklus ab?

Red, green, refactor. Der Test muss fehlschlagen, dann wird er so einfach wie möglich grün gemacht, dann wird refaktorisiert.

Was ist der erweiterte TDD-Zyklus?

Red, optimize failure message, green, refactor, refactor tests. Zusätzlich zum normalen Zyklus wird Wert auf sprechende Meldungen bei Fehlschlägen gelegt und auch der Test-Code explizit refaktorisiert.

Wie kann man TDD mit Integrationstests kombinieren?

Wie in GOOS* beschrieben: Zuerst Integrationstest schreiben, der längere Zeit fehlschlägt, und dann Schritt für Schritt mit Unit-Tests auf grünen Integrationstest hinarbeiten.

Warum heißt TDD auch Test Driven Design?

Weil sich das Design der Anwendung erst beim Programmieren ergibt.

Was sind Vorteile von TDD?

Tests werden nicht vergessen.

Hohe Testabdeckung des Produktivcodes.

Gute Modularisierung des Codes durch Fokussierung der Tests.

Hohe Testbarkeit des Codes (wenig Abhängigkeiten).

Langfristig Zeiteinsparung bei der Weiterentwicklung, da Regression sofort erkannt wird.

Experimente und Refactorings werden durch Testnetz erst ermöglicht.

Was sind Nachteile von TDD?

Umstellung beim Entwickler nötig.

Zunächst höherer Zeitaufwand.

Legacy Code ist meist nicht gut testbar.

Wie findet man Testfälle?

Start mit "Happy Path"

übliche Geschäftsvorfälle

einfachste Fälle

Edge-Cases/Grenzwerte

Sonderfälle

Was sind Äquivalenzklassen?

Werte, deren Verwendung in Tests zum Durchlaufen des gleichen Pfades im Code führen und damit nicht zusätzlich getestet werden müssen (Beispiel "positive Zahl" 5 und 322).

Was ist ein Regressionstest?

Regressionstest stellen sicher, dass Abweichungen vom bisherigen Verhalten (Regression) schnellstmöglich erkannt werden.

Wie steigt man am besten in TDD ein?

Nicht lange schnacken (lesen), Kopp in' Nacken (coden)! Einfach machen! Am besten mit Code Katas.

Literaturempfehlungen

Zum Einstig schau dir mal diese perfekt auf die Begleitmusik angepasste Implementierung der Kata "Prime Factors" von Uncle Bob an:

Prime Factors Kata in Ruby, Flower Duet, Lakme'

Zum Thema TDD empfehle ich zunächst das "Original" Test Driven Development: By Example* von Kent Beck, der TDD erfunden hat. Es ist voll mit Beispielen, gut verständlich und auch nicht allzu lang. Das Buch ist zwar schon ein paar Tage älter, aber immer noch meine Empfehlung zum Einstieg.

*

Etwas moderner geht es zu in Professional Test Driven Development with C#*. In den Links habe ich auch meine Rezension des Buches verlinkt. Dort erfährst du noch mehr darüber, warum ich das Buch empfehlen kann.

*

Zuletzt noch ein modernes Buch zum Thema testen und TDD: Pragmatic Unit Testing in Java 8 with JUnit*. Darüber habe ich schon eine ganze Podcast-Episode aufgenommen und auch eine Rezension geschrieben (siehe Links).

*

Falls du schon fortgeschritten bist, kann ich wärmstens Growing Object-Oriented Software, Guided by Tests* empfehlen. Das Buch hat mein Verständnis von TDD noch einmal grundlegend erweitert und mich nachhaltig geprägt. Ein tolles Buch, das auch den erweiterten TDD-Zyklus beschreibt und über einfache Unit-Tests weit hinaus geht.

*

Und falls du mal lesen willst, wie ich ein Testframework testgetrieben entwickelt habe, kannst du dir hier den entsprechenden Teil meiner Masterarbeit herunterladen: NUNIT: A Unit-Test-Framework for Natural.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Regressionstest – Wikipedia

Rezension: Professional Test Driven Development with C# von James Bender und Jeff McWherter

Rezension: Pragmatic Unit Testing in Java 8 with JUnit von Jeff Langr

Pragmatic Unit Testing in Java 8 with JUnit (Buchclub)

Rezension: Growing Object-Oriented Software, Guided by Tests (Freeman/Pryce)

Zusammenfassung

TDD aus meiner Praxis

In meiner Masterarbeit habe ich untersucht, wie testgetriebenes Entwickeln die Qualität von Software beeinflusst. Dafür habe ich bestehenden Code überarbeitet und anhand von Codemetriken geprüft, wie er sich verändert. Dabei ließ sich eine bessere Codequalität feststellen. Außerdem habe ich NATUnit für die Programmiersprache NATURAL entwickelt, wobei ich mich an JUnit und NUnit orientiert habe. Das Framework ist seit Jahren in meinem Betrieb im Einsatz.

Tests vor dem Produktivcode schreiben

Bei Test-Driven Development, kurz TDD, schreibst du zuerst einen automatisierten Test für das gewünschte Verhalten. Anschließend entsteht der Produktivcode, der diesen Test erfüllt. Die Tests treiben dabei auch den Entwurf deiner Software voran, weil du schon beim Schreiben über die Schnittstellen und das erwartete Verhalten nachdenken musst.

Der klassische TDD-Zyklus

Red: Du schreibst einen Test und führst ihn aus. Er muss zunächst fehlschlagen, weil das gewünschte Verhalten noch fehlt.

Green: Du schreibst so wenig Produktivcode wie nötig, damit der neue Test erfolgreich durchläuft. Bereits vorhandene Tests müssen weiterhin erfolgreich sein.

Refactor: Du überarbeitest den Code, während die Tests das bisherige Verhalten absichern. Beispielsweise entfernst du doppelte Inhalte oder extrahierst eine Methode.

Bei einer Sprache mit Compiler kann davor ein weiterer Zustand auftreten: Der Test lässt sich noch gar nicht kompilieren, weil eine Klasse oder Methode fehlt. Diese sogenannte gelbe Phase endet, sobald du die nötigen Strukturen angelegt hast. Danach kannst du den Test ausführen und sein Fehlschlagen prüfen.

Warum ein Test zuerst fehlschlagen muss

Wenn du einen neuen Test einmal fehlschlagen siehst, kannst du prüfen, ob er auf das fehlende Verhalten reagiert. Eine Prüfung wie 1 == 1 bleibt bei jeder Änderung am Produktivcode erfolgreich und erzeugt dadurch falsche Sicherheit.

Auch der Grund für das Testergebnis muss nachvollziehbar sein. Erwartest du bei einer ungültigen Eingabe eine bestimmte Exception, gehört deren Typ zur Prüfung. Eine zufällig auftretende Datenbank-Exception würde eine andere Ursache anzeigen.

Durch automatisierte Tests erkennst du Regressionen: Bereits funktionierendes Verhalten fällt nach einer Änderung aus. Das kann auch eine andere Klasse betreffen, die vom geänderten Code abhängt. Ein Regressionstest prüft, ob das bisherige Verhalten weiterhin funktioniert, und deckt unerwünschte Abweichungen auf. Diese Begriffe können dir auch im Fachgespräch begegnen.

Kleine Schritte und YAGNI

Beim ersten Test einer Wurzelfunktion kannst du prüfen, ob die Wurzel aus 1 den Wert 1 ergibt. Für diesen Test reicht zunächst return 1. Weitere Testfälle verlangen nach zusätzlichem Verhalten. Beim anschließenden Refactoring entwickelst du den Code weiter und ersetzt wiederholte Fallunterscheidungen durch einen passenden Algorithmus.

Mit YAGNI, ausgeschrieben You Ain’t Gonna Need It, konzentrierst du dich auf das Verhalten, das deine aktuellen Anforderungen verlangen. Zusätzliche Funktionen und Abstraktionen für vermutete spätere Wünsche kosten Zeit und machen den Code komplexer.

Gerade beim Einstieg übst du diese Baby Steps, damit du auch bei schwierigen Problemen in einem komplexen System schrittweise vorgehen kannst. Mit Erfahrung kannst du größere Schritte wählen. Nach jeder Änderung gibt dir die Testsuite Rückmeldung über das geprüfte Verhalten, sodass du einen fehlerhaften Schritt zurücknehmen und einen anderen Weg ausprobieren kannst.

Mein erweiterter TDD-Zyklus

In meiner Praxis ergänze ich den klassischen Ablauf um zwei Schritte:

Red: Den neuen Test fehlschlagen lassen.

Optimize Failure Message: Prüfen, ob die Fehlermeldung beim Suchen nach der Ursache hilft, und sie bei Bedarf verbessern.

Green: Den Test mit möglichst wenig Produktivcode erfolgreich machen.

Refactor: Den Produktivcode überarbeiten.

Refactor Tests: Auch den Testcode überarbeiten.

Bei einer Meldung wie "Value is False" fehlt dir der fachliche Zusammenhang. Eine Meldung wie "Der Kontostand darf niemals negativ sein" beschreibt,...

Ein spannendes Interview mit Stefan Lieser von der Initiative "Clean Code Developer" gibt es in der einhundertzweiten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit Stefan Lieser bespreche ich, wie du als IT-Azubi Clean Code im Alltag umsetzt: durch kleine Übungsaufgaben, regelmäßiges Lernen und gemeinsame Arbeit im Team. Die Clean Code Developer Initiative ordnet ihre Prinzipien und Praktiken in farbige Grade ein, mit denen du dich jeweils etwa drei Wochen beschäftigst. Zu ihren vier Werten gehören Korrektheit, Wandelbarkeit, Produktionseffizienz und kontinuierliches Verbessern. Außerdem erfährst du, wie Flow Design beim Entwerfen hilft und weshalb automatisierte Tests sowie klar getrennte Aufgaben innerhalb von Methoden die Software verständlicher und leichter veränderbar machen.

Kapitelmarken

[00:00:00] Einführung in das Interview

[00:01:14] Stefan Lieser stellt sich vor

[00:02:40] Clean-Code-Prinzipien sammeln und mit Katas üben

[00:04:34] Clean Code in Betrieben, Berufsschulen und IHK-Prüfungen

[00:07:03] Liesers Weg zu C# und seine Erfahrungen mit anderen Sprachen

[00:10:03] Trainings und Ausbildung bei der CCD School

[00:11:23] Workshopformate und langfristige Begleitung

[00:14:27] Gemeinsam als Team lernen

[00:16:25] Qualität im eigenen Betrieb anstoßen

[00:19:22] Kontinuierlich lernen und Arbeitszeit dafür einplanen

[00:21:19] Clean Code in älteren Entwicklungsumgebungen

[00:22:48] Automatisierte Tests und die vier CCD-Werte

[00:23:50] Microservices und asynchrones Programmieren vorbereiten

[00:26:48] Wie die Clean Code Developer Initiative entstand

[00:28:36] Farbige Grade und der Kreislauf beim Lernen

[00:30:16] Reihenfolge der Bausteine und Einstieg im roten Grad

[00:32:34] Prinzipien, Praktiken und ihre vier Werte

[00:34:32] Von einzelnen Prinzipien zu Flow Design

[00:37:05] Software mit Aktionen und Datenflüssen entwerfen

[00:39:21] Symbole und Code aus dem Flow-Design-Entwurf

[00:40:38] UML, TDD und gemeinsames Entwerfen im Team

[00:44:32] Code und Entwurf in Einklang halten

[00:47:09] IOSP und das Abwägen von Prinzipien

[00:49:58] Flow Design und Domain-Driven Design

[00:52:01] Armbänder und weitere Hilfen für den Alltag

[00:55:44] Websites und Übungsaufgaben für den Einstieg

[00:58:49] Bücher, Testkurse und fachlicher Austausch

[00:61:24] Fachvorträge und Projektpräsentationen üben

[01:02:32] Kontakt und Refactoring von Legacy-Code

[01:03:26] Zeit für fachliches Lernen einplanen

[01:04:31] Shownotes und Ausblick

Inhalt

Hier sind einige der Fragen, die wir im Laufe des Gesprächs durchgegangen sind:

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

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

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

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

Was ist deine Lieblingsprogrammiersprache und warum?

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

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

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

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

Wer braucht Microservices?

Wie sollte man beim Entwurf einer Software vorgehen? Welche Modellierungswerkzeuge sollte man einsetzen?

Was ist Flow Design?

Was ist die Initiative "Clean Code Developer"?

Was ist der Sinn des CCD-Armbandes?

Welches Prinzip findest du am wichtigsten bzw. welches bietet den größten Mehrwert?

Welche Praktik findest du am wichtigsten bzw. welche bietet den größten Mehrwert?

Werden die Ideen hinter CCD deiner Erfahrung nach schon großflächig in den Unternehmen eingesetzt oder ist hier noch viel Aufklärungs-/Überzeugungsarbeit zu leisten?

Sollten bereits Auszubildende/Studenten mit CCD anfangen oder ist das eher etwas für "fertige" Entwickler/-innen?

Wie können auch Azubis/Studenten schon CCD in ihren Alltag integrieren bzw. womit sollten sie beginnen?

Was können (gerade junge) Entwickler/-innen tun, wenn ihr Unternehmen die Ideen hinter CCD nicht unterstützt?

Muss CCD in Unternehmen immer "von oben" mitgetragen werden oder können Entwickler auch selbst damit anfangen?

Wo kann man mehr über CCD erfahren? Gibt es z.B. Kurse, Bücher, Konferenzen usw.?

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

Literaturempfehlungen

Auf Clean Code* basiert eigentlich das gesamte Gespräch mit Stefan. Daher darf es natürlich nicht auf der Buchliste fehlen!

*

Außerdem hat Stefan noch Refactoring* empfohlen, um "alten" Code Schritt für Schritt besser zu machen.

*

Um dabei gleich in Richtung etablierter Patterns zu arbeiten, ist noch Refactoring to Patterns* zu empfehlen.

*

Und ein weiterer Klassiker, den ich persönlich auch jedem Entwickler empfehlen kann, wurde auch genannt: Working Effectively with Legacy Code*.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Die Initiative "Clean Code Developer"

Trainings & Beratung rund um Clean Code Development sowie Übungsaufgaben

Refactoring von Legacy Code

Kostenloser Online Kurs zum Thema Unit Tests mit NUnit, über 2h Videos

Cheatsheet zu Flow Design

Zusammenfassung

Stefan Lieser und Clean Code in der Ausbildung

Mit Stefan Lieser bespreche ich, wie du als IT-Azubi zum/zur Fachinformatiker:in Anwendungsentwicklung sauberen Code schreiben und deine Arbeitsweise weiterentwickeln kannst. Er arbeitet freiberuflich, schreibt unter anderem für die .NET Pro und bietet gemeinsam mit Ralf Westphal Trainings über die CCD School an. Beide haben die Clean Code Developer Initiative gegründet.

Aus meinen IHK-Prüfungen kenne ich Projektarbeiten, bei denen automatisierte Tests und Continuous Integration kaum vorkommen. Auch Lieser erlebt in seinen Trainings, dass Betriebe und Berufsschulen solche Arbeitsweisen unterschiedlich vermitteln. Kleine Aufgaben geben dir Gelegenheit, einzelne Prinzipien auszuprobieren, bevor du sie in einem echten Projekt anwendest. Seine regelmäßig veröffentlichten Katas in der .NET Pro folgen diesem Ansatz.

C# und andere Sprachen

Lieser hat unter anderem mit C und C++ gearbeitet, sich mehrere Jahre mit Netzwerken beschäftigt und später über VB6 zu C# gefunden. C# ist seine Lieblingssprache, die er besonders gründlich kennt. Er schätzt die zusammenhängend gestaltete Sprache und ihr zügiges Weiterentwickeln unter Microsoft und Anders Hejlsberg. In seinen Workshops begegnen ihm außerdem häufig Java und C++.

Clean-Code-Praktiken lassen sich auch in älteren Umgebungen anwenden. In meinem Betrieb habe ich beispielsweise bei der Arbeit mit Natural eine Versionsverwaltung mit eingeführt. Auch der Weg vom Code bis zur produktiven Software lässt sich dort durch Continuous Integration verbessern. Für ABAP berichtet Lieser aus einem Training seines Kollegen, dass Unit-Tests zur verfügbaren Umgebung gehören.

Die Clean Code Developer Initiative

Ende 2008 lasen Stefan Lieser und Ralf Westphal unabhängig voneinander Clean Code von Robert C. Martin. Daraus entstand die Idee, bewährte Prinzipien aus verschiedenen Quellen online zusammenzutragen. Die Sammlung wuchs im Austausch mit der Community auf mehr als 40 Bausteine.

Dabei bezeichnet Baustein sowohl ein Prinzip als auch eine Praktik:

Prinzip: Im fertigen Code lässt sich prüfen, ob es eingehalten wurde. Eine Verletzung von DRY, also "Don’t Repeat Yourself", wird beispielsweise durch kopierten Code sichtbar.

Praktik: Sie beschreibt, wie du arbeitest. Ob du beim Test-First-Vorgehen zuerst den Test geschrieben hast, lässt sich dem fertigen Code allein kaum eindeutig entnehmen.

Vier Werte als Grundlage

Die Bausteine richten sich an vier Werten aus:

Korrektheit: Deine Software erfüllt die Anforderungen der Kund:innen korrekt.

Wandelbarkeit: Du kannst den Code auch nach vielen Jahren verändern und um Funktionen ergänzen.

Produktionseffizienz: Der Aufwand bleibt gering, indem etwa Tests und Builds automatisiert ablaufen. Auch Integration und Deployment gehören dazu.

Kontinuierliches Verbessern: Du lernst regelmäßig dazu. Dieser Anspruch gilt ebenso für dein Team und den Betrieb wie für die gesamte Branche.

Automatisierte Tests verbinden Korrektheit mit effizientem Arbeiten. Sie bilden außerdem eine Grundlage für eine Pipeline, die Software bis in die produktive Umgebung bringt.

Mit den farbigen Graden arbeiten

Die Sammlung ist auf fünf farbige Grade verteilt: Rot, Orange, Gelb, Grün und Blau. Jeder enthält ungefähr acht Prinzipien und Praktiken. Du beschäftigst dich etwa drei Wochen mit einem Grad und achtest beim Programmieren gezielt auf dessen Bausteine. Anschließend folgt der nächste Abschnitt.

Nach einem Durchlauf kannst du im weißen Grad etwa drei Wochen lang alle Bausteine gemeinsam berücksichtigen. Danach beginnt der Kreislauf erneut; vorgesehen sind mehrere Runden. Die Farben orientieren sich am Regenbogen und kennzeichnen den aktuellen Schwerpunkt beim Lernen.

Im roten Grad stehen überwiegend Bausteine, die du selbst anwenden kannst, etwa DRY. Versionskontrolle gehört ebenfalls an den Anfang. Später folgen anspruchsvollere Aufgaben oder solche, für die sich das Team abstimmen muss.

Toolgestützte, einfache Refactorings kommen früh vor. Integrationstests stehen vor Unit-Tests, weil du sie auch bei stark miteinander verbundenem Code schreiben kannst. Für Unit-Tests musst du dich intensiver damit beschäftigen, Abhängigkeiten aufzulösen. Gemeinsames Entwerfen erscheint im blauen Grad, da das Team dafür eine gemeinsame Sprache lernen und üben muss.

Lernen und Üben im Betrieb

Die CCD School hat unterschiedlich lange Workshopformate ausprobiert. Daraus entwickelte sich ein Ansatz mit einzelnen Trainingstagen und längerfristiger Begleitung: etwa sechs bis zehn Termine über ein Jahr verteilt, häufig mit drei bis vier Wochen Abstand.

Während eines Trainingstags bearbeitet das Team Aufgaben, zu denen es Entwürfe erstellt und Code schreibt. Im anschließenden Review werden die Lösungen anhand der Prinzipien

Den letzten Teil des Buchclubs zum Handbuch für Fachinformatiker mit den Kapiteln Mobile Development und Software-Engineering gibt es in der einhundertersten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit Software Engineering und einem Überblick über Mobile Development schließe ich den Buchclub zum IT-Handbuch für Fachinformatiker:innen von Sascha Kersken ab. Für dein Abschlussprojekt gehören ein geplanter Entwicklungsprozess und eine durchdachte Architektur ebenso dazu wie automatisierte Tests und passende Dokumentation. Netzpläne, Lasten- und Pflichtenhefte sowie UML-Diagramme begegnen dir auch in Prüfungen. Für Themen wie Scrum und Entwurfsmuster empfehle ich dir ergänzende Fachbücher, da das Handbuch hier jeweils einen kurzen Einstieg bietet.

Kapitelmarken

[00:00:01] Abschluss des Buchclubs zum IT-Handbuch

[00:01:38] Mobile Development: Überblick und Grenzen des Kapitels

[00:04:54] iOS mit Swift und Xcode, Android mit Android Studio

[00:06:26] Mobile Anwendungen in Unternehmen und Abschlussprojekten

[00:07:25] Software Engineering und seine Geschichte

[00:08:59] Entwicklungsphasen und Wasserfallmodell

[00:09:48] Projektplanung mit Netzplänen und Gantt-Diagrammen

[00:11:44] Analyse: Lastenheft und Pflichtenheft

[00:13:22] Entwurf: Architektur im Abschlussprojekt planen

[00:16:27] Code entwickeln: Versionsverwaltung und Unit-Tests

[00:18:10] Dokumentation für Entwickler:innen und Anwender:innen

[00:19:16] Entwicklungsverfahren und Extreme Programming

[00:20:33] Scrum in der Prüfungsvorbereitung

[00:21:19] UML: fünf prüfungsrelevante Diagrammtypen

[00:23:04] UML-Diagramme den Projektphasen zuordnen

[00:25:22] Entwurfsmuster und ihre Bedeutung im Fachgespräch

[00:27:17] Beispiele für Entwurfsmuster und gemeinsame Fachsprache

[00:29:47] Unit-Tests und testgetriebene Entwicklung

[00:31:10] Versionskontrolle und Bug-Tracker

[00:32:04] Software Engineering vertiefen

[00:32:35] Rückblick auf den Buchclub und Empfehlung zur aktuellen Auflage

[00:34:31] Buchvorschläge für weitere Buchclubs

[00:35:07] Literatur zu UML und agiler Softwareentwicklung

[00:36:31] Bücher zu Extreme Programming und Entwurfsmustern

[00:38:03] Weiterführende Links und Podcast-Episoden

[00:38:33] Newsletter, Bewertungen und Feedback

Inhalt

Kapitel 12 ist voll mit prüfungsrelevanten Inhalten, die jeder Anwendungsentwickler beherrschen sollte. Der Ausflug in die Entwicklung mobiler Anwendungen ist zwar spannend, aber weniger prüfungsrelevant.

Kapitel 11: Mobile Development

Die Kurzeinführung in iOS und Android ist ganz nett, wenn man die Betriebssysteme noch nicht kennt.

Die Einführung in Swift ist interessant, aber aufgund des geringen Umfangs nicht ausreichend für die Praxis.

Die "Schritt-für-Schritt-Anleitungen" zum Erstellen zweier Apps sind sehr spezifisch und nicht prüfungsrelevant. Da sie wahrscheinlich schnell veralten, sind sie für die Praxis auch nicht allzu hilfreich. Dennoch vermitteln sie einen ersten Überblick über die Werkzeuge und das Vorgehen bei der Entwicklung einer App.

Kapitel 12: Software-Engineering

Die kurze geschichtliche Einführung anhand der Softwarekrise ist sinnvoll.

12.1 Überblick

Der Entwicklungszyklus aus Planung, Analyse, Entwurf, Implementierung, Test und Dokumentation wird exakt so in (fast) jedem IHK-Abschlussprojekt durchlaufen, hat also eine sehr hohe Praxisrelevanz.

Projektmanagement ist ein wichtiges Prüfungsthema. Netzpläne werden in gefühlt jeder zweiten Prüfung abgefragt. Auch das Gantt-Diagramm sollte jeder Prüfling beherrschen.

Ein weiteres wichtiges Prüfungsthema sind Lastenheft und Pflichtenheft.

Beim Entwurf wird auf die Architektur der Anwendung geachtet. Eine Information, die viele Prüflinge in ihren Projektarbeiten vergessen.

Bei der Implementierung werden mehrere - eigentlich als selbstverständlich geltende - Verfahren wie Versionsverwaltung oder Unit-Tests beschrieben, die in vielen Projektarbeiten auch keine Erwähnung finden.

Im Bereich Dokumentation werden dann genau die Artefakte besprochen, die ich in jeder Projektarbeit erwarte: Entwicklerdokumentation und Kundendokumentation.

Die konkreten Entwicklungsprozesse sollte auch jeder Prüfling kennen, wobei der RUP bislang nie abgefragt wurde (wohl weil er kommerziell ist). Extreme Programming und Scrum sollten jedem Prüfling geläufig sein.

12.2 Werkzeuge

UML: Das Lieblingsthema jedes Prüfungserstellers :-) Absolut prüfungsrelevant sind: Anwendungsfalldiagramm, Klassendiagramm, Sequenzdiagramm, Aktivitätsdiagramm und Zustandsdiagramm. Letzeres wird leider nicht näher vorgestellt. Sekundärliteratur ist für die UML dringend zu empfehlen!

Entwurfsmuster sollten einem Anwendungsentwickler nach drei Jahren Ausbildung auch einmal untergekommen sein. Allerdings wurden sie bislang nicht in Prüfungen abgefragt. Da sie aber eine hohe Praxisrelevanz haben, können sie definitiv im Fachgespräch zur Sprache kommen. Ich empfehle eine nähere Auseinandersetzung mit: Abstract Factory, Factory Method, Builder, Singleton, Adapter, Decorator, Observer, Strategy, Template Method, Visitor.

In Java würde ich statt des gezeigten Codes für einen Singleton die implizit synchronisierte Variante verwenden.

Unit-Tests sollten heutzutage Standard bei der Softwareentwicklung - und in jedem Abschlussprojekt - sein. Auch TDD muss jeder Prüfling erklären können.

Ohne eine Versionsverwaltung wie Git würde ich nicht eine Zeile Code schreiben.

Und Bugtracker sind hoffentlich in den Ausbildungsbetrieben auch weit verbreitet.

Literaturempfehlungen

Software-Engineering ist ein weites Feld. Zu den genannten Schwerpunkten in der Prüfung kann ich die folgenden Bücher empfehlen.

Darum geht es ja hier :-)

*

Eine detaillierte und gut verständliche Übersicht über alle UML-Diagramme.

*

Enthält auf wenigen Seiten (ca. 200) Extreme Programming, Scrum und Feature Driven Development.

*

Der Klassiker vom "Erfinder" Kent Beck persönlich.

*

Sehr gut verständlich und spannend geschrieben. Es werden aber nicht alle Pattern besprochen.

*

Eine kurze Zusammenfassung aller wichtiger Patterns. Zum Nachschlagen gut geeignet. Wenn man sie noch gar nicht kennt, aber zu kurz.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Lasten- und Pflichtenheft in der Projektdokumentation

Pragmatic Unit Testing in Java 8 with JUnit (Buchclub)

Einführung in die Versionsverwaltung mit Git (Teil 1)

Testverfahren für Software - Häufige Fragen im Fachgespräch

Design Patterns & Refactoring

Zusammenfassung

Mobile Development

Mit den Kapiteln Mobile Development und Software Engineering beende ich die 14-teilige Buchclub-Reihe zum IT-Handbuch für Fachinformatiker:innen von Sascha Kersken. Das Kapitel zu mobilen Anwendungen führt kurz in iOS und Android ein. Für iOS behandelt es Swift und die Entwicklungsumgebung Xcode; für Android zeigt es den Einstieg mit Android Studio und Java. Auf rund 30 Seiten entstehen einfache Beispiel-Apps.

Die Klickanleitungen hängen von der jeweiligen Softwareversion ab und altern entsprechend schnell. Ich empfehle dir für solche Schritte aktuelle Webseiten und für den tieferen Einstieg ein Fachbuch zur jeweiligen Plattform.

In den schriftlichen Prüfungen, auf die ich mich hier beziehe, stehen allgemeine Programmierkonzepte wie Schleifen und Algorithmen im Vordergrund. Wenn du dein Abschlussprojekt mit Swift umsetzt, gehören Fragen dazu ins Fachgespräch. Mobile Anwendungen begegnen mir regelmäßig in IHK-Projekten. In meinem Unternehmen gibt es beispielsweise eine App, mit der Versicherte Arztrechnungen fotografieren und einreichen können.

Software Engineering und der Entwicklungsprozess

Die Softwarekrise der 1960er-Jahre war ein Ausgangspunkt für Software Engineering. Seitdem haben sich Methoden entwickelt, mit denen du Software systematisch planen und erstellen kannst.

In vielen Abschlussprojekten, die ich lese, kommt das Wasserfallmodell vor. Für ein kurzes Projekt lässt sich damit der Ablauf gut beschreiben. Die behandelten Phasen sind:

Planung

Analyse

Entwurf

Implementierung

Test

Dokumentation

Aus jeder Phase sollte etwas in deiner Projektarbeit erkennbar sein. Die genaue Benennung und Reihenfolge können variieren.

Mit Netzplänen und Gantt-Diagrammen planen

Mit einem Netzplan kannst du Abhängigkeiten zwischen Aufgaben darstellen und berechnen, wie lange dein Projekt dauert. Er zeigt außerdem, welche Arbeiten parallel möglich sind. Die Aufgaben erscheinen als verbundene Rechtecke mit Angaben wie dem frühesten Anfangszeitpunkt oder dem spätesten Endzeitpunkt.

Auf dem kritischen Pfad liegen Aufgaben, deren Verzögerung das gesamte Projekt verschiebt. In meinen damaligen schriftlichen Prüfungen kamen Netzpläne häufig vor, etwa als Aufgabe zum Vervollständigen oder zum Berechnen des kritischen Pfads. Ich empfehle dir, das Thema mit weiteren Quellen und Übungsaufgaben zu vertiefen. Gantt-Diagramme werden ebenfalls als Werkzeug zum Planen vorgestellt.

Anforderungen im Lasten- und Pflichtenheft festhalten

Im Lastenheft beschreibt dein:e Auftraggeber:in die fachlichen Anforderungen an die gewünschte Software.

Als Auftragnehmer:in erstellst du darauf aufbauend das Pflichtenheft, in dem du beschreibst, wie du diese Anforderungen technisch umsetzen möchtest. Es gehört zum Vertrag und dient später als Grundlage dafür, zu prüfen, ob die vereinbarten Leistungen erfüllt sind.

Beide Dokumente sind Themen für schriftliche Prüfungen und Fachgespräche. Du kannst sie auch für dein eigenes Abschlussprojekt erstellen.

Die Architektur vorab entwerfen

Für dein Abschlussprojekt empfehle ich dir, die Architektur vor dem Programmieren aufzuzeichnen, beispielsweise mit einem UML-Komponentendiagramm. Dabei legst du fest, welche Komponenten deine Software hat und wie sie über Schnittstellen zusammenarbeiten. Auch Abhängigkeiten und ein möglicher Aufbau nach MVC gehören auf diese Ebene. Das Buch behandelt unter anderem Client-Server- und Peer-to-Peer-Architekturen.

Aus diesem Entwurf kannst du deine Projektstruktur ableiten....