IT-Berufe-Podcast

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

Die nächsten Schritte zum Einrichten deines eigenen Linux-Servers sind das Thema der einundneunzigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit einer Firewall nach dem Whitelist-Prinzip gibst du auf deinem Linux-Server gezielt die benötigten Verbindungen frei und schützt deine Dienste mit sicheren Passwörtern. Ich passe außerdem die .bashrc und Vim an, damit ich auf der Kommandozeile schneller arbeiten kann und beim Löschen von Dateien eine Rückfrage bekomme. Automatische, verschlüsselte Backups mit getestetem Restore sichern deine Arbeit ab, während ein externes Monitoring dich über ausgefallene Dienste informiert.

Kapitelmarken

[00:00:00] Einstieg und Abschluss der Linux-Server-Reihe

[00:01:18] Automatische Debian-Updates mit Unattended Upgrades

[00:01:54] Konfigurationen mit etckeeper und Git sichern

[00:03:27] Die Firewall einrichten

[00:04:54] Whitelisting und Blacklisting

[00:06:46] iptables, Chains und Shell-Skripte

[00:09:25] Sichere Passwörter für deine Dienste

[00:11:11] Die .bashrc und versteckte Dateien

[00:13:20] Home-Verzeichnis und Start der Bash

[00:14:49] Aliase für häufige Befehle

[00:16:38] Rückfragen beim Löschen mit rm

[00:19:45] Farbige Ausgabe auf der Kommandozeile

[00:20:26] History vergrößern und Befehle suchen

[00:22:08] History mehrerer Shells zusammenführen

[00:23:02] Den Prompt konfigurieren

[00:24:16] Dotfiles als Beispiele für eigene Einstellungen

[00:24:55] Vim konfigurieren und Literaturempfehlung

[00:26:40] Syntax-Highlighting, Zeilennummern und Suche

[00:28:11] Vim-Navigation ohne Pfeiltasten üben

[00:29:45] Regelmäßige Backups automatisieren

[00:32:03] Backups vor dem Übertragen verschlüsseln

[00:33:00] Das Restore frühzeitig testen

[00:34:40] Dienste mit externem Monitoring überwachen

[00:35:19] Ausfallmeldungen an ein unabhängiges Postfach schicken

[00:37:32] Rückblick auf die Schritte beim Einrichten

[00:38:35] Mit einem eigenen Server praktische Erfahrung sammeln

[00:40:36] Weiterführende Links und Bücher

[00:41:42] Newsletter und Checklisten zur Abschlussprüfung

[00:42:38] Feedback zur praxisbezogenen Server-Reihe

Inhalt

Firewall einrichten (iptables)

erstmal alles blockieren, was nicht explizit benötigt wird

nur Ports öffnen, die wirklich benötigt werden (SSH, HTTP, IMAP usw.)

sichere Passwörter für alle Dienste vergeben (z.B. MySQL)

.bashrc optimieren

hilfreiche Aliase definieren (z.B. l anstatt ls -la)

gefährliche Befehle entschärfen (z.B. rm)

farbige Ausgabe aktivieren

History-Größe erhöhen

Kommandos mehrerer Shells mergen

Prompt konfigurieren (z.B. Hostnamen und User anzeigen)

Vim konfigurieren

farbige Ausgabe und Syntax Highlighting

Pfeiltasten ausschalten (um Vim wirklich zu lernen)

Zeilennummern aktivieren

case-insensitive Suche aktivieren

Backup einrichten

Monitoring einrichten

Literaturempfehlungen

Wenn du nur einen einzigen Texteditor beherrschen dürftest, sollte es Vim sein :-) Mit Drew Neils Buch wirst du zum Profi bei der Bedienung des besten Editors der Welt.

*

Und wie schon in allen Linux-Episoden ist die "Linux-Bibel" von Michael Kofler* mein Literaturtipp zur Vertiefung deiner Linux-Kenntnisse.

*(direkt beim Rheinwerk-Verlag bestellen*)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

vServer bei 1blu*

Nachtrag zu den letzten Episoden (Danke an Robin!)

UnattendedUpgrades - Debian Wiki

joeyh/etckeeper bei Github

Linux: 20 Iptables Examples For New SysAdmins

Linux Iptables Setup Firewall For a Web Server

Why are filenames that start with a dot hidden?

30 Handy Bash Shell Aliases For Linux / Unix / Mac OS X

Bash Tips and Tricks

Linux Bash – Shortcuts To Boost Your Productivity

/bin/bash - Grundlegende Kommandos

Blog von Jonas Hellmann (mein Azubi)

Zusammenfassung

Updates automatisch einspielen und Konfigurationen sichern

Mit Unattended Upgrades kannst du Debian-Updates nachts automatisch installieren lassen. Falls ein Neustart erforderlich ist, lässt sich auch dieser automatisieren.

Für das Verzeichnis /etc empfehle ich Git, damit du vor Experimenten oder Änderungen einen funktionierenden Stand festhalten und später wiederherstellen kannst. etckeeper erleichtert das. Achte dabei auf sensible Dateien wie /etc/shadow, weil über das Repository zusätzliche Zugriffe auf deren Inhalte möglich werden. Ich schließe bestimmte Dateien über .gitignore aus.

Die Firewall einrichten

Eine Firewall blockiert unerwünschte Zugriffe über das Netzwerk. Richte sie so ein, dass zunächst alle Verbindungen gesperrt sind und du anschließend die benötigten Dienste gezielt freigibst. Welche Ports du öffnest, hängt davon ab, was du auf deinem Server betreibst, etwa einen Webserver oder einen Mailserver.

Dabei gehören zwei Begriffe zum Prüfungswissen:

Whitelisting: Du führst die erlaubten Ports oder Verbindungen auf. Alles außerhalb dieser Liste bleibt gesperrt.

Blacklisting: Du führst die Ports oder Verbindungen auf, die gesperrt werden sollen.

Für meinen Server wähle ich das Whitelist-Prinzip. Dadurch bleiben auch Ports gesperrt, die ein zusätzlich installiertes Programm öffnet. Wenn du einen neuen Dienst betreiben möchtest, ergänzt du die passende Freigabe.

Unter Linux arbeite ich mit iptables. Die Regeln lassen sich in Shell-Skripten hinterlegen, sodass du die Firewall per Kommandozeile steuern kannst. Sorge dafür, dass sie beim Hochfahren automatisch startet.

iptables arbeitet mit sogenannten Chains. Für den beschriebenen Einstieg auf einem V-Server stehen INPUT und OUTPUT im Vordergrund. FORWARD gehört ebenfalls zu den Chains; beim Betrieb eigener virtueller Maschinen kann zusätzlich Network Address Translation, kurz NAT, relevant werden. Anleitungen und Beispiele zur Konfiguration findest du in meinen Shownotes sowie im Linux-Handbuch von Michael Kofler.

Sichere Passwörter vergeben

Schütze deine Dienste mit sicheren Passwörtern, auch wenn sie ausschließlich intern erreichbar sind. Das betrifft beispielsweise eine Datenbank oder einen FTP-Server. Beim zuvor eingerichteten SSH-Zugang kommt bereits ein Public Key zum Einsatz.

Ersetze voreingestellte oder leere Passwörter direkt nach dem Einrichten durch sichere Kennwörter. Angreifer:innen probieren bekannte Standardzugänge gezielt aus, deren Passwörter sich in öffentlich zugänglichen Listen finden. Ich verwalte meine Passwörter in einem Passwort-Safe.

Die Bash über .bashrc anpassen

Die Datei .bashrc liegt in deinem Home-Verzeichnis und enthält Einstellungen sowie Befehle für die Bash. Dort kannst du festlegen, was beim Start einer Shell ausgeführt werden soll.

Dateien, deren Name mit einem Punkt beginnt, gelten unter Linux als versteckt. Diese Konvention entstand dadurch, dass beim Auflisten ursprünglich die Verzeichniseinträge . und .. ausgeblendet werden sollten. Die damalige Regel erfasste sämtliche Namen mit einem Punkt am Anfang.

Für die Arbeit mit Verzeichnissen helfen dir diese Schreibweisen:

. bezeichnet das aktuelle Verzeichnis.

.. bezeichnet das übergeordnete Verzeichnis.

~ steht für dein Home-Verzeichnis, das gewöhnlich unter /home/deinbenutzername liegt.

Mit cd ~ oder einfach cd wechselst du in der Bash in dein Home-Verzeichnis.

Häufige Befehle abkürzen

Ein Alias ersetzt einen längeren Befehl durch einen kurzen Namen. Ich lege beispielsweise l für ls -la an. Damit sehe ich den Verzeichnisinhalt einschließlich versteckter Dateien und zusätzlicher Angaben, etwa der Dateirechte.

Bei rm empfiehlt sich gerade zum Einstieg ein Alias, der rm -i aufruft. Dadurch fragt der Befehl vor dem Löschen nach. Tippfehler oder versehentlich eingefügte Leerzeichen können beim Löschen mehrere Dateien erfassen. Mit rekursiven Löschbefehlen und Root-Rechten können große Teile des Dateisystems betroffen sein. Was du mit rm entfernst, landet direkt außerhalb eines Papierkorbs und lässt sich entsprechend schwer zurückholen.

Farben und History einstellen

Eine farbige Ausgabe von ls hilft dir, Verzeichnisse und ausführbare Dateien schneller zu erkennen.

Die Bash merkt sich eingegebene Befehle in ihrer History. Mit der Pfeiltaste nach oben rufst du frühere Befehle auf; über Strg+R suchst du nach einer enthaltenen Zeichenfolge. Ich erhöhe die History-Größe beispielsweise auf 100.000 Einträge, damit ältere Befehle länger verfügbar bleiben.

Wenn du mehrere Shells parallel geöffnet hast, kannst du ihre Befehle gemeinsam in der History speichern lassen. Die passende Einstellung in der .bashrc verhindert, dass eine zuletzt geschlossene Sitzung die Einträge anderer Sitzungen überschreibt. Dazu habe ich eine Anleitung verlinkt.

Nach einem Angriff kann die History Hinweise auf ausgeführte Befehle enthalten, sofern die Angreifer:innen sie erhalten haben. Da sie in einer Datei liegt, lässt sie sich auch verändern oder löschen.

Den Prompt anpassen

Der Prompt ist der Text vor deinem Cursor. Ich lasse dort meinen Kontonamen mit dem Servernamen anzeigen und ergänze das aktuelle Verzeichnis. Das erleichtert die Orientierung, wenn ich mit mehreren Shells arbeite oder zwischen Root und einem regulären Konto wechsle.

Mit pwd kannst du dein aktuelles Verzeichnis anzeigen lassen. whoami zeigt dir, unter welchem Konto du gerade arbeitest. Beispiele für persönliche Konfigurationsdateien findest du auf GitHub unter dem Stichwort Dotfiles.

Vim einstellen

Wenn du mit Vim arbeitest, kannst du über seine Konfigurationsdateien das Verhalten anpassen. Je nach Distribution liegt die systemweite Datei beispielsweise unter /etc/vim/vimrc; persönliche Einstellungen sind auch über .vimrc im Home-Verzeichnis möglich.

Diese Einstellungen gehören zu meinen Empfehlungen:

Aktiviere Syntax-Highlighting, damit Vim Bestandteile einer Datei farbig hervorhebt.

Blende Zeilennummern ein, um Stellen aus Fehlermeldungen leichter zu finden.

Stelle die Suche so ein, dass sie Groß- und Kleinschreibung ignoriert.

Ich habe außerdem die Pfeiltasten auf No-Op gesetzt, sodass sie den Cursor unverändert lassen. Damit gewöhne ich mir die Navigation über h, j, k und l an, bei der meine rechte Hand auf der Grundreihe der Tastatur b