IT-Berufe-Podcast Archiv

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....

Eine ganze Reihe an Hörerfragen beantworte ich in der Jubiläumsepisode 100 des Anwendungsentwickler-Podcasts. TL;DR Zur 100. Episode beantworte ich häufige Fragen aus der IT-Ausbildung, damit du deinen Berufsweg und dein Abschlussprojekt selbstständig angehen kannst. Eine Programmiersprache lernst du durch ein eigenes Praxisprojekt; für die Prüfung gehören alte Aufgaben und fachübergreifende IT-Grundlagen zum Lernstoff. Dein Abschlussprojekt soll einen echten betrieblichen Bedarf erfüllen und zeigen, wie du methodisch Software entwickelst, wobei du Vorlagen und Artefakte passend zu deinem Projekt auswählst. Dazu kommen Einblicke in meine Podcast-Technik und die fünf meistgehörten Folgen. Kapitelmarken [00:00:20] 100. Episode und Fragen von IT-Azubis [00:02:25] Herkunft der Intro- und Outro-Musik [00:04:17] Audio bearbeiten mit Audacity [00:04:58] Hosting bei Amazon S3 und Website mit WordPress [00:07:45] Hosting-Kosten und Affiliate-Links [00:09:42] Mikrofon, Ständer und Popfilter [00:11:48] Downloads und die fünf meistgehörten Folgen [00:18:06] Mein Weg in die Anwendungsentwicklung [00:23:12] Ausbildung und Studium: Den passenden Weg wählen [00:27:38] Umschulung und betriebliche Ausbildung [00:30:01] Später in die IT einsteigen und berufliche Chancen [00:34:02] Bewerben nach einer schwachen Ausbildung [00:37:05] Eine neue Programmiersprache lernen [00:39:11] Alte Prüfungen legal besorgen [00:41:21] Einheitliche Prüfungen und Baden-Württemberg [00:42:22] Früh lernen und bei Ausbildungsproblemen aktiv werden [00:45:57] Subnetting und fachübergreifende IT-Grundlagen [00:48:57] Hilfe beim Korrekturlesen der Projektdokumentation [00:51:51] Fachliche Tiefe des Abschlussprojekts [00:55:53] Frameworks und Bibliotheken einsetzen [00:58:39] Make-or-Buy-Analyse und passende Vorlageninhalte [01:02:17] Lastenheft, Pflichtenheft und Auszüge im Anhang [01:06:55] Kosten, Amortisation und Nutzwertanalyse [01:09:47] Technische und organisatorische Projektschnittstellen [01:11:51] Ist-Analyse bei einer neuen Lösung [01:13:50] Diagramme und Artefakte für dein Projekt auswählen [01:17:04] Code in der Dokumentation lesbar darstellen [01:19:20] Weitere Fragen und Materialien zur Ausbildung [01:22:03] Der vollständige Song zur Jubiläumsfolge Inhalt Infos zum Podcast Die Intro-/Outro-Musik habe ich selbst komponiert und aufgenommen (siehe Kathrin's Song). Der Podcast wird mit dem Open-Source-Tool Audacity aufgenommen und gemischt. Das Hosting läuft über Amazon S3*. In die WordPress-Website eingebunden wird der Podcast über Blubrry PowerPress. Als Mikro verwende ich das Samson Meteor*. * Fragen meiner Hörer/Leser Wie bin ich Anwendungsentwickler geworden? Durch meine ersten Versuche im Bereich Webentwicklung für meine damalige Band. Ausbildung Soll ich lieber studieren oder eine Ausbildung machen? Das kann man nicht pauschal beantworten. Soll ich lieber eine Umschulung machen oder eine normale Ausbildung? Meiner Erfahrung nach ist eine Ausbildung zu empfehlen! Kann ich auch mit X Jahren noch in der IT Fuß fassen? Bestimmt! Wir brauchen gute Fachkräfte. Und mit >30 ist man definitiv noch nicht zu alt. Soll ich mich trotz schlechter Ausbildung auf eine Stelle bewerben? Aber sicher! Sonst wirst du nie erfahren, ob es geklappt hätte. Und hier gleich ein paar Tipps: Bewerbung nach der Ausbildung Wie lerne ich am besten Programmiersprache X? Durch die Umsetzung eines echten Projekts und Feedback von anderen Entwicklern. Und ich empfehle parallel immer Bücher*. Prüfungsvorbereitung Kannst du mir die Prüfung X zuschicken? Nein. Die kannst du bzw. dein Ausbildungsbetrieb legal erwerben*. Sind die Prüfungen bundesweit einheitlich? In allen Bundsländern bis auf Baden-Württemberg. Bei mir im Betrieb ist alles ganz anders - wie soll ich für die Prüfung lernen? Meine allgemeinen Tipps für die Prüfungsvorbereitung gelten immer: Vorbereitung auf die schriftliche Abschlussprüfung. Muss ich Subnetting können? Ja. Projektdokumentation Kannst du bitte meine Projektdokumentation korrekturlesen? Ja, aber nicht kostenlos. Reicht X als Abschlussprojekt? Ist mein Projekt ohne Datenbank und grafische Oberfläche ausreichend? Dazu habe ich schon einmal etwas geschrieben: Was ist eine ausreichende fachliche Tiefe des Abschlussprojekts? Ich will bei meinem Projekt "bei Null" anfangen. Ist das ok? Das ist nicht sinnvoll. So würde man in der Praxis nicht arbeiten. Es gibt Frameworks und Bibliotheken, die dem Entwickler viel Arbeit abnehmen. Mein Produkt kann man nicht fertig kaufen. Brauche ich eine Make-or-buy-Analyse? Nicht jedes Projekt benötigt eine Make-or-buy-Analyse, nur weil das in meiner Vorlage steht. Aber oftmals werden Tools entwickelt, die es bereits fertig am Markt gibt. Und dann erwarte ich eine gute Begründung, warum der Aufwand einer Eigenentwicklung betrieben wird. Muss ich ein Lasten-/Pflichtenheft zusätzlich zur Projektdokumentation erstellen? Das kommt auf deinen Entwicklungsprozess an. Grundsätzlich aber ja. Lasten-/Pflichtenheft sind separate Artefakte, die du für dein Projekt zusätzlich zur Dokuentation erstellen musst. Mein Projekt amortisiert sich nicht. Kann ich die Berechnung weglassen? Das halte ich für ein Gerücht. Jedes Projekt wird aus irgendeinem Grund erstellt. Und zur Not kann man noch eine Nutzwertanalyse anfertigen. Was ist mit "Schnittstellen" in der Projektdokumentation gemeint? Siehe PDF meiner Vorlage für die Projektdokumentation. Mit welchen anderen Systemen interagiert die Anwendung (technische Schnittstellen)? Wer genehmigt das Projekt bzw. stellt Mittel zur Verfügung? Wer sind die Benutzer der Anwendung? Wem muss das Ergebnis präsentiert werden? Was mache ich in der Ist-Analyse, wenn es bislang noch keine Lösung gibt? Genau das analysieren, was vorhanden ist. Wenn es nichts gibt, kannst du genau die fehlenden Punkte aufführen und die Schwachstellen aufzeigen. Welche Diagramme soll ich für mein Projekt erstellen? Alle, die nötig sind. Wie stelle ich am besten Code in der Projektdokumentation dar? Mit einer Nicht-Proportionalschrift wie Courier New. Wenn es geht, am besten mit Syntax-Highlighting. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts BIBB / Die Top-10-Ausbildungsberufe 2016 Die 17 häufigsten Fehler in der Projektdokumentation - Anwendungsentwickler-Podcast #9 Gliederung der Projektdokumentation (Teil 1) - Anwendungsentwickler-Podcast #27 Layout der Projektdokumentation - Anwendungsentwickler-Podcast #31 Zusammenfassung Mein Podcast zur 100. Episode Für die Jubiläumsfolge habe ich häufige Fragen von IT-Azubis gesammelt. Die Angaben zu Prüfungen und zum Arbeitsmarkt beziehen sich auf die damalige Situation 2016/2017. Musik und Technik Die Musik für Intro und Outro stammt aus einem Punkrock-Song, den ich für meine Schwester zum 18. Geburtstag geschrieben habe. Bass und Gitarren habe ich selbst eingespielt, das Schlagzeug ist gesampelt. Den vollständigen Song findest du unter band.macke.it; zur Jubiläumsfolge hängt er auch am Ende der Episode. Audio: Mit dem kostenlosen Open-Source-Programm Audacity habe ich alle bisherigen Folgen aufgenommen, bearbeitet und als MP3 exportiert. Der Mehrspur-Editor enthält auch Effekte wie Kompressor und Limiter. Hosting: Die MP3-Dateien liegen bei Amazon S3. Ausschlaggebend waren schnelle Downloads und die Möglichkeit, Dateien sowie Zugriffsrechte selbst zu verwalten. Als die Folgen noch auf meinem eigenen Server lagen, wurden Website und Downloads bei vielen gleichzeitigen Zugriffen langsam. Website: WordPress mit dem Plugin Blubrry PowerPress erzeugt aus der hinterlegten MP3-Adresse den Player und den Podcast-Feed. Mikrofon: Mein Samson Meteor kostet etwa 60 Euro und wird per USB direkt an den PC angeschlossen. Ein Mikrofonständer verhindert, dass sich Vibrationen vom Tisch auf die Aufnahme übertragen. Ein Popfilter mildert Luftstöße beim Sprechen ab. Da ich den Podcast in meiner Freizeit produziere und durch die Downloads Kosten entstehen, setze ich auf meiner Website Affiliate-Links ein. Wenn du darüber beispielsweise ein empfohlenes Buch kaufst, bekomme ich eine kleine Provision, die zum Hosting beiträgt. Die fünf meistgehörten Folgen Bis zur Jubiläumsfolge kamen rund 128.000 Downloads zusammen, durchschnittlich etwa 1.200 pro Episode. Aus den Downloads lässt sich keine genaue Zahl einzelner Hörer:innen ableiten. Episode 2: Häufige Fragen im Fachgespräch zur Objektorientierung, mit fast 4.000 Downloads. Episode 14: Ablauf der mündlichen Abschlussprüfung, mit Präsentation und Fachgespräch. Episode 17: Häufige Fragen im Fachgespräch zu relationalen Datenbanken, mit knapp 3.000 Downloads. Episode 15: FAQ zu Präsentation und Fachgespräch, Teil 1, mit über 2.500 Aufrufen. Episode 12: Häufige Fragen im Fachgespräch zur Programmierung, Teil 1, etwa zu Algorithmen sowie Schleifen und Verzweigungen. Für das Fachgespräch empfehle ich dir, Objektorientierung und relationale Datenbanken vorzubereiten. Auch die Grundlagen der Programmierung solltest du verständlich erklären können, beispielsweise den Unterschied zwischen kopf- und fußgesteuerten Schleifen. Mein Weg in die Anwendungsentwicklung Während meiner Schulzeit wollte ich eine Website für meine Band bauen. Mit einem PHP-Buch begann ich, eine Bildergalerie und ein Kontaktformular zu entwickeln; daraus entstand ein eigenes kleines CMS. Die Freude daran, logische Probleme zu lösen und neue Funktionen zu schaffen, führte mich beruflich zur Anwendungsentwicklung. Ich absolvierte ein vierjähriges duales Studium der Wirtschaftsinformatik in Vechta, verbunden mit der Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung. Mein damaliger Ausbildungsbetrieb unterstützt mich seit dieser Zeit und ist bis heute mein Arbeitgeber. Später folgte ein Master, inzwischen bilde ich selbst IT-Azubis aus. Ausbildung und Berufsweg Welche Form passt zu dir? Bei der Wahl deines Bildungswegs spielen deine Interessen und

Nach langer Zeit setze ich meine Reihe der Lernzielkontrollen zur Programmierung mit einem wichtigen Thema fort. Arrays und Listen sind der Inhalt der neunundneunzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Mit meinen Fragen zu Arrays und Collections kannst du als IT-Azubi dein Wissen über Datenstrukturen prüfen. Arrays speichern mehrere Werte eines Datentyps bei fester Länge; beim Zugriff über nullbasierte Indizes reicht der gültige Bereich von 0 bis length - 1. Listen lassen sich nachträglich erweitern und bieten Methoden, mit denen du ihre Inhalte bearbeiten kannst. Für die Praxis greife ich meist zur Liste, während du für die Prüfung auch verstehen solltest, wie ArrayList und LinkedList intern arbeiten, wie Sets eindeutige Elemente sicherstellen und wie Maps Werte über Schlüssel zugänglich machen. Kapitelmarken [00:00:00] Lernzielkontrolle zu Arrays und Collections [00:01:50] Was ist ein Array? [00:04:10] Die Länge eines Arrays abfragen [00:04:55] Feste Arraygröße und Aufwand beim Kopieren [00:07:18] Indexzugriff und nullbasierte Indizes [00:10:12] Arrays mit einer For-Schleife durchlaufen [00:10:47] Arraytypen mit eckigen Klammern deklarieren [00:11:45] For-Each-Schleifen und ihre Einsatzbereiche [00:14:49] Mehrdimensionale Arrays [00:17:13] Assoziative Arrays und Schlüssel-Wert-Paare [00:19:30] Listen und ihre Methoden [00:23:02] ArrayList und LinkedList intern [00:26:02] List als gemeinsames Interface und Polymorphie [00:26:33] Knoten einer verketteten Liste [00:27:22] Generische Listen und Typsicherheit [00:28:58] Laufzeit und Einsatzbereiche der Listenvarianten [00:33:05] Arrays und Listen in der Praxis [00:34:08] Sets für eindeutige Elemente [00:35:08] Maps, Dictionaries und Hashes [00:36:58] Praxistipps und APIs kennenlernen [00:37:55] Bücher zu Arrays und Collections [00:39:27] Fragen für die 100. Episode [00:40:24] Shownotes und Newsletter Inhalt Was ist ein Array? Eine Liste mehrerer Werte des gleichen Datentyps. Wie findet man heraus, wie viele Elemente ein Array enthält? Arrays haben eine Eigenschaft "Länge", die in Java z.B. length heißt. Wie kann man die Länge eines Arrays verändern? Gar nicht. Arrays sind nicht redimensionierbar. Wie greift man auf die Elemente in einem Array zu? Viele Programmiersprachen bieten für den Zugriff auf die Elemente eines Arrays die Schreibweise mit eckigen Klammern an, z.B. myArray[2]. Der Index ist meistens 0-basiert. Wie iteriert man über die Elemente eines Arrays? Mit Schleifen wie der for-Schleife. Einige Programmiersprachen bieten auch eine foreach-Schleife (in Java "extended for") an, die ohne Indizes arbeitet und nur die Elemente durchläuft. Was ist eine foreach-Schleife? Sie durchläuft alle Elemente eines Arrays und weist sie nach und nach einer Iterationsvariablen zu. Dadurch muss sich der Entwickler nicht um die Indizes kümmern. Was ist ein mehrdimensionales Array? Ein Array kann nicht nur eine Dimension haben, sondern mehrere. Bis zur dritten kann man sich dieses Konstrukt noch vorstellen (2. Tabelle, 3. Würfel). Was ist ein assoziatives Array? Ein zweidimensionales Array, das anstatt numerischer Indizes beliebige Datentypen als Schlüssel zulässt. Was ist eine Liste? Eine Liste ist quasi ein intelligentes Array. Sie stellt Funktionen zur Manipulation bereit und ist redimensionierbar. Was unterscheidet eine verkettete Liste (LinkedList) von einer Array-Liste (ArrayList)? Die Art der Implementierung. Verkettete Listen sind schnell beim Einfügen und langsam beim Zugriff, Array-Listen sind langsam beim Einfügen und schnell beim Zugriff. Wann sollte man Arrays und wann Listen verwenden? Wenn es keinen guten Grund dagegen gibt, sollte man immer Listen verwenden, da sie deutlich einfacher zu verwenden sind und zahlreiche Funktionen bereitstellen. Was ist ein Set? Eine Liste mit eindeutigen Elementen. Was ist eine Map? Das gleiche wie ein assoziatives Array, aber als eigene Datenstruktur implementiert. Es handelt sich um Schlüssel/Wert-Paare auf die über die Schlüssel zugegriffen werden kann. Literaturempfehlungen Eine sehr ausführliche Einführung in Listen und andere Datenstrukturen aus der Collection-API bietet die gute alte Java-Insel*. *(direkt beim Rheinwerk-Verlag bestellen*) Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Arrays Listen Assoziative Speicher Zusammenfassung Arrays: Werte speichern und darauf zugreifen Wenn ich fünf Ganzzahlen zusammen speichern möchte, kann ich dafür ein Array mit fünf Elementen anlegen. Über eine Variable erreiche ich sämtliche Werte und kann sie mit einer Schleife durchlaufen. In statisch typisierten Sprachen wie Java haben die Elemente eines Arrays denselben Datentyp. Mit eckigen Klammern kennzeichnest du in vielen Programmiersprachen den Arraytyp. int[] steht beispielsweise für ein Integer-Array. Auch eigene Objekttypen können als Elementtyp dienen. Über die Länge erfährst du, wie viele Elemente das Array hat. In Java steht sie im Attribut length. Die Länge wird beim Anlegen festgelegt und bleibt anschließend unverändert. Für eine andere Größe legst du ein neues Array an und kopierst die vorhandenen Werte hinein. Währenddessen beanspruchen beide Arrays Speicher, wobei das Kopieren zusätzlich Zeit kostet. Bei bekannter, dauerhaft fester Größe ermöglicht ein Array einen schnellen direkten Zugriff und arbeitet speichereffizient. Mit meinArray[index] greifst du in vielen Sprachen auf ein einzelnes Element zu. Bei nullbasierten Indizes liegt das erste Element an Position 0. Hat das Array fünf Elemente, ist 4 der letzte gültige Index. Ob die Indizes bei null beginnen, hängt von der Programmiersprache ab. Arrays mit Schleifen durchlaufen In einer klassischen For-Schleife beginnst du bei einem nullbasierten Array mit dem Index 0 und zählst bis length - 1. Die Schleifenbedingung lautet entsprechend index < meinArray.length. Wenn du bis einschließlich length zählst, greifst du auf eine Position außerhalb des Arrays zu. Java meldet dafür eine ArrayIndexOutOfBoundsException. Bei einer For-Each-Schleife erhältst du jedes Element nacheinander in einer Schleifenvariable. Die Schleife übernimmt das Weitergehen und berücksichtigt die Grenzen des Arrays. In Java heißt diese Variante erweiterte For-Schleife. Wenn ich beispielsweise gelesene Benutzer:innen auf einer Website ausgeben möchte, reicht es, die Elemente einzeln zu verarbeiten. Dafür eignet sich For-Each. Für Aufgaben, bei denen du die Position eines Elements brauchst oder Elemente gezielt umordnest, führst du den Index mit einer passenden Schleife selbst mit. Mehrdimensionale Arrays Mit int[][] kannst du ein Array anlegen, dessen Elemente wiederum Arrays sind. Zwei Dimensionen lassen sich als Tabelle mit Zeilen und Spalten vorstellen. Bei drei Dimensionen hilft das Bild eines Würfels; weitere Dimensionen sind ebenfalls möglich. Wenn du in Java das äußere Array durchläufst, erhältst du jeweils ein inneres Array mit eigener Länge. Auf dessen Elemente kannst du anschließend über einen weiteren Index zugreifen. Assoziative Arrays Über einen Schlüssel wie "Name" kannst du einen zugeordneten Wert erreichen. Diese Form heißt assoziatives Array und begegnet dir beispielsweise in PHP. Schlüssel und Werte bilden zusammen ein Paar. Welche Datentypen dafür infrage kommen, hängt von der jeweiligen Sprache und Datenstruktur ab. Für Schlüssel und Wert können unterschiedliche Typen vorgesehen sein. Listen im Alltag Wenn du nach einem Nachnamen in einer Datenbank suchst, steht die Zahl der Treffer erst nach der Abfrage fest. In einer Liste kannst du die gefundenen Werte nachträglich hinzufügen und später wieder entfernen. Listen sind zunächst eindimensional, wobei ihre Elemente selbst wieder Listen sein können. Je nach Programmiersprache bietet dir die Liste Methoden, mit denen du beispielsweise: einen Wert an einer bestimmten Position einfügst oder abfragst, einzelne Elemente entfernst, die gesamte Liste leerst, nach einem enthaltenen Wert suchst, die Elemente sortierst. Für meine alltäglichen Programme greife ich meist zu Listen, weil ich damit wechselnde Mengen von Werten bearbeiten kann. Arrays kommen unter anderem infrage, wenn die Größe dauerhaft feststeht oder du hardwarenah mit Sprachen wie C oder C++ arbeitest. ArrayList Im Inneren einer ArrayList liegen die Werte in einem Array. Wenn dessen Kapazität ausgeschöpft ist, wird ein größeres Array angelegt und der Inhalt dorthin kopiert. Dabei kann die Kapazität um mehrere Plätze auf einmal wachsen, damit weitere Elemente zunächst Platz haben. Über einen Index erreicht die ArrayList ein Element in konstanter Zeit. Das Vergrößern des internen Arrays kostet Zeit und zusätzlichen Speicher; beim Einfügen innerhalb der Liste müssen vorhandene Elemente verschoben werden. Für häufige direkte Zugriffe auf bestimmte Positionen eignet sich diese Struktur. LinkedList Eine verkettete Liste arbeitet mit Knoten, die jeweils einen Wert und einen Verweis auf den nächsten Knoten enthalten. Ausgehend vom ersten Knoten lässt sich die Liste Schritt für Schritt durchlaufen. Beim letzten Knoten endet die Kette. Um einen neuen Knoten einzufügen, werden die betreffenden Verweise angepasst. Für den Zugriff auf eine bestimmte Position müssen die Knoten bis zur gesuchten Stelle durchlaufen werden. Die Struktur eignet sich daher für Aufgaben, bei denen du häufig Elemente hinzufügst und mit den Verknüpfungen arbeitest. Gemeinsames Interface und generische Typen In Java implementieren ArrayList und LinkedList das Interface List. Wenn ich meinen Code gegen dieses Interface schreibe, kann ich die konkrete Listenklasse austauschen, während die aufgerufenen Listenmethoden gleich bleiben. Das ist ein Beispiel für Polymorphie. Mit einem Typparameter legst du fest, welche Elemente eine generische Liste aufnehmen kann. List enthält Integer-Werte. Versuchst du, einen String einzufügen, weist der Compiler den falschen Typ zurück....

Das äußerst empfehlenswerte Buch "Pragmatic Unit Testing in Java 8 with JUnit" wird im Buchclub in der achtundneunzigsten Episode des Anwendungsentwickler-Podcasts besprochen. TL;DR Mit "Pragmatic Unit Testing in Java 8 with JUnit" arbeite ich bereits im ersten Ausbildungsjahr, sobald du erste Java-Kenntnisse hast. Das Buch führt dich Schritt für Schritt an automatisierte Tests heran und gibt dir Merkhilfen, mit denen du passende Testfälle findest. Du erfährst außerdem, wie Tests das Refactoring absichern und mit Mocking sowie testgetriebener Entwicklung zusammenhängen. Viele der beschriebenen Prinzipien lassen sich auf andere Programmiersprachen übertragen. Kapitelmarken [00:00:00] Einstieg in den Buchclub [00:01:22] Das Buch im ersten Ausbildungsjahr [00:03:20] Verständlichkeit und Erfahrungen mit IT-Azubis [00:06:07] Die vier Teile des Buchs [00:06:42] Warum automatisierte Tests zum Entwickeln gehören [00:07:53] JUnit in der Entwicklungsumgebung einrichten [00:08:48] Erste Testfälle und der JUnit-Testablauf [00:09:38] Englische Fachliteratur und Fachbegriffe [00:10:41] Assertions, Hamcrest und Exceptions [00:12:52] Tests strukturieren und als Dokumentation lesen [00:14:08] Merkhilfen und ihre Prüfungsrelevanz [00:15:00] FIRST: Eigenschaften guter Unit-Tests [00:17:01] Right BICEP: Geeignete Testfälle finden [00:19:08] CORRECT: Grenzfälle berücksichtigen [00:20:33] Refactoring mit vorhandenen Tests [00:22:01] SOLID und Single Responsibility [00:22:48] Mocks, Stubs und Mockito [00:25:37] Testcode refaktorisieren [00:27:04] Test-Driven Development und Softwareentwurf [00:28:06] Nebenläufigen Code und Datenbankzugriffe testen [00:29:24] Tests im Projektalltag, Continuous Integration und Code Coverage [00:30:44] Testprinzipien auf andere Programmiersprachen übertragen [00:31:57] Weiterführende Literaturempfehlungen [00:32:59] Fragen für Episode 100 [00:33:42] Newsletter und Checklisten für die Projektarbeit Inhalt Das Buch ist meine absolute Empfehlung für jeden Azubi. Meine eigenen Azubis lesen es schon direkt im 1. Ausbildungsjahr, kurz nachdem sie ihre ersten Java-Aufgaben gelöst haben. Für mich gehört Unit-Testing einfach mit zur Ausbildung dazu und man kann gar nicht früh genug damit anfangen. Bislang waren die Rückmeldungen zum Buch sehr positiv. Alle Azubis haben es gut verstanden und konnten die Inhalte auch direkt in die Praxis umsetzen. Wir haben uns für das Durcharbeiten meistens ca. 2 Wochen Zeit genommen. Das Buch ist sehr verständlich geschrieben, enthält tolle Beispiele - und zwar endlich einmal auch in Java 8 - und ist dank des geringen Umfangs von knapp 200 Seiten sehr schnell zu lesen. Die Bücher aus dem Hause Pragmatic Programmers kann man eigentlich ausnahmslos empfehlen. Sie haben u.a. auch das "Standardwerk" zum Einstieg in Ruby on Rails* oder POODR* veröffentlicht. Pragmatic Unit Testing in Java 8 with JUnit* reiht sich - meiner Meinung nach - hier perfekt ein. Grundlagen Das Buch führt auf knapp 50 Seiten zunächst in das Thema Unit-Tests ein und erklärt die Funktionsweise von JUnit. Schritt für Schritt wird ein lauffähiger Unit-Test erstellt und dabei werden auch die neuen Entwicklungen in JUnit berücksichtigt - also keine alten test*-Methoden mehr, sondern vernünftige Annotations. Dabei wird auch gleich das berühmte AAA zum Aufbau der Test-Methoden erläutert und @Before und @After eingeführt. Ich kann mir in Zukunft meine eigenen Erklärungen sparen und lasse meine Azubis diese ersten 50 Seiten lesen. Danach sollten sie alle wichtigen Begriffe und Ideen zum Thema Unit-Tests und Junit kennen :-) Das Buch startet mit einem schönen Überblick, warum man überhaupt testen sollte. Außerdem enthält es Schritt-für-Schritt-Anleitungen, um Unit-Test mit Eclipse zu erstellen. Im Anhang wird aber auch auf IntelliJ und Netbeans eingegangen, sodass man unabhängig von der konkreten IDE mitmachen kann. Die zu testenden Codebeispiele werden ebenfalls ausführlich erläutert. Es können also auch absolute Anfänger mitarbeiten. Als nächstes werden Assertions im Detail vorgestellt. Auch die Hamcrest-Matcher gehören dazu, um sprechende Tests zu schreiben, und die unterschiedlichen Möglichkeiten z.B. mittels Annotationen werden vorgestellt. Akronyme Der nächste Teil (ca. 40 Seiten) ist dann ganz den "Mnemonics" gewidmet. Das hilft in der Praxis, ist aber nicht prüfungsrelevant. FIRST: fast, isolated, repeatable, self-validating, timely. Right-BICEP: right, boundary conditions, inverse relationships, cross-checking, error conditions, performance. CORRECT: conformance, ordering, range, reference, existence, cardinality, time. Anhand dieser einprägsamen Akronyme geht Jeff Langr die Eigenschaften guter Unit-Tests durch und bringt den Lesern damit gleich bei, worauf sie bei der Programmierung ihrer Tests achten sollten, um keine falsche Sicherheit zu erreichen. Design Im dritten Teil (ca. 60 Seiten) widmet sich das Buch den "großen" Themen Refactoring und Mock-Objekte. Es wird intensiv geschildert, warum Refactoring wichtig ist und warum Unit-Tests unabdingbare Voraussetzung für das Refactoring des eigenen Codes sind. Außerdem wird erklärt, wofür man Mock-Objekte braucht und wann man sie besser nicht einsetzen sollte. Das Kapitel wird abgerundet mit einer stimmigen Liste von Test Smells, die auf ein nötiges Refactoring des Test-Codes hindeuten. Somit wird dem Leser gleich an die Hand gegeben, dass auch der Test-Code den gleichen Qualitätskriterien genügen sollte wie der Produktivcode. Sogar ein Kurzausflug in die SOLID-Prinzipien ist enthalten. Als nächstes werden Mock-Objekte vorgestellt und die Unterschiede zwischen Stubs und Mocks erläutert. Der Teil schließt mit einem Kapitel zum Refactoring des Test-Codes. Das ist ein Vorgang, der zu jedem testgetriebenen Entwicklungsprozess gehören sollte. Big Picture Der letzte Teil des Buchs (ca. 50 Seiten) geht dann konkret auf Test Driven Development ein und auch auf das Testen schwieriger Probleme wie zum Beispiel Multithreading und Datenbanken. Ganz zum Schluss werden dann auch noch weitere wichtige Begriffe erläutert wie z.B. Continuous Integration und Code Coverage. Es ist also auch etwas für fortgeschrittene Tester dabei. Fazit Ich konnte Pragmatic Unit Testing in Java 8 with JUnit* gut von vorn bis hinten durchlesen. Es ist durchgängig interessant geschrieben und enthält viele lehrreiche Tipps. Es ist daher meine Empfehlung für alle Azubis (oder auch Ausbilder ;-) ), die sich dem Thema Unit-Tests widmen möchten (oder müssen). Es gehört für mich ab sofort zur Standardbibliothek für meine Azubis. Tipp für Ausbilder Ich würde neuen Auszubildenden das Buch nach ca. drei Monaten Einarbeitung zur Lektüre empfehlen. Dann sollten sie bereits einige (negative) Erfahrungen mit der Programmierung gemacht haben und schnell einsehen, warum automatische Tests so wichtig sind. Die Java-Vorkenntnisse sollten dann auch ausreichen, um das Buch ohne Probleme zu verstehen. Literaturempfehlungen Logisch, oder? :-) * Die perfekte Ergänzung für einen noch tieferen Einstieg in das Testen deiner Software: * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts JUnit Unit Testing with JUnit - Tutorial JUnit Cheat Sheet Zusammenfassung Das Buch in der IT-Ausbildung Mit meinen IT-Azubis arbeite ich "Pragmatic Unit Testing in Java 8 with JUnit" durch, sobald sie erste kleine Java-Programme geschrieben haben. Das 2015 erschienene Buch umfasst rund 200 Seiten und berücksichtigt Java-8-Funktionen wie Lambda-Ausdrücke. Etwas Programmiererfahrung reicht für den Einstieg aus. Anhand ausführlich erklärter Beispiele kannst du sowohl den getesteten Code als auch die Tests nachvollziehen. Meine IT-Azubis kamen mit ihrem Vorwissen gut zurecht. Von den 14 Kapiteln sind etwa zehn schon im ersten Ausbildungsjahr verständlich; Themen wie nebenläufiger Code brauchen weitere Vorkenntnisse. Nach dem Lesen bespreche ich mit meinen IT-Azubis offene Fragen und prüfe, was sie gelernt haben. Ich empfehle dir die englische Ausgabe, weil du englische Fachbegriffe als Fachinformatiker:in Anwendungsentwicklung im Arbeitsalltag brauchst. Einige davon können auch in der Prüfung vorkommen. Teil 1: Erste Unit-Tests schreiben Durch automatisierte Tests prüfst du, ob dein Programm das erwartete Verhalten zeigt. Bei späteren Änderungen helfen dir Regressionstests, Fehler zu erkennen, die durch das Überarbeiten des Codes entstehen. Das Buch zeigt mit Screenshots, wie du JUnit in Eclipse einrichtest. Für IntelliJ und NetBeans gibt es Anleitungen im Anhang. Die behandelten Testprinzipien gelten unabhängig von deiner Entwicklungsumgebung. An einer Beispielklasse lernst du, welche Methoden und Pfade durch den Code du testen kannst. Dabei begegnen dir auch die JUnit-Methoden Before und After, die vor beziehungsweise nach jedem Test laufen. Damit bereitest du einen Test vor und räumst anschließend wieder auf. Mit Assertions vergleichst du erwartete Werte mit den Ergebnissen deines Codes. Hamcrest-Matcher machen solche Vergleiche wie englische Sätze lesbar. Dadurch ist leichter zu erkennen, welcher Wert erwartet wird und welcher aus dem Programm stammt. Wenn du diese Werte vertauschst, werden Fehlermeldungen schwerer verständlich. Auch Exceptions gehören zu den Testfällen: Du prüfst beispielsweise, ob bei einem bestimmten Fehlerzustand die erwartete Exception auftritt. Tests strukturieren und als Dokumentation lesen Mit Arrange, Act, Assert (AAA) gliederst du einen Test in die Schritte Vorbereiten, Ausführen und Prüfen. Dieses Wissen habe ich bereits in Prüfungen abgefragt. Das Buch behandelt außerdem, wie die getestete Klasse und ihre Testklasse zusammenarbeiten und welche Rolle die Sichtbarkeit von Methoden spielt. An sprechenden Testnamen und den beschriebenen Fällen kannst du ablesen, wie sich der Code fachlich verhalten soll. Tests helfen dir dadurch auch, eine fremde Anwendung zu verstehen. Teil 2: Passende Testfälle finden Wenn du mit dem Testen anfängst,...

Um Werkzeuge, die dem Entwickler beim Bauen seiner Software viel Arbeit abnehmen, geht es in der siebenundneunzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Mit einem Build-Werkzeug automatisiere ich die Schritte, die aus Quellcode eine lauffähige Software machen. Dazu gehören etwa das Laden benötigter Bibliotheken und das Ausführen von Tests; auch das Deployment lässt sich einbinden. Ein automatisierter Build spart dir manuelle Arbeit, verringert Fehler und bildet die Grundlage für Continuous Integration sowie die anschließenden Prozesse bis zum Continuous Deployment. Dein Build-Skript gehört zusammen mit dem Quellcode in die Versionsverwaltung. An Gradle zeige ich dir, wie sich solche Abläufe durch Skripte erweitern lassen und wie der Wrapper die passende Werkzeugversion für dein Projekt bereitstellt. Kapitelmarken [00:00:00] Begrüßung und Einstieg in Build-Werkzeuge [00:02:16] Was gehört zu einem Build? [00:03:34] Wie ein Build-Werkzeug den Ablauf automatisiert [00:04:43] Zeit sparen und Wissen im Team verteilen [00:06:05] Das Works-on-my-machine-Problem [00:07:09] Automatisierte Builds als Grundlage für CI und Deployment [00:07:47] Build-Skripte beschreiben und versionieren [00:09:42] Aufgaben eines Build-Werkzeugs [00:10:21] Abhängigkeiten auflösen und Bibliotheken bereitstellen [00:13:02] Code kompilieren und Tests ausführen [00:14:27] Code-Coverage und statische Code-Analyse [00:15:11] Pakete erzeugen und in Artifactory veröffentlichen [00:16:33] Software automatisch deployen [00:17:00] IDE-Projektdateien für den jeweiligen Rechner erzeugen [00:18:50] CSS und JavaScript zusammenfassen und verkleinern [00:20:02] Code durch Obfuscation verschleiern [00:21:11] Technische Dokumentation erzeugen [00:21:52] Eigene Build-Schritte ergänzen und Werkzeuge auswählen [00:23:30] Zusammenhang mit Continuous Integration [00:24:16] Bekannte Build-Werkzeuge für verschiedene Plattformen [00:27:00] Erfahrungen mit automatisierten Builds für Natural [00:28:50] Werkzeug und Voraussetzungen im Ausbildungsbetrieb klären [00:29:59] Projektkonventionen und vorhandene Vorlagen [00:32:02] Das eigene Build-Skript verstehen [00:33:05] Erzeugte Dateien aus der Versionsverwaltung ausschließen [00:34:23] Gradle für Java und Android [00:35:01] Gradle-Skripte mit DSL und Groovy erweitern [00:36:44] Laufzeit von Gradle-Builds [00:36:59] Die passende Gradle-Version mit dem Wrapper starten [00:38:04] Erste Befehle: build, clean und eclipse [00:39:23] Buch und weitere Quellen zu Gradle [00:40:55] Fragen für Episode 100 [00:41:47] Ausblick auf den Buchclub zu JUnit [00:42:24] Newsletter und Verabschiedung Inhalt Die Episode ist wie meine Einführung in die Versionsverwaltung mit Git in mehrere Fragen aufgeteilt. Los geht es mit allgemeinen Fragen zu Build-Werkzeugen. Dann folgen Fragen zum Einsatz im eigenen Unternehmen. Und zuletzt gehen auf die Details von Gradle ein. Allgemein Die folgenden Fragen sind unabhängig vom konkreten Build-Werkzeug. Was ist ein Build? Der Vorgang, der alle Aktionen umfasst, die zum Erstellen einer lauffähigen und deploybaren Software aus Basisartefakten wie Sourcecode nötig sind. Was macht ein Build-Werkzeug? Mit einem Build-Werkzeug können alle notwendigen Build-Schritte automatisiert werden. Was sind die Vorteile eines Build-Werkzeugs? Die Software kann automatisiert und damit schneller und verlässlicher gebaut werden. Kopfmonopole werden abgebaut. "Works on my machine" wird verhindert. Ein automatischer Build ist die Grundlage für Continuous Integration/Delivery/Deployment. Was ist ein Build-Script? In einem Build-Script werden die notwendigen Build-Schritte definiert. Es wird vom Build-Werkzeug wie Programmcode ausgeführt. Warum sollten Build-Scripts versioniert werden? Letztlich sind die Build-Scripts ausführbarer "Code", der ganz normal mit versioniert werden sollte. Allein, um Änderungen am Build mit Änderungen im Code zu synchronisieren und später auch noch frühere Builds nachstellen zu können. Welche Aktionen kann ein Build-Werkzeug bei einem Build durchführen? Abhängigkeiten auflösen (z.B. fremde JARs oder DLLs einbinden) Kompilieren des Codes Testen (mit Analyse der Code Coverage) Statische Code-Analyse durchführen (z.B. Code-Style, bestimmte Bugs) Paketieren der Anwendung (z.B. als JAR, DLL) Snapshots der Software erzeugen und in ein Artefakt-Repository einstellen Deployment der Anwendung auf ein Zielsystem Maschinenunabhängig Projekte für die jeweilige IDE erstellen Minification von Artefakten (z.B. CSS und JavaScript) Obfuscation zum Schutz des Quellcodes Technische Dokumentation der Software erzeugen Alles, was man sonst noch so manuell tun müsste Wie hängt das Build-Werkzeug mit Continuous Integration zusammen? Ohne automatischen Build ist kein CI möglich! Welche bekannten Build-Werkzeuge gibt es für Java, .NET, Ruby und C? Java: Ant, Maven, Gradle .NET: MSBuild Ruby: Rake C: make Dein Unternehmen Diese Fragen solltest du dir stellen, wenn du in deinem Unternehmen mit einem Build-Werkzeug arbeiten willst/musst. Welche konkreten Build-Werkzeuge setzt dein Unternehmen ein? Was musst du tun, um dieser auf deiner Maschine nutzen zu können? Welche Konventionen musst du ggfs. einhalten, um sie in deinem Projekt nutzen zu können? z.B. Ordnerstruktur des Projekts, Benennung der Komponenten. Wo findest du Vorlagen für eigene Build-Scripts? Welche Dateien gehören zum Build-Script deines Unternehmens und was sind ihre jeweiligen Aufgaben? Welche Ordner und Dateien deines Projekts solltest du von der Versionierung ausschließen? Gradle Zum Schluss kommen noch ein paar einleitende Fragen zum konkreten Werkzeug Gradle. Was ist Gradle? Ein Build-Werkzeug für Java, das inzwischen z.B. der Standard für Android-Projekte ist. Was sind die Vorteile von Gradle gegenüber Maven und Ant? Gradle verwendet eine flexible und mächtige DSL für die Build-Scripts und kann sowohl deklarativ, als auch imperativ verwendet werden. Was ist der Gradle Wrapper? Eine Möglichkeit, um Gradle in der passenden Version für das aktuelle Build-Script automatisch herunterzuladen und damit den Build durchzuführen. Mit welchem Befehl startest du einen normalen Build mit Gradle? gradle build Mit welchem Befehl räumst du dein Projektverzeichnis mit Gradle auf? gradle clean Mit welchem Befehl erzeugst du ein importierbares Eclipse-Projekt mit Gradle? gradle eclipse Literaturempfehlungen Wenn du tiefer in Gradle einsteigen möchtest (was natürlich nur sinnvoll ist, wenn du es selbst einsetzt), empfehle ich dir dieses Buch von Joachim Baumann. Es hat uns beim Erstellen einer Vorlage für unsere eigenen Build-Scripts sehr geholfen. * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Erstellungsprozess – Wikipedia Java Quickstart - Gradle User Guide Version 3.4.1 The Gradle build system- Tutorial Zusammenfassung Vom Quellcode zur lauffähigen Software Wenn ich eine neue Softwareversion bereitstelle, müssen aus dem Quellcode und den weiteren Projektdateien lauffähige Artefakte entstehen. Alle dafür erforderlichen Schritte gehören zum Build. Das Ergebnis soll sich auf der vorgesehenen Umgebung bereitstellen lassen, sodass Benutzer:innen damit arbeiten können. Ein Build-Werkzeug führt diesen Ablauf automatisch aus. Du startest ihn beispielsweise mit einem Kommandozeilenbefehl. Anschließend laufen die hinterlegten Schritte bis zum fertigen Ergebnis durch, ohne dass du zwischendurch manuell eingreifen musst. Warum sich ein automatisierter Build lohnt Bei jedem Release Dateien von Hand zu kopieren oder Konfigurationen anzupassen, kostet Zeit und eröffnet Möglichkeiten für Fehler. Ein automatisierter Ablauf führt die festgelegten Schritte verlässlich aus. Während längere Vorgänge laufen, kannst du dich anderen Aufgaben widmen. Wenn jede:r Entwickler:in den Build starten kann, verteilt sich außerdem das Wissen darüber, wie die Software entsteht und bereitgestellt wird. Der Betrieb hängt dadurch weniger von einzelnen Personen ab, die sämtliche manuellen Schritte kennen. Ein weiteres Problem begegnet dir unter dem Namen "Works on my machine": Auf deinem Rechner funktioniert die Software, auf dem Rechner einer anderen Person oder in der Zielumgebung scheitert sie. Ein Build-Werkzeug hilft dabei, benötigte Bibliotheken bereitzustellen und Abhängigkeiten von lokalen Pfaden zu vermeiden. Dadurch lässt sich das Projekt auf unterschiedlichen Maschinen bauen. Für Continuous Integration muss die Software automatisch gebaut werden können. Darauf bauen auch Continuous Delivery und Continuous Deployment auf, bei denen weitere Schritte bis zum Bereitstellen der Software automatisiert werden. Was ein Build-Werkzeug übernehmen kann Je nach Projekt umfasst der Ablauf unterschiedliche Aufgaben: Abhängigkeiten auflösen: Im Build-Skript legst du fest, welche Bibliotheken dein Projekt in welcher Version benötigt. Das Werkzeug lädt fehlende Pakete beispielsweise aus Maven Central oder über NuGet herunter und stellt sie für den Build bereit. Umfangreiche Abhängigkeiten und Konflikte zwischen Versionen können sonst viel manuelle Arbeit verursachen, die als "Dependency Hell" bezeichnet wird. Code kompilieren: Das Werkzeug ruft den passenden Compiler auf und berücksichtigt die benötigten Bibliotheken. Es muss die Sprache und Plattform deines Projekts unterstützen. Tests ausführen: Nach dem Kompilieren können automatische Tests prüfen, ob sich die Software wie erwartet verhält. Eine Code-Coverage-Analyse zeigt dabei, welche Teile des Codes durch die Tests ausgeführt werden. Code statisch analysieren: Zusätzliche Werkzeuge prüfen beispielsweise, ob der Quellcode den vereinbarten Styleguides entspricht oder Hinweise auf Fehler enthält. Die Ergebnisse lassen sich bei jedem Build aufbereiten. Pakete erzeugen: Aus den Projektdaten entstehen Artefakte wie eine JAR-Datei bei Java oder ein Gem bei Ruby. Artefakte veröffentlichen: Das fertige Paket kann automatisch in ein Artefakt

Um Kapitel 10 (Konzepte der Programmierung) des Handbuchs für Fachinformatiker geht es in der sechsundneunzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Mit Kapitel 10 des Handbuchs für Fachinformatiker von Sascha Kersken gehe ich mit dir grundlegende Konzepte der Programmierung durch. Wenn du Algorithmen und Datenstrukturen verstehst, kannst du passende Lösungen auswählen und nachvollziehen, wie sich dein Code bei größeren Datenmengen verhält. Reguläre Ausdrücke helfen dir im Arbeitsalltag beim Bearbeiten von Texten, während ereignisgesteuerte Programmierung auch im Fachgespräch relevant ist. Die Beispiele zur systemnahen Programmierung sowie zu Netzwerkzugriffen und grafischen Oberflächen geben dir Einblicke in Arbeitsfelder, die über deinen Ausbildungsbetrieb hinausgehen. Kapitelmarken [00:00:00] Einstieg in den Buchclub zu Kapitel 10 [00:01:50] Warum du Datenstrukturen intern verstehen solltest [00:03:46] Überblick über die Programmierkonzepte [00:04:01] Sortieralgorithmen und Komplexität [00:07:50] Rekursion selbst ausprobieren [00:08:25] Sortieraufgaben in Praxis und Prüfung [00:09:34] Lineare und binäre Suche [00:10:17] Stack, Queue und weitere Datenstrukturen [00:13:19] Reguläre Ausdrücke im Arbeitsalltag [00:16:11] Prozesse und Pipes [00:16:47] Threads und nebenläufige Programmierung [00:19:26] Netzwerkprogrammierung mit Sockets [00:21:08] Über den Ausbildungsbetrieb hinaus lernen [00:22:53] Grafikprogrammierung und Mathematik [00:24:59] Fensteranwendungen und Event-Handling [00:26:45] Event-Bus und Reactive Programming [00:29:29] Welche Konzepte für die Prüfung relevant sind [00:31:38] Das frühere Unterkapitel zu Java EE [00:33:07] Fragen für Episode 100 [00:33:43] Reguläre Ausdrücke mit Regex Crossword üben [00:34:17] Projektpräsentation, weiterführende Links und Newsletter [00:35:36] Weitere Buchclub-Termine Das Kapitel 10 des IT-Handbuchs für Fachinformatiker* von Sascha Kersken liefert einen Überblick über zentrale Konzepte der Programmierung: Algorithmen, Datenstrukturen, reguläre Ausdrücke, Netzwerkprogrammierung usw. Insgesamt ein spannendes Kapitel gefüllt mit viel Know-How für die Praxis. Auch wenn nicht so viel prüfungsrelevantes Wissen enthalten ist, sollte jeder Anwendungsentwickler die beschriebenen Inhalte kennen, da man ihnen früher oder später sehr wahrscheinlich bei der eigenen Arbeit begegnen wird. 10.1 Algorithmen und Datenstrukturen Sortieralgorithmen zeigen gut die Unterschiede bei der Komplexität verschiedener Lösungen für das gleiche Problem (BubbleSort vs. QuickSort). In einer der letzten Prüfungen war ein kleiner Sortieralgorithmus enthalten. Der kleine Ausflug zur Rekursion und Iteration ist wichtig. Suchalgorithmen sind für die Praxis nicht ganz so wichtig, bilden aber die Grundlage von Datenbanken. Daher begegnen sie uns - wenn vielleicht auch unbewusst - jeden Tag. Die abstrakten Datenstrukturen Stack, Queue und Baum sind absolutes Grundwissen für jeden Entwickler. Es gibt keine Ausrede dafür, sie nicht zu kennen! Ich lasse sie in meinem Java-Tutorial auch immer einmal selbst programmieren. 10.2 Reguläre Ausdrücke Ich bin immer wieder erstaunt, wie selten fertige Anwendungsentwickler sich mit regulären Ausdrücken auskennen. Ich könnte ohne sie nicht leben :-) Es gab schon einmal eine Aufgabe zu Textmustern in der IHK-Prüfung, die allerdings eine eigene Syntax vorgab. Aber die Idee der regulären Ausdrücke ist daher wohl als prüfungsrelevant einzustufen. 10.3 Systemnahe Programmierung Prozesse und Pipes sind wichtige Konzepte für die systemnahe Programmierung, sie jeder Entwickler einmal gehört haben sollte. In der Praxis werden sie aber wohl nur relevant, wenn man halt systemnah programmiert :-) Threads sind ein Konzept, das heutzutage immer wichtiger wird. Da Prozessoren nicht mehr (oder kaum noch) vertikal skalieren, sondern horizontal, sollte jeder Entwickler sich mit der nebenläufigen Programmierung auseinandersetzen. Viele moderne Sprachen bieten Abstraktionen für die nebenläufige Programmierung an, sodass man nicht selbst mit Threads hantieren muss. 10.4 Einführung in die Netzwerkprogrammierung Jeder Entwickler sollte wissen, was eine Socket ist. In der Praxis wird man aber wahrscheinlich wenig damit arbeiten, da einem moderne Sprachen das Low-Level-Coding abnehmen. 10.6 GUI- und Grafikprogrammierung Ein netter Ausblick auf die eigene Programmierung von grafischen Ausgaben, aber für die Praxis und die Prüfung eher uninteressant, da man heutzutage sehr wahrscheinlich Frameworks dafür nutzen würde. Das Unterkapitel zur fensterbasierten Programmierung und dem Event Handling ist allerdings wieder sehr praxisrelevant. Auch in der mündlichen Prüfung haben wir schon öfter nach Events und Event Handlern gefragt. Frühere Inhalte 10.5 Verteilte Anwendungen mit Java Enterprise Edition Zurecht entfernt, da schwergewichtige Konzepte wie EJBs und SOAP heute eher eine untergeordnete Rolle spielen und in der Kürze ohnehin nicht vermittelt werden könnten. Literaturempfehlungen Was sonst? :-) *(direkt beim Rheinwerk-Verlag bestellen*) Die erwähnten Bücher zum Buchclub und zur Einarbeitung in Java EE gibt es hier: Jeff Langr - Pragmatic Unit Testing in Java 8 with JUnit (Affiliate)* Alexander Salvanos - Professionell entwickeln mit Java EE 7: Das umfassende Handbuch (Affiliate)* Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Regex Crossword Zusammenfassung Algorithmen und Datenstrukturen verstehen Für dich als IT-Azubi in der Anwendungsentwicklung bespreche ich Kapitel 10 des Handbuchs für Fachinformatiker von Sascha Kersken. Die Codebeispiele zeigen, wie grundlegende Konzepte intern funktionieren. Dieses Wissen hilft dir dabei, Datenstrukturen passend auszuwählen und Ursachen für langsame Programme zu erkennen. In meinem Java-Tutorial lässt sich jede:r Azubi deshalb unter anderem mit einer selbst programmierten Queue und einer verketteten Liste auf diese Grundlagen ein. Sortieren, Suchen und Rekursion An Bubble Sort und Quick Sort führt das Kapitel in Sortieralgorithmen ein. Bubble Sort lässt sich einfach programmieren und hat durch seine geschachtelten Schleifen einen quadratischen Aufwand: Bei doppelt so vielen Elementen steigt der Aufwand auf das Vierfache. Quick Sort teilt die Liste und arbeitet rekursiv. An solchen Beispielen kannst du nachvollziehen, wie der Aufwand eines Algorithmus mit der Datenmenge wächst. Bei der linearen Suche werden Elemente nacheinander geprüft. Die binäre Suche grenzt den Bereich schrittweise ein, wodurch sie bei großen Datenmengen erheblich weniger Vergleiche braucht. Das Kapitel behandelt diese Suchverfahren auf wenigen Seiten. Zum Üben empfehle ich dir, selbst etwas Rekursives zu programmieren. Dabei lernst du die besondere Art kennen, ein Problem rekursiv zu lösen, und begegnest den Schwierigkeiten, die daraus entstehen. Der kurze Kasten im Buch reicht dafür als Einstieg. In einer von mir betrachteten IHK-Prüfung musste innerhalb einer Programmieraufgabe eine Liste sortiert werden. Der Algorithmus war frei wählbar, sodass Bubble Sort für die Aufgabe ausreichte. Auch im Arbeitsalltag kann eine eigene Sortierlösung erforderlich sein, wenn die vorhandenen Sprachmittel die Aufgabe nicht abdecken. Stack, Queue und Bäume Mit Codebeispielen stellt das Buch ausgewählte Datenstrukturen vor: Ein Stack folgt dem LIFO-Prinzip, also "Last In, First Out". Das zuletzt abgelegte Element wird zuerst entnommen. Rücksprungadressen bei Methodenaufrufen werden beispielsweise auf einem Stack verwaltet. Eine Queue arbeitet nach FIFO, also "First In, First Out". Das zuerst eingefügte Element wird zuerst verarbeitet, wie bei einer Warteschlange. Bäume gehören ebenfalls zu den behandelten Grundstrukturen. Ergänzend zum Buch erwähne ich die Double Ended Queue, bei der du an beiden Enden Elemente einfügen kannst. Damit lässt sich beispielsweise eine dringende Nachricht vorne einordnen. Beim Lernen hilft dir die Frage, für welche Aufgabe eine Datenstruktur geeignet ist. Ihre interne Arbeitsweise erklärt auch, warum bestimmte Operationen mehr Zeit brauchen. Stack und Queue bieten sich als Themen für das Fachgespräch an. Reguläre Ausdrücke im Arbeitsalltag Zum Einstieg in reguläre Ausdrücke empfehle ich dir die rund 18 Seiten des Kapitels. Dort werden wichtige Syntaxelemente sowie Gruppen und Klammerungen behandelt. Mit regulären Ausdrücken kannst du Textmuster erkennen und Texte bearbeiten. Beispielsweise lassen sich Leerzeichen am Zeilenende entfernen oder Logdateien anhand bestimmter Muster auswerten. Viele Texteditoren und IDEs unterstützen die Suche mit regulären Ausdrücken samt Ersetzen. Auf der Linux-Kommandozeile gehört grep zu den entsprechenden Werkzeugen. In einer schriftlichen Prüfung habe ich bereits eine Aufgabe zu Textmustern gesehen, die eine eigens definierte Syntax vorgab. Für die Praxis empfehle ich dir, die gebräuchliche Regex-Syntax zu lernen. Beim Regex Crossword kannst du sie spielerisch üben. Systemnah und nebenläufig programmieren An C-Beispielen zeigt das Buch, wie Prozesse über Pipes kommunizieren. Wie weit du diese Details vertiefen solltest, hängt von deinen Aufgaben im Betrieb ab. In den von mir betrachteten Prüfungen sind mir solche Programmieraufgaben bislang nicht begegnet. Bei Threads geht es darum, mehrere Abläufe nebenläufig auszuführen. Mehrere CPU-Kerne können dabei Arbeit übernehmen. Für Entwickler:innen wird es anspruchsvoll, die möglichen Abläufe nachzuvollziehen und fehlerfreien Code zu schreiben. Viele Programmiersprachen bieten dafür Abstraktionen an. Als Beispiel bespreche ich async und await in C#, mit denen du asynchronen Code schreiben kannst. Asynchronität und Nebenläufigkeit bezeichnen unterschiedliche Konzepte. Das Buch liefert eine Einführung samt Java-Beispiel; für deine praktische Arbeit solltest du zusätzlich nachlesen, welche Möglichkeiten deine Programmiersprache bietet. Über Netzwerke kommunizieren ...

Nachdem letzte Woche bereits häufige Fragen im Fachgespräch rund um das Thema Softwaretests besprochen wurden, folgen nun einige Detailfragen zum Bereich Unit-Tests in der fünfundneunzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Mit meinen Fragen zu Unit Testing bereitest du dich auf dein Fachgespräch als Fachinformatiker:in Anwendungsentwicklung vor. Du erfährst, was eine Unit ist, wie du Tests nach Arrange, Act, Assert aufbaust und wie du Abhängigkeiten durch Testobjekte ersetzt. Code Coverage und Mutationstests helfen dir, Lücken in deinen Tests zu finden. Die Testpyramide beschreibt, wie du deine Tests verteilst, wobei schnelle, verlässliche Unit-Tests die breite Basis bilden. Kapitelmarken [00:00:01] Hinweise zum Fachgespräch [00:00:20] Unit Testing als Thema im Fachgespräch [00:01:24] Was ist eine Unit? [00:03:40] Unit-Tests, Integrationstests und Systemtests [00:08:08] Aufgaben und Beispiele von Unit-Test-Frameworks [00:10:26] Assertions und erwartete Werte [00:11:51] Tests nach Arrange, Act, Assert aufbauen [00:13:53] Abhängigkeiten durch Mocking ersetzen [00:15:40] Stubs und Mocks im Detail [00:17:48] Code Coverage und sinnvolle Testabdeckung [00:19:40] Eigenschaften guter Unit-Tests [00:22:49] Mutationstests [00:24:12] Die Testpyramide [00:26:11] Oberflächen automatisiert testen [00:29:08] Rückblick auf die Fachgesprächsfragen [00:31:53] Buchtipp: Pragmatic Unit Testing in Java 8 with JUnit [00:33:15] Buchtipp: Growing Object-Oriented Software, Guided by Tests [00:35:42] Ankündigung des Buchclubs [00:36:17] Newsletter und Listen zur Projektarbeit [00:36:54] Kontakt und Fragen zum Unit Testing [00:37:20] Fragen für Episode 100 Inhalt Was ist eine Unit? Die kleinste zu testende Einheit, meist eine Methode. Wie unterscheiden sich Unit- bzw. Komponenten-, Integrations- und Systemtest? Unit-Test: Einzelne Komponente wird in Isolation getestet Integrationstest: Das Zusammenspiel mehrerer Komponenten wird getestet Systemtest: Das System als Ganzes wird auf Funktionalität getestet Was ist ein Unit-Test-Framework? Ein Softwareframework, das den Entwickler beim Schreiben automatischer Tests unterstützt. Was ist eine Assertion? Eine konkrete Prüfung in einem Unit-Test (z.B. Gleichheit von Werten). Was bedeutet AAA? Arrange, Act, Assert Was ist Mocking? Abhängigkeiten werden durch Fake-Objekte ersetzt, um die eigentlich zu testende Komponente in Isolation ausführen zu können. Was ist Code-Coverage? Der Grad der Abdeckung des Codes durch die Tests. Welche Eigenschaften sollten Unit-Tests haben? Schnell, einfach, isoliert, wiederholbar, verlässlich, keine Infrastruktur verwenden. Was ist ein Mutationstest? Ein Test, der den zu testenden Code verändert, um die Testabdeckung durch vorhandene Tests zu prüfen. Was ist die Testpyramide? Eine Empfehlung für das Verhältnis zwischen Unit- (viele), Integrations- (mehrere) und Systemtests (wenige). Wie kann man Oberflächen testen? Manuell oder mit Hilfe von Frameworks wie Selenium. Literaturempfehlungen Einen sehr schönen Einstieg in das Thema Unit-Testing liefert Jeff Langr in seinem Buch Pragmatic Unit Testing in Java 8 with JUnit*. Er fängt "bei 0" an und erklärt alle wichtigen Konzepte inkl. Mocking für die Praxis. Außerdem arbeitet er auch mit den neuen Features von Java 8 (Lambdas, Streams) um die Tests zu optimieren. Sehr empfehlenswert! Ich lasse es meine Azubis als Grundlagenbuch lesen und werde bald auch einen Buchclub dazu aufnehmen. * Und wenn du ein Buch lesen möchtest, dass dir noch einmal einen völlig anderen Blick auf das Vorgehen bzgl. der Tests beim Schreiben einer Software ermöglicht, empfehle ich dir wärmstens Growing Object-Oriented Software, Guided by Tests*. Die beiden Autoren zeigen ein komplett testgetriebenes Vorgehen, das mit Integrationstests beginnt. Ein sehr spannender Ansatz, der mit einem großen Praxisbeispiel in Java illustiert wird. Hier habe ich das Buch schon vor einigen Jahren rezensiert: Growing Object-Oriented Software, Guided by Tests (Freeman/Pryce). * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Testabdeckung – Wikipedia Regressionstest – Wikipedia Zusammenfassung Was du unter einer Unit verstehst Wenn ich im Fachgespräch nach einer Unit frage, geht es um die kleinste Einheit, deren Verhalten du testen kannst. In einer objektorientierten Sprache ist das meist eine Methode; bei prozeduralem Code kommt eine Funktion oder Prozedur infrage. Damit du das Verhalten prüfen kannst, muss etwas beobachtbar sein. Das kann ein Rückgabewert sein oder ein Seiteneffekt, etwa ein Auftrag, eine E-Mail zu versenden. Eine Assertion prüft anschließend, ob das beobachtete Verhalten deiner Erwartung entspricht. Bei Methoden, die innerhalb einer Klasse zusammenarbeiten, ziehe ich die Grenze bereits beim Integrationstest. Ein einzelner Unit-Test sollte sich auf genau ein Verhalten konzentrieren. Welche Testebenen es gibt Unit-Test beziehungsweise Komponententest: Du prüfst eine einzelne Einheit isoliert. Abhängigkeiten ersetzt du durch Testobjekte, sodass der Test unabhängig von einer echten Datenbank oder einem Netzwerk läuft. Integrationstest: Du prüfst, wie mehrere Komponenten zusammenarbeiten. Dabei kann auch Infrastruktur beteiligt sein, beispielsweise das Dateisystem. Systemtest: Du prüfst die Anwendung als Ganzes über ihre Schichten hinweg. Wenn du über eine Weboberfläche ein Benutzer:innenkonto anlegst und anschließend prüfst, ob es in der Datenbank gespeichert wurde, ist das ein solcher Test. Systemtests kannst du manuell durchführen oder automatisieren. Bei Webanwendungen lässt sich dafür beispielsweise ein Browser mit Selenium fernsteuern. Wie dir ein Unit-Test-Framework hilft Beim Schreiben automatisierter Tests fallen wiederkehrende Aufgaben an. Ein Test-Framework stellt dir dafür Funktionen bereit, etwa um Werte zu vergleichen und fehlgeschlagene Tests anzuzeigen. Dadurch musst du den entsprechenden Code weniger oft selbst schreiben. Für Java gibt es JUnit, im .NET-Umfeld beispielsweise NUnit. Bei Ruby steht unter anderem RSpec zur Verfügung. Für viele Programmiersprachen existieren passende Frameworks. Für die Sprache Natural habe ich im Rahmen meiner Masterarbeit ein eigenes Unit-Test-Framework geschrieben. Zu dessen grundlegenden Aufgaben gehört es, Module aufzurufen und die Ergebnisse mit Assertions zu prüfen. Der verfügbare Quellcode von JUnit bietet dir ebenfalls einen Einblick darin, wie ein solches Framework aufgebaut ist. Was eine Assertion prüft Wenn du eine Additionsmethode mit zwei Zahlen aufrufst, erwartest du deren Summe als Ergebnis. Eine Assertion vergleicht diesen erwarteten Wert mit dem Wert, den die Methode zurückgibt. Bei einer Abweichung schlägt der Test fehl. Auch andere Bedingungen lassen sich prüfen, beispielsweise ob eine Liste einen bestimmten Wert enthält. In Frameworks begegnen dir dafür häufig die Begriffe Expected für den erwarteten Wert und Actual für den Wert, der beim Test herauskommt. Wie du einen Test nach AAA aufbaust Für meine Unit-Tests folge ich dem verbreiteten Aufbau Arrange, Act, Assert, kurz AAA: Arrange: Du bereitest das Testszenario vor. Dazu erzeugst du beispielsweise ein Objekt der Klasse, die du testen möchtest, und richtest benötigte Testobjekte ein. Act: Du rufst die zu testende Methode auf. Dieser Abschnitt besteht meist aus einer Zeile. Einen Rückgabewert speicherst du für die anschließende Prüfung. Assert: Du prüfst, ob das Ergebnis deiner Erwartung entspricht. Bei einer Methode mit Seiteneffekten kannst du beispielsweise prüfen, welcher Aufruf bei einem Mock angekommen ist. Wie du Abhängigkeiten ersetzt Wenn deine Methode einen Mailserver anspricht, kannst du dessen Rolle im Test durch ein Testobjekt übernehmen lassen. So prüfst du den Auftrag zum Versand einer E-Mail, während die Methode isoliert bleibt. Unter dem Begriff Mocking wird häufig allgemein verstanden, dass Abhängigkeiten durch solche Objekte ersetzt werden. Im Fachgespräch frage ich auch nach den genaueren Begriffen: Ein Stub liefert bei einem Methodenaufruf einen festgelegten Wert zurück. Eine ersetzte Datenbankklasse kann beispielsweise immer die Zahl 7 liefern, mit der deine Methode weiterrechnet. Ein Mock zeichnet auf, welche Methoden bei ihm aufgerufen wurden. Anschließend kannst du unter anderem die übergebenen Parameter und die Zahl der Aufrufe prüfen. Beim Mailversand lässt sich so feststellen, ob die Versandmethode mit der vorgesehenen Empfänger:innenadresse aufgerufen wurde. Mocking-Frameworks wie Mockito für Java oder Moq für .NET unterstützen diese Aufgaben. Viele davon können sowohl feste Rückgabewerte liefern als auch Aufrufe überprüfen. Für dein Fachgespräch solltest du die Begriffe auseinanderhalten können. Was Code Coverage aussagt Wenn deine Tests laufen, kann ein Werkzeug erfassen, welche Zeilen deines Produktivcodes ausgeführt werden. Der Anteil dieser Zeilen heißt Code Coverage oder Codeabdeckung. Werden von 100 Codezeilen 95 durchlaufen, beträgt sie 95 Prozent. Eine hohe Abdeckung ist ein sinnvolles Ziel. Dabei solltest du auch Sonderfälle berücksichtigen, damit deine Tests möglichst viele Fehler finden können. Viele Tests für denselben Fall lassen andere Fälle weiterhin offen. Für pauschal angestrebte 100 Prozent halte ich den Aufwand in der Praxis für unangemessen, etwa bei automatisch erzeugtem Boilerplate-Code wie einer toString-Methode. Solche Stellen vollständig abzudecken, kann viel Zeit beanspruchen. Welche Eigenschaften deine Unit-Tests haben sollten Schnell: Ein Unit-Test sollte im Millisekundenbereich laufen. Dadurch kannst du deine Tests nach kleinen Codeänderungen ausführen und zeitnah erkennen, ob etwas kaputtgegangen ist. Einfach: Halte den Testcode kurz und verständlich. Auch hier gelten Regeln für guten Code, etwa das Single Responsibility Principle. Als Einstieg empfehle ich eine Assertion pro Testmethode; davon weiche ich gelegentlich ab. ...

Einige häufige Fragen im Fachgespräch rund um das Thema Softwaretest sind Inhalt der vierundneunzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Für dein Fachgespräch als Fachinformatiker:in Anwendungsentwicklung empfehle ich dir, Testverfahren anhand fester Fragen einzuordnen: Was wird getestet, wie und von wem, mit welchen Kenntnissen, zu welchem Zeitpunkt und mit welchem Ziel? Dazu gehören auch Blackbox- und Whitebox-Tests sowie statische und dynamische Verfahren. Mit der Testabdeckung beschreibst du, welche Anweisungen oder Wege durch deinen Code geprüft wurden; bei komplexem Code wächst der Aufwand dafür. Tests zeigen Fehler und bestätigen das Verhalten für geprüfte Fälle, wobei ein vollständiger Nachweis der Fehlerfreiheit durch Testen praktisch unerreichbar bleibt. Kapitelmarken [00:00:01] Einstieg und Informationen zum Fachgespräch [00:00:37] Testen als Thema im Fachgespräch [00:02:37] Offene Prüfungsfragen strukturiert beantworten [00:03:26] Testverfahren anhand fester Fragen einordnen [00:05:10] Komponenten-, Integrations- und Systemtests [00:06:29] Funktionale und nicht funktionale Anforderungen [00:08:13] Manuelle und automatische Tests [00:09:38] Wer führt Tests durch? [00:10:17] Blackbox- und Whitebox-Tests [00:12:03] Test First, Test Last und Test-Driven Development [00:13:28] Alpha- und Beta-Tests [00:14:12] Dynamische und statische Testverfahren [00:15:34] Testziele und Grenzen erschöpfenden Testens [00:17:48] Anweisungsüberdeckung: C0 [00:19:04] Zweigüberdeckung: C1 [00:20:02] Pfadüberdeckung: C2 [00:21:23] Zyklomatische Komplexität [00:23:48] Abnahmetest und User Acceptance Test [00:25:03] Lasttest [00:26:33] Smoke-Test [00:28:24] Exploratives Testen [00:30:27] Rückblick auf die Testverfahren [00:32:59] Links und Literatur zu Softwaretests [00:34:36] Projektpräsentation und Rückengesundheit im Blog [00:35:44] Fachartikel zu WireMock [00:36:19] Newsletter und Materialien zur Projektarbeit [00:37:15] Fragen für Episode 100 und Ausblick Inhalt Wie lassen sich Testverfahren klassifizieren? Was wird getestet? Komponente, Integration mehrerer Komponenten oder das ganze System. Funktionale oder nicht-funktionale Anforderungen. Wie werden sie durchgeführt? Durch den Menschen (manuell) oder eine Maschine (automatisch). Wer führt sie durch? Entwickler oder Fachbereich. Welche Kenntnisse sind für die Erzeugung von Testfällen nötig? Nur das nach außen sichtbare Verhalten (Black-Box) oder auch der Sourcecode (White-Box). Wann werden die Tests erstellt? Test first vs. test last. Alpha-/Beta-Test. Wird die Software für den Test ausgeführt (dynamisch) oder nicht (statisch)? Welches Ziel verfolgen die Tests? Z.B. Regression verhindern, Last simulieren. Was ist der Unterschied zwischen Black- und White-Box-Test? Bei Black-Box-Tests kennt der Tester nicht die interne Struktur der Software, sondern sieht nur das nach außen sichtbare Verhalten. Beim White-Box-Test wird der Sourcecode mit einbezogen, um z.B. bestimmte Testfälle zu definieren. Was sind Anweisungs-, Zweig- und Pfadüberdeckung? Alle sind Maße für die Testabdeckung des Codes. Bei der Anweisungsüberdeckung (C0) wird jede Anweisung im Code mind. einmal durchlaufen. Bei der Zweigüberdeckung (C1) wird jeder Zweig im Code mind. einmal durchlaufen. Das heißt, bei if-Anweisungen wird sowohl der if-Zweig als auch der else-Zweig durch einen Test abgedeckt. Sie inkludiert die Anweisungsüberdeckung. Bei der Pfadüberdeckung (C2) werden alle Pfade durch den Code getestet. Das heißt, dass z.B. alle möglichen Wege durch Schleifen abgedeckt sein müssen. Sie inkludiert die Zweigüberdeckung. Was ist die zyklomatische Komplexität? Ein Maß für die Anzahl der möglichen Pfade durch den Code. Welche sonstigen Testverfahren gibt es noch? Abnahmetest oder Akzeptanztest (User Acceptance Test): Finaler Test des Kunden, der das Projekt offiziell beendet. Lasttest: Das System wird unter hohe Last gesetzt, um z.B. den gleichzeitigen Zugriff vieler Benutzer zu simulieren. Smoketest: Erster grober Test der Software, um entscheiden zu können, ob weitere detaillierte Tests überhaupt sinnvoll sind. Exploratives Testen: einfaches "Ausprobieren" durch erfahrene Benutzer. Literaturempfehlungen Wenn du dich wirklich intensiv mit Softwaretests auseinandersetzen willst (oder musst) und auch etwas akademischer werden möchtest, gibt es eigentlich nur eine Empfehlung: Software-Qualität: Testen, Analysieren und Verifizieren von Software* von Peter Liggesmeyer. Das Buch hat mich persönlich bei meiner eigenen Masterarbeit zum Thema Test-Driven-Development begleitet und liefert knackige Definitionen für alle möglichen Begriffe aus dem Umfeld der Softwaretests. Es geht aber auch weit über das Testen hinaus und erklärt z.B. auch statische Codeanalyse und Code-Review-Verfahren. * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Links Smoke testing – Wikipedia Softwaretest – Wikipedia Kontrollflussorientierte Testverfahren – Wikipedia McCabe-Metrik – Wikipedia Testabdeckung – Wikipedia Zusammenfassung Testverfahren im Fachgespräch einordnen Bei einer offenen Frage wie "Welche Testverfahren kennst du?" erwarte ich eine strukturierte Antwort. Als IT-Azubi kannst du dich an diesen Fragen orientieren: Was wird getestet? Eine einzelne Komponente, das Zusammenspiel mehrerer Komponenten oder das gesamte System? Welche Anforderungen werden geprüft? Wie werden die Tests durchgeführt? Manuell durch einen Menschen oder automatisch durch den Computer? Wer führt sie durch? Entwickler:innen, der Fachbereich, eine Testabteilung oder Kund:innen? Welche Kenntnisse brauchst du für die Testfälle? Kennst du den Quellcode oder betrachtest du das Verhalten über Eingaben und Ausgaben? Wann werden die Tests erstellt? Vor oder nach dem Produktivcode? In welcher Phase des Projekts finden sie statt? Wird die Software ausgeführt? Das bestimmt, ob das Verfahren dynamisch oder statisch ist. Welches Ziel haben die Tests? Beispielsweise Fehler finden, Regressionen erkennen, Last simulieren oder die Software abnehmen. Ein Testverfahren lässt sich mehreren Kategorien zuordnen. Ein Unit-Test prüft etwa eine einzelne Komponente, läuft meist automatisch und wird von Entwickler:innen geschrieben. Weil dabei Code ausgeführt wird, gehört er zu den dynamischen Verfahren. Der Testcode kann vor oder nach dem Produktivcode entstehen. Was du testest Komponenten- oder Unit-Test: Du prüfst die kleinste zu testende Einheit deiner Software, häufig eine Methode. Sie wird üblicherweise isoliert getestet. Integrationstest: Du prüfst, wie mehrere Komponenten zusammenarbeiten, beispielsweise eine Klasse mit einer Datenbankklasse. Systemtest: Du prüfst das gesamte System. Ein Beispiel ist eine Aktion über die Oberfläche, die bis zur Datenbank reicht. Bei einem Taschenrechner kannst du prüfen, ob die Addierfunktion das erwartete Ergebnis liefert. Damit testest du eine funktionale Anforderung. Zu den nicht funktionalen Anforderungen gehören unter anderem Performance und Sicherheit sowie Ausfallsicherheit oder Effizienz. Für einen Performance-Test brauchst du messbare Erwartungen, etwa eine zulässige Antwortzeit und einen Toleranzbereich. Die Frage, ob eine Antwort schnell genug kommt, setzt voraus, dass du festgelegt hast, welche Zeit akzeptabel ist. Wie und durch wen getestet wird Wenn ein:e Tester:in die Anwendung bedient und Ergebnisse protokolliert, kostet das Arbeitszeit. Wiederholte manuelle Tests verursachen entsprechend laufenden Aufwand. Automatische Tests lassen sich schnell und mit geringen Kosten pro Durchlauf wiederholen. Das ist bei neuen Releases relevant, weil Änderungen auch bereits vorhandene Funktionen beschädigen können. Entwickler:innen schreiben beispielsweise Unit-Tests und bringen ihr Wissen über den Code ein. Im Fachbereich stehen fachliche Abläufe im Mittelpunkt; dort werden häufig manuelle Tests durchgeführt. Auch Kund:innen oder eine eigene Testabteilung können die Software prüfen. Blackbox und Whitebox Beim Blackbox-Test leitest du Testfälle aus dem von außen sichtbaren Verhalten ab. Du gibst Werte ein und prüfst die Ausgabe, während die interne Struktur für dich verborgen bleibt. Für einen Whitebox-Test kennst du den Quellcode. Dadurch kannst du Testfälle gezielt auf Verzweigungen oder Schleifen ausrichten. Wenn du etwa eine Grenze im Code erkennst, kannst du einen Wert außerhalb dieser Grenze ausprobieren. Dieses Wissen hilft auch dabei, Sonderfälle zu finden, die bei alltäglichen fachlichen Abläufen selten auftreten. Wann Tests entstehen Beim Test First schreibst du den Test vor dem zugehörigen Produktivcode. Dieser Ansatz gehört zum Test-Driven Development, bei dem die Tests auch das Design und die Implementierung vorantreiben. Ich empfehle dir, Tests zuerst zu schreiben. Bei Test Last entstehen die Tests nach dem Produktivcode. Wenn sich das Projektende nähert und Zeit knapp wird, besteht das Risiko, dass die geplanten Tests entfallen. Auch die Projektphase spielt eine Rolle: Ein Alpha-Test kann mit einer ersten lauffähigen Version prüfen, ob die Software grundsätzlich das Gewünschte tut. Ein Beta-Test findet nahe am Release beziehungsweise vor der ersten verkaufsfähigen Version statt, um verbliebene Fehler aufzuspüren. Dynamische und statische Verfahren Während eines dynamischen Tests wird die Software ausgeführt, beispielsweise bei einem Unit-Test. Bei statischen Verfahren wird der Code untersucht. Dazu gehören Code-Reviews, bei denen ein Mensch den Quellcode liest, und Werkzeuge zur statischen Codeanalyse. Genannte Beispiele sind FindBugs und PMD für Java sowie FxCop für .NET. Auch mathematische Verfahren, mit denen sich die Korrektheit von Code beweisen lässt, werden angesprochen. Was Tests nachweisen können Mit Tests findest du Fehler und bestätigst, dass sich die Software in den geprüften Fällen wie erwartet verhält. Eine Aussage über sämtliche denkbaren Fälle würde erschöpfendes Testen voraussetzen. ...

Um Kapitel 9 (Grundlagen der Programmierung) des Handbuchs für Fachinformatiker geht es in der dreiundneunzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Als IT-Azubi findest du in Kapitel 9 des Handbuchs für Fachinformatiker einen Einstieg in grundlegende Programmierkonzepte anhand von C, Java und Python. Für die Prüfung empfehle ich dir besonders die allgemeinen Begriffe, die verschiedenen Arten, Parameter zu übergeben, und die Grundlagen der Objektorientierung. Python führt außerdem an dynamische Typen und Lambda-Ausdrücke heran. Für das tägliche Programmieren brauchst du ergänzende Fachliteratur und praktische Erfahrung. Kapitelmarken [00:00:00] Einstieg in den Buchclub zu Kapitel 9 [00:01:26] C, Java und Python im Überblick [00:03:39] C in der Praxis und in Abschlussprojekten [00:05:53] Prozedurales Programmieren und grundlegende Begriffe [00:07:29] Variablen, Datentypen und Kontrollstrukturen [00:08:49] Pointer, Call-by-Reference und Call-by-Value [00:10:20] Standardbibliotheken und sprachspezifisches Prüfungswissen [00:11:26] Java und das Einordnen von Programmiersprachen [00:12:36] Objektorientierung, Vererbung und Interfaces [00:13:56] Collections, generische Klassen und Enumerations [00:14:51] Python und dynamische Typen [00:15:40] Einrücken und snake_case in Python [00:17:42] Erfahrungen mit anders typisierten Sprachen sammeln [00:18:30] Code mit einer REPL interaktiv ausprobieren [00:19:56] Lambda-Ausdrücke und Funktionen als Parameter [00:22:38] Umfang und Grenzen von Kapitel 9 [00:24:17] Open Books und Fragen zum Fachgespräch [00:25:23] Weiterführende Bücher zu Java und anderen Sprachen [00:27:19] Newsletter und Materialien zur IT-Ausbildung [00:28:11] Fragen von Hörer:innen für Episode 100 Inhalt Kapitel 9 (Grundlagen der Programmierung) Das Kapitel 9 des IT-Handbuchs für Fachinformatiker* von Sascha Kersken liefert einen kurzen Einstieg in mehrere unterschiedliche Programmiersprachen. Für einen tiefen Einstieg reicht das natürlich nicht aus, aber man bekommt einen guten Überblick über die Eigenschaften und Unterschiede der einzelnen Programmiersprachen. Als "Lernkapitel" bietet es sich jedoch nicht an, da viele konkrete Syntaxelemente vorgestellt werden, die für die Praxis absolut relevant sind, aber in der Prüfung so detailliert wohl eher nicht abgefragt werden. 9.1 Die Programmiersprache C Wichtige Programmiersprache! Allerdings (meiner Erfahrung nach) wenig bei IHK-Prüfungen eingesetzt. Die Konzepte der prozeduralen Programmierung finden in den IHK-Aufgaben Anwendung. Gute Erklärung grundlegender Begriffe wie Deklaration, Wertzuweisung und Kontrollstruktur. Kurze Einführung in grundlegende Datentypen wie int, char und double. Einige konkrete Tipps wie z.B. die Empfehlung, bei if immer geschweifte Klammern zu setzen. Schöne Erklärung von Call by value und Call by reference mit Pointern. Die Standardbibliothek ist nicht prüfungsrelevant. 9.2 Java Guter Einstieg mit Liste der Unterschiede zu C. Kurze Einführung in die Objektorientierung mit Überladen, Vererbung und Interfaces. Gut für einen ersten Überblick, aber für Details zu oberflächlich. Abschluss mit kurzer Einführung in Collections und Enums. Wichtig für die Praxis. 9.3 Python (früher 9.3 Perl und 9.4 Ruby) Python ist als bekannter Vertreter der dynamischen (Script-)Sprachen sehr interessant. Die Unterschiede zu statischen Sprachen sollte jeder Prüfling kennen. Auch die Bedeutung von Whitespace in der Sprache ist spannend, da sie sauber formatierten Code erzwingt. Im Gegensatz zu Java wird Snake Case für Bezeichner verwendet. Intensive Behandlung von Listen und den dazu passenden "coolen" Sprachfeatures. Eine REPL bieten heute auch immer mehr Sprachen an. Sogar Java bekommt bald eine :-) Lambda-Funktionen sollte heute auch jeder Anwendungsentwickler kennen. Sie sind in fast allen modernen Programmiersprachen enthalten und bilden ein wichtiges Fundament der funktionalen Programmierung. Die Standardbibliothek ist analog zu C eher uninteressant (für die Prüfung). 9.5 Zusammenfassung Literaturempfehlungen Was sonst? :-) *(direkt beim Rheinwerk-Verlag bestellen*) Und für einen richtigen Einstieg in eine der genannten Sprachen - natürlich Java ;-) - empfehle ich wie immer die "Insel*"! *(direkt beim Rheinwerk-Verlag bestellen*) Wenn du einen wirklich tollen Überblick über einige der interessantesten Programmiersprachen inkl. ihrer konkreten Stärken haben möchtest, kann ich dir Seven Languages in Seven Weeks von Bruce Tate empfehlen, das ich in meinem privaten Blog schon einmal rezensiert habe. * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Anwendungsentwickler-Podcast #12: Häufige Fragen im Fachgespräch - Programmierung (Teil 1) Anwendungsentwickler-Podcast #13: Häufige Fragen im Fachgespräch - Programmierung (Teil 2) Zusammenfassung Kapitel 9 als Einstieg für IT-Azubis Im Buchclub zum Handbuch für Fachinformatiker von Sascha Kersten bespreche ich Kapitel 9 über die Grundlagen der Programmierung. Die neuere Auflage behandelt C, Java und Python in eigenen Unterkapiteln. Python hat die früher enthaltenen Sprachen Perl und Ruby ersetzt, die ebenfalls zu den dynamischen Skriptsprachen gehören. Auf etwa 120 Seiten einschließlich der Übungsaufgaben lernst du verschiedene Programmierkonzepte kennen. Rund 100 Seiten entfallen auf den eigentlichen Inhalt. Für meine IT-Azubis empfehle ich das Kapitel als Einstieg und zum Auffrischen der Grundlagen. Um eine der Sprachen im Arbeitsalltag zu beherrschen, brauchst du weiterführende Literatur. C: Grundbegriffe und prozedurales Programmieren Als IHK-Prüfer habe ich bei meiner IHK bisher kein Abschlussprojekt in C gesehen. In der Praxis spielt die Sprache weiterhin eine Rolle, etwa bei Embedded-Systemen und beim Steuern von Hardware. Meine eigenen Erfahrungen mit C stammen aus dem Studium. Im C-Unterkapitel werden grundlegende Begriffe von Anfang an eingeführt: Syntaxfehler und Laufzeitfehler: Du lernst die beiden Fehlerarten kennen. Variablen: Eine Variable ist ein benannter Speicherplatz. Dazu gehören das Deklarieren einer Variable und das Zuweisen eines Werts. Datentypen: Das Buch beschreibt beispielsweise int und double mit ihren Wertebereichen. Auch char wird eingeführt. Operatoren und Kontrollstrukturen: Du arbeitest mit Verzweigungen wie if oder switch sowie mit Schleifen. Funktionen und Prozeduren: Sie gehören zu den Grundlagen des prozeduralen Programmierens. C zeigt dir, wie ein Programm Arbeitsschritte nacheinander ausführt, anhand einer Bedingung verzweigt oder Schritte wiederholt. Die Begriffe aus diesem Abschnitt helfen dir auch beim Lernen anderer Sprachen und beim Vorbereiten auf die Prüfung. Pointer und Parameter Durch Pointer beschäftigst du dich genauer damit, wie der Computer mit Speicher arbeitet. Sie verlangen Sorgfalt, weil Fehler beim Umgang mit ihnen weitreichende Folgen haben können. Für das Fachgespräch solltest du erklären können, wie Parameter übergeben werden: Bei Call-by-Reference wirkt sich eine Änderung am übergebenen Parameter auch auf die aufrufende Stelle aus. Bei Call-by-Value wird der Wert in eine neue Variable kopiert. Änderungen betreffen diese lokale Kopie. Java: Einstieg in die Objektorientierung Das etwa 20 Seiten lange Java-Unterkapitel beginnt mit der Herkunft der Sprache und ihren Eigenschaften. Java ist objektorientiert sowie statisch und stark typisiert. Für die Prüfung solltest du Programmiersprachen anhand ihrer Eigenschaften einordnen können, etwa anhand ihrer Typen oder ihrer Syntax. Mit Java lernst du erste Grundlagen der Objektorientierung kennen, einschließlich Vererbung und Interfaces. Hinzu kommen Collections und generische Klassen. Auch Enumerations werden vorgestellt. Diese Konzepte begegnen dir in weiteren Programmiersprachen. Für meine IT-Azubis eignet sich dieser Abschnitt als erster Überblick über objektorientiertes Programmieren. Zum Vertiefen von Java empfehle ich dir die Java-Insel von Christian Ullenboom, die selbst über 1.000 Seiten umfasst. Python: Dynamische Typen und Einrücken Mit ungefähr 70 Seiten ist Python das umfangreichste Unterkapitel. Die Sprache ist dynamisch typisiert, sodass eine Variable im Verlauf des Programms Werte verschiedener Typen aufnehmen kann. Wie du den Code einrückst, bestimmt in Python seine Struktur. Dadurch legst du beispielsweise fest, welche Anweisungen zu einer if-Bedingung gehören. Für Variablennamen ist snake_case üblich: Wörter werden kleingeschrieben und durch Unterstriche verbunden. Ich empfehle dir, eine Sprache auszuprobieren, deren Umgang mit Typen sich von deiner Alltagssprache unterscheidet. Diese Erfahrung hilft dir, Eigenschaften von Programmiersprachen einzuschätzen und eine passende Sprache für eine Aufgabe auszuwählen. Code interaktiv ausprobieren Python bringt eine REPL mit. Die Abkürzung steht für Read, Eval, Print, Loop. In dieser interaktiven Shell gibst du Befehle direkt ein und erhältst sofort ein Ergebnis. So kannst du kleine Codeabschnitte testen und erkunden, wie sich Methoden mit bestimmten Parametern verhalten. Lambda-Ausdrücke und Funktionen als Parameter Ein Lambda-Ausdruck beschreibt eine anonyme Funktion mit wenig Code. Du kannst eine solche Funktion als Parameter an eine andere Funktion übergeben. Eine Filterfunktion kann beispielsweise für jedes Listenelement eine übergebene Funktion aufrufen. Liefert diese true, wird das Element in eine neue Liste aufgenommen. Das Kriterium zum Filtern kommt damit von der aufrufenden Stelle. Als weiterführende Themen empfehle ich dir map und reduce sowie das Vertiefen von filter. Das Buch erläutert diese Funktionen im besprochenen Kapitel nicht näher. Lambda-Ausdrücke bieten dafür einen ersten Zugang zu Konzepten des funktionalen Programmierens. Welche Inhalte du für die Prüfung vertiefen solltest Für die sprachunabhängige Prüfung stehen allgemeine Begriffe und Konzepte im Mittelpunkt. Dazu gehören etwa Kontrollstrukturen und das Übergeben von Parametern....

Eine Einführung in die kontinuierliche Integration - Continuous Integration - gibt es in der zweiundneunzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Continuous Integration (CI) führt Codeänderungen regelmäßig zusammen und prüft sie durch automatisierte Builds und Tests. Dafür brauchst du ein vollständiges Projekt in der Versionsverwaltung sowie einen Build, der selbstständig und möglichst schnell durchläuft; als Entwickler:in commitest und pushst du häufig kleine Änderungen. Mit Jenkins oder vergleichbaren Werkzeugen erkennst du Fehler früh, prüfst deinen Code auf einem separaten System und verringerst den Aufwand vor einem Release. Aus meiner Ausbildungspraxis zeige ich dir außerdem, wie du als IT-Azubi schrittweise einen CI-Server aufbauen kannst, auf dem später auch Continuous Delivery oder Continuous Deployment aufsetzen. Kapitelmarken [00:00:00] Einstieg in Continuous Integration [00:01:47] Was Continuous Integration bedeutet [00:04:46] Einfacher Einstieg mit einem automatisierten Build [00:06:35] CI-Werkzeuge und Jenkins [00:10:03] Alle Projektdateien in der Versionsverwaltung [00:10:59] Builds automatisieren und passende Werkzeuge wählen [00:13:39] Schnelle Builds für zeitnahes Feedback [00:14:49] Automatisierte Tests und Legacy Code [00:15:56] Kleine Commits und neue Arbeitsgewohnheiten [00:18:31] Erfolgreiche Builds und verfügbare Softwarestände [00:19:20] Auf einem separaten System bauen [00:21:12] Zeit sparen und Fehler leichter finden [00:22:34] Feedback im Team und Codequalität [00:23:44] Den Projektstatus sichtbar machen [00:24:15] Codekonventionen und typische Fehler prüfen [00:25:40] Testabdeckung und Abhängigkeiten sichtbar machen [00:26:33] Aus Codeprüfungen lernen und Trends verfolgen [00:28:10] Artefakte automatisch im Repository ablegen [00:29:13] Testsysteme automatisch aktualisieren [00:31:06] Branch-Strategien und Feature-Toggles [00:32:27] Continuous Delivery und Continuous Deployment [00:34:28] Einen CI-Server als IT-Azubi schrittweise aufbauen [00:35:09] Aufwendige Abläufe häufiger ausführen und automatisieren [00:36:00] Quellen und Vorträge zum Vertiefen [00:37:14] Buchclubs und Newsletter [00:39:22] Fragen für die 100. Episode [00:40:55] Elenas Projektarbeit als Beispiel [00:42:21] Abschluss und Ausblick Inhalt Voraussetzungen Völlig unabhängig von Programmiersprache oder Plattform. Theoretisch auch ohne separate Software umsetzbar, aber einfacher mit etablierten Lösungen wie Jenkins, Team Foundation Server, Travis CI, Teamcity oder CruiseControl. Alle Artefakte (Code, Oberflächen, Konfiguration usw.) müssen in der Versionsverwaltung liegen. Ein automatischer Build des Projekts muss möglich sein (z.B. mit Gradle oder MS Build). Der Build sollte möglichst schnell sein. Die Funktionalität sollte mit automatischen Tests abgedeckt sein. Entwickler müssen häufig - mindestens täglich - committen. Vorteile Das Projekt ist jederzeit auf dem neusten Stand automatisiert baubar. Vermeidung von "Works on my Machine". Vermeidung langer Integrationsphasen vor Deployments. Erziehung der Entwickler zu kleinen Commits, sauberem Code und automatisierten Tests. Projektbeteiligte bekommen jederzeit kurzfristiges Feedback zum Projektstand. Statische Codeanalyse ist möglich. Einhaltung von Code-Konventionen, z.B. mit Checkstyle. Finden/Verhindern von Bugs, z.B. mit FindBugs. Codeabdeckung durch Tests, z.B. mit JaCoCo. Visualisierung von Abhängigkeiten, z.B. mit JDepend. Trends können erkannt werden. Artefakte können automatisch im Repository abgelegt werden. Automatisches Deployment in eine Testumgebung kann stattfinden. Mögliche Erweiterungen Verschiedene Strategien für die Versionierung möglich, z.B. Feature Branches oder Feature Toggles. CI ist die Basis für Continuous Delivery und Continuous Deployment. Literaturempfehlungen Für Jenkins gibt es inzwischen eine eigene Konferenz, deren Videos größtenteils bei Confreaks verfügbar sind: Jenkins User Conference. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Kontinuierliche Integration – Wikipedia Continuous Integration Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment - Scrum.de CI-Server bei heise Developer Version Control Strategies Zusammenfassung Was Continuous Integration bedeutet Wenn mehrere Entwickler:innen gleichzeitig an einer Software arbeiten, müssen ihre Änderungen zu einem gemeinsamen, lauffähigen Stand zusammenkommen. Continuous Integration (CI) bedeutet, diesen Code regelmäßig zu integrieren, beispielsweise täglich oder mehrfach am Tag. Ein CI-Server holt den aktuellen Stand aus der Versionsverwaltung und führt automatisierte Builds sowie Tests aus. Dadurch erhältst du zeitnah Feedback zu deinen Änderungen. Kleine Schritte erleichtern es, die Ursache eines Fehlers zu finden und den Code wieder lauffähig zu machen. In mündlichen Prüfungen frage ich Prüflinge auch danach, ob sie CI für ihr Projekt eingerichtet haben. Welche Werkzeuge infrage kommen CI lässt sich unabhängig von der Programmiersprache und der Plattform einsetzen. Für einen einfachen Einstieg reicht ein Skript, das nach einem Commit oder Push beziehungsweise nachts den aktuellen Code auscheckt und den Compiler aufruft. Bei einem Fehler kann es eine E-Mail verschicken. Fertige CI-Produkte übernehmen diese Aufgaben und bieten weitere Funktionen. Beispiele sind Jenkins, Team Foundation Server, Travis CI, TeamCity und CruiseControl. Travis CI wird als Werkzeug für auf GitHub gehostete Projekte vorgestellt; Team Foundation Server verbindet im Microsoft-Umfeld die Versionsverwaltung mit CI-Builds. Ich arbeite seit Jahren mit Jenkins und baue damit Java- sowie .NET-Projekte. Obwohl Jenkins selbst in Java geschrieben ist, kann es Projekte in anderen Sprachen bauen. Plugins stellen passende Funktionen bereit. Eigene Bash- oder PowerShell-Skripte lassen sich ebenfalls einbinden. Was dein Projekt mitbringen muss Alle benötigten Dateien liegen in der Versionsverwaltung Damit der CI-Server dein Projekt bauen kann, braucht er Zugriff auf sämtliche dazugehörigen Dateien. Zum Quellcode kommen beispielsweise Konfigurationsdateien und Dateien für die Oberfläche hinzu. Bei Webprojekten gehören auch Grafiken oder Icons dazu. Der Server muss alles aus dem Repository beziehen können. Als Versionsverwaltung kommen etwa Git oder Subversion infrage. Im Podcast werden außerdem CVS und TFS genannt. Der Build läuft selbstständig Jeder erforderliche Schritt muss automatisiert ausführbar sein. Je nach Projekt gehört dazu, den Code zu kompilieren und Tests auszuführen. Weitere Schritte können Webdateien zusammenfassen, Konfigurationsdateien erzeugen oder benötigte Datenbankzustände herstellen. Für viele Plattformen gibt es passende Build-Werkzeuge: Java: Ant, Gradle oder Maven. .NET: MSBuild. Ruby on Rails: Rake. Bei anderen Sprachen kann eigener Aufwand entstehen. Für Natural von der Software AG musste ich den automatisierten Build selbst aufbauen, weil die benötigten Möglichkeiten fehlten. Dazu gehörte, den Compiler aus einem Skript heraus aufrufen zu können. Der Build liefert schnell Feedback Wenn du nach einer Änderung innerhalb weniger Minuten ein Ergebnis bekommst, kannst du direkt darauf reagieren. Sekunden wären noch günstiger. Auch ein nächtlicher Build liefert regelmäßig Hinweise zum Zustand des Projekts. Automatisierte Tests prüfen das Verhalten Der Compiler prüft, ob sich dein Code übersetzen lässt. Automatisierte Tests prüfen, ob er sich bei den getesteten Fällen wie erwartet verhält. Für aussagekräftiges CI-Feedback brauchst du deshalb solche Tests. Bei bestehender Software können sie fehlen. Michael Feathers beschreibt in Working Effectively with Legacy Code Legacy Code als Code ohne automatisierte Tests. Änderungen an solchem Code sind schwer abzusichern. Du commitest und pushst häufig kleine Änderungen Damit der CI-Server früh prüfen kann, solltest du deine Änderungen möglichst kleinteilig und mehrfach täglich ins gemeinsame Repository übertragen. Kleine Commits machen Fehler überschaubar. Dafür müssen Entwickler:innen gegebenenfalls ihre Arbeitsweise ändern. Wenn du CI im Betrieb einführst, gehört auch dazu, diese Gewohnheiten gemeinsam zu verändern. Einen Server einzurichten deckt den technischen Teil ab; das Team muss anschließend regelmäßig mit ihm arbeiten. Was CI im Projekt bringt Ein geprüfter Softwarestand ist verfügbar: Den letzten erfolgreichen Build kannst du beispielsweise für eine Vorabversion oder eine Vorführung verwenden. Abhängigkeiten vom Entwicklungsrechner werden sichtbar: Auf dem separaten CI-System fallen fehlende Bibliotheken oder fest eingetragene lokale Pfade auf. Damit lässt sich prüfen, ob das Projekt außerhalb deines eigenen Rechners gebaut werden kann. Der Aufwand vor Releases sinkt: Häufiges Integrieren verteilt die Arbeit auf kleine Schritte und spart Zeit, die sonst kurz vor der Auslieferung für umfangreiche Merges anfällt. Fehler lassen sich leichter zuordnen: Bei wenigen kleinen Änderungen kannst du schneller erkennen, welcher Code den Build beschädigt hat. Der Projektstatus ist sichtbar: In Jenkins können Entwickler:innen und Vorgesetzte sehen, ob ein Build erfolgreich war. E-Mails informieren über Fehler und die zuletzt eingegangenen Commits. Aus meiner Praxis kenne ich auch den sozialen Effekt solcher Meldungen: Wenn ein beschädigter Build im Team sichtbar wird, kümmern sich Entwickler:innen zeitnah darum. Das fördert sorgfältiges Arbeiten und automatisierte Tests. Code automatisch prüfen und daraus lernen Zusätzliche Werkzeuge lassen sich bei jedem Build ausführen. Gerade als IT-Azubi bekommst du dadurch konkrete Hinweise zu deinem Code: | Werkzeug | Was es prüft oder sichtbar macht | | --- | --- | | Checkstyle | Codekonventionen, etwa Zeilenlängen und Namen von Variablen | | FindBugs oder PMD | Auffällige Codestellen, beispielsweise offene Ressourcen oder leere Catch-Blöcke | | JaCoCo | Welche Teile des Produktivcodes durch Unit-Tests ausgefüh