Aufgaben Toolchain

IHK-Aufgaben Toolchain

Punkte: 0 / 28

Aufgaben: 0 / 10

Richtig: 0 · Falsch: 0

Zehn IHK-Aufgaben durch den gesamten Kurs: IDEs, Build-Tools, Paketmanager, Bibliotheken, Code lesen, Linter, Vorgehensmodelle, Doku, SonarQube. Mix aus MC, Mehrfachauswahl, Zuordnung, Reihenfolge und einer offenen Aufgabe. Live-Auswertung oben, am Ende eine Note.

Aufgabe 12 Punkte

Editor vs. IDE

Welche Aussage zum Unterschied zwischen Editor und IDE ist korrekt?

Editoren sind grundsätzlich schneller als IDEs und haben mehr Features.

Eine IDE umfasst zusätzlich zum Editor Compiler-Anbindung, Debugger, Build-Tools und Refactoring – ein Editor primär nur Textbearbeitung.

IDEs sind kostenlos, Editoren immer kostenpflichtig.

VS Code ist eine reine Text-Editor-Anwendung ohne Plugin-Unterstützung.

Richtig. Eine IDE integriert Compiler, Debugger, Build-Tools, Refactoring, Versionskontrolle in einer Oberfläche. Ein Editor ist primär für Textbearbeitung. VS Code ist eine spannende Zwischenform: technisch Editor, durch Plugins aber IDE-mächtig. Vgl. L1.

Aufgabe 23 Punkte

Maven-Lifecycle ordnen

Bring die Maven-Lifecycle-Phasen in die richtige Reihenfolge (Default-Lifecycle):

Korrekte Reihenfolge: 1. validate → 2. compile → 3. test → 4. package → 5. verify → 6. install → 7. deploy. clean gehört zu einem eigenen Lifecycle. Vgl. L2.

Aufgabe 33 Punkte

Paketmanager und Konfigdatei

Ordne jeden Paketmanager seinem Ökosystem und seiner Konfigurationsdatei zu. Klick zuerst einen Paketmanager unten, dann sein passendes Ziel:

pip → requirements.txt

npm → package.json

Maven → pom.xml

Gradle → build.gradle

Java-Projekte mit XML-basierter Konfiguration

JavaScript/TypeScript-Pakete aus der npmjs.com-Registry

Python-Pakete aus dem Python Package Index (PyPI)

Java/Kotlin-Builds mit Groovy/Kotlin-DSL und inkrementellen Builds

Auswertung: Maven → pom.xml (XML). Gradle → build.gradle (Groovy-DSL). npm → package.json (JSON). pip → requirements.txt (oder pyproject.toml). Vgl. L3.

Aufgabe 42 Punkte

SemVer-Specifier

In package.json steht "express": "^4.18.0". Welche Versionen sind dadurch erlaubt?

Nur exakt 4.18.0.

Alle Versionen von 4.18.0 bis 4.18.99 (nur PATCH-Updates).

Alle Versionen von 4.18.0 bis < 5.0.0 (MINOR + PATCH-Updates erlaubt).

Alle Versionen ab 4.18.0 aufwärts, auch 5.x und 6.x.

Richtig. Caret ^ erlaubt MINOR und PATCH-Updates: alle Versionen von 4.18.0 bis < 5.0.0. Im Gegensatz dazu erlaubt Tilde ~4.18.0 nur PATCH-Updates (bis < 4.19.0). Vgl. L3.

Eselsbrücke: ^ = bis nächstes MAJOR. ~ = bis nächstes MINOR.

Aufgabe 52 Punkte

Lizenzwahl für kommerzielles Produkt

Welche Open-Source-Lizenzen sind unproblematisch für ein proprietäres kommerzielles Produkt? Wähle alle zutreffenden:

✓MIT

✓Apache 2.0

✓BSD-3-Clause

✓GPL v3

✓AGPL

✓Public Domain / CC0

Richtig sind 4 Lizenzen: MIT, Apache 2.0, BSD-3-Clause und Public Domain – alle erlauben kommerzielle Nutzung ohne Copyleft. GPL und AGPL sind Copyleft-Lizenzen: dein eigenes Produkt müsste auch unter GPL stehen. Bei AGPL gilt das sogar bei Web-Services. Vgl. L4.

Aufgabe 63 Punkte

Code-Smells erkennen

Welche Aussage über Code-Smells ist korrekt?

Code-Smells sind syntaktische Fehler, die den Compiler stören.

Code-Smells sind Hinweise auf potenziell problematische Stellen (Long Method, God Class, Magic Numbers) – nicht zwingend falsch, aber meist verbesserungswürdig.

Code-Smells müssen vor Release komplett entfernt werden, sonst läuft der Build nicht.

Eine 500-Zeilen-Methode ist per se ein Bug, nie ein Smell.

Richtig. Code-Smells sind Indikatoren für problematische Stellen, keine harten Bugs. Long Method, God Class, Magic Numbers, Duplikate, Shotgun Surgery sind klassische Beispiele. Sie zeigen Refactoring-Bedarf, brechen aber den Code nicht. Vgl. L5.

Aufgabe 72 Punkte

Linter vs. Formatter

Welche Tools sind Formatter, welche Linter? Wähle alle zutreffenden Formatter:

✓Prettier (JS/TS)

✓Black (Python)

✓ESLint (JS/TS)

✓Pylint (Python)

✓SpotBugs (Java)

✓Spotless / Google Java Format (Java)

Formatter: Prettier, Black, Spotless/Google Java Format – ändern die Optik (Einrückung, Zeilenumbrüche). Linter: ESLint, Pylint, SpotBugs – finden Probleme (Bugs, unsauberer Stil). Vgl. L6.

Aufgabe 83 Punkte

Scrum-Begriffe zuordnen

Ordne jeden Scrum-Begriff der richtigen Kategorie zu:

Rolle

Event

Artefakt

Product Owner

Sprint Review

Product Backlog

Scrum Master

Daily Scrum

Increment

Auswertung: Rollen: Product Owner, Scrum Master, Entwicklerteam. Events: Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective. Artefakte: Product Backlog, Sprint Backlog, Increment. Vgl. L7.

Aufgabe 93 Punkte

Code-Dokumentation: Sprache zuordnen

Welches Doku-Format wird für welche Sprache eingesetzt? Klick zuerst ein Format, dann den passenden Einsatz:

JavaDoc

JSDoc

Docstring

OpenAPI/Swagger

Java-Methoden mit /** ... */-Kommentaren über der Signatur

Python-Funktionen mit Triple-Quote-String direkt unter def

REST-APIs mit YAML/JSON-Spec für Endpunkte und Schemas

JavaScript/TypeScript-Funktionen mit /** @param ... */

Auswertung: JavaDoc (Java), JSDoc (JS/TS), Docstring (Python), OpenAPI/Swagger (REST-APIs sprach-unabhängig). Vgl. L8.

Aufgabe 105 Punkte

Toolchain für ein neues Projekt

Beschreibe in 4-6 Sätzen die Toolchain für ein neues Java/Spring-Backend-Projekt: welche IDE, welches Build-Tool, welches Test-Framework, welche Linter, welches Versionsverwaltungssystem? Wie sicherst du Code-Qualität bei jedem Commit?

Das System prüft, ob die wichtigsten Stichworte vorkommen:

Mögliche Musterlösung: Als IDE nutze ich IntelliJ IDEA (Standard für Java). Build-Tool ist Maven (oder Gradle) mit pom.xml für Dependencies. Tests mit JUnit 5. Code-Qualität: Checkstyle und SpotBugs als Linter, Spotless als Formatter. Versionsverwaltung über Git mit Pre-Commit-Hook (Husky/pre-commit) für automatische Linter-Läufe. Im CI/CD (GitHub Actions) laufen Build, Tests und SonarQube-Analyse bei jedem Push. Vgl. L1-L9.

📊 Auswertung

Punkte

Prozent

Note

–

Aufgaben gelöst

0/10

Verwandte Lektionen zum Wiederholen: L2 Build-Tools · L3 Paketmanager · L6 Linter · L7 Scrum · L9 SonarQube

Nächste Kurse: K54 Git als praktische Ergänzung. K52 Testen wird in Build-Pipelines integriert. K11 Secure Coding ergänzt SonarQube um Sicherheitsfokus.