Spaces:
Running
Running
| title: Softwareentwicklung | |
| emoji: 💻 | |
| colorFrom: blue | |
| colorTo: indigo | |
| sdk: static | |
| pinned: false | |
| short_description: Softwareentwicklung, Architektur, DevOps und AI Coding. | |
| # Softwareentwicklung | |
| **Die deutschsprachige Referenz zu Softwareentwicklung, Softwarearchitektur, Programmierung, APIs, Testing, DevOps, Cloud-Native Development, Secure Coding und AI-gestützter Softwareentwicklung.** | |
| Softwareentwicklung ist der strukturierte Prozess, mit dem **Software geplant, entworfen, programmiert, getestet, bereitgestellt, betrieben und kontinuierlich verbessert** wird. | |
| Sie reicht weit über das Schreiben von Code hinaus. | |
| Moderne Softwareentwicklung verbindet: | |
| - **Anforderungsanalyse** | |
| - **Softwarearchitektur** | |
| - **Programmierung** | |
| - **Versionskontrolle** | |
| - **Testing** | |
| - **Code Review** | |
| - **APIs** | |
| - **Datenbanken** | |
| - **Cloud** | |
| - **Container** | |
| - **CI/CD** | |
| - **DevOps** | |
| - **Observability** | |
| - **Security** | |
| - **Automatisierung** | |
| - **KI-gestützte Entwicklung** | |
| - **Coding Agents** | |
| - **Agentic Software Engineering** | |
| Diese Hugging-Face-Organisation bündelt deutschsprachige technische Ressourcen zu: | |
| - **Softwareentwicklung** | |
| - **Software Engineering** | |
| - **Programmierung** | |
| - **Softwarearchitektur** | |
| - **Clean Code** | |
| - **Design Patterns** | |
| - **APIs** | |
| - **Backend Development** | |
| - **Frontend Development** | |
| - **Full-Stack Development** | |
| - **Mobile Development** | |
| - **Cloud-Native Development** | |
| - **DevOps** | |
| - **CI/CD** | |
| - **Testing** | |
| - **Secure Coding** | |
| - **Code Review** | |
| - **MLOps** | |
| - **AI Coding** | |
| - **Coding Agents** | |
| - **Agentic Software Engineering** | |
| Ziel ist eine verständliche, technisch belastbare und praxisnahe Referenz mit **Erklärungen, Architekturmustern, Engineering-Prinzipien, interaktiven Spaces, Benchmarks, Datasets und weiterführenden Ressourcen**. | |
| > **Kurzdefinition:** Softwareentwicklung ist der systematische Prozess, Anforderungen in zuverlässige, wartbare und nutzbare Software zu übersetzen. | |
| --- | |
| # Was ist Softwareentwicklung? | |
| Softwareentwicklung umfasst alle Schritte, die nötig sind, um digitale Anwendungen und Systeme zu erstellen. | |
| Dazu gehören beispielsweise: | |
| - Webanwendungen, | |
| - mobile Apps, | |
| - Unternehmenssoftware, | |
| - APIs, | |
| - Datenplattformen, | |
| - Embedded Systems, | |
| - Cloud Services, | |
| - KI-Anwendungen, | |
| - Agentensysteme. | |
| Der sichtbare Programmcode ist nur ein Teil davon. | |
| Eine professionelle Softwareentwicklung beantwortet zusätzlich Fragen wie: | |
| - Welches Problem soll gelöst werden? | |
| - Welche Anforderungen gelten? | |
| - Wie soll die Architektur aussehen? | |
| - Wie wird Qualität sichergestellt? | |
| - Wie wird Software getestet? | |
| - Wie wird sie sicher betrieben? | |
| - Wie werden Änderungen kontrolliert? | |
| - Wie wird sie langfristig gewartet? | |
| --- | |
| # Softwareentwicklung einfach erklärt | |
| Ein einfaches Beispiel: | |
| Ein Unternehmen möchte eine Anwendung zur Verwaltung von Kundenanfragen bauen. | |
| Die Softwareentwicklung könnte folgende Schritte umfassen: | |
| 1. Anforderungen sammeln. | |
| 2. Nutzer und Rollen definieren. | |
| 3. Datenmodell entwerfen. | |
| 4. technische Architektur auswählen. | |
| 5. Benutzeroberfläche entwickeln. | |
| 6. Backend implementieren. | |
| 7. Datenbank anbinden. | |
| 8. Tests erstellen. | |
| 9. Anwendung bereitstellen. | |
| 10. Monitoring und Wartung einrichten. | |
| Das Ergebnis ist nicht nur Code. | |
| Es ist ein **betriebsfähiges Softwaresystem**. | |
| --- | |
| # Warum ist Softwareentwicklung wichtig? | |
| Nahezu alle digitalen Produkte und Geschäftsprozesse basieren auf Software. | |
| Software steuert heute unter anderem: | |
| - Kommunikation, | |
| - Handel, | |
| - Produktion, | |
| - Logistik, | |
| - Forschung, | |
| - Finanzen, | |
| - Verwaltung, | |
| - Mobilität, | |
| - künstliche Intelligenz. | |
| Gute Softwareentwicklung sorgt dafür, dass Systeme: | |
| - zuverlässig, | |
| - sicher, | |
| - wartbar, | |
| - skalierbar, | |
| - verständlich | |
| bleiben. | |
| Schlechte Softwareentwicklung führt dagegen häufig zu: | |
| - technischen Schulden, | |
| - Sicherheitsproblemen, | |
| - hohen Wartungskosten, | |
| - langsamen Änderungen, | |
| - instabilen Systemen. | |
| --- | |
| # Software Engineering vs. Programmierung | |
| Die Begriffe werden häufig gleichgesetzt, sind aber unterschiedlich. | |
| ## Programmierung | |
| Programmierung bedeutet, Code zu schreiben. | |
| ## Software Engineering | |
| Software Engineering umfasst zusätzlich: | |
| - Planung, | |
| - Architektur, | |
| - Prozesse, | |
| - Testing, | |
| - Qualität, | |
| - Betrieb, | |
| - Wartung. | |
| Vereinfacht: | |
| **Programmierung erzeugt Code.** | |
| **Software Engineering erzeugt nachhaltige Softwaresysteme.** | |
| --- | |
| # Software Development Lifecycle | |
| Der Software Development Lifecycle, kurz **SDLC**, beschreibt den Lebenszyklus einer Software. | |
| Ein typischer Ablauf: | |
| **Planung → Analyse → Design → Entwicklung → Test → Deployment → Betrieb → Verbesserung** | |
| Dieser Ablauf muss nicht streng linear sein. | |
| Moderne Teams arbeiten meist iterativ. | |
| --- | |
| # Anforderungen | |
| Softwareentwicklung beginnt mit Anforderungen. | |
| Anforderungen beschreiben: | |
| - was ein System tun soll, | |
| - für wen, | |
| - unter welchen Bedingungen. | |
| Man unterscheidet häufig: | |
| ## Funktionale Anforderungen | |
| Was soll das System tun? | |
| Beispiele: | |
| - Nutzer anmelden, | |
| - Bestellung speichern, | |
| - Bericht erzeugen. | |
| ## Nichtfunktionale Anforderungen | |
| Wie gut soll das System etwas tun? | |
| Beispiele: | |
| - Antwortzeit, | |
| - Verfügbarkeit, | |
| - Sicherheit, | |
| - Skalierbarkeit. | |
| --- | |
| # User Stories | |
| Agile Teams formulieren Anforderungen häufig als User Stories. | |
| Beispiel: | |
| > Als Nutzer möchte ich meine Bestellung sehen, damit ich den aktuellen Status prüfen kann. | |
| Eine gute User Story beschreibt: | |
| - Rolle, | |
| - Ziel, | |
| - Nutzen. | |
| --- | |
| # Akzeptanzkriterien | |
| Akzeptanzkriterien definieren, wann eine Funktion als erfüllt gilt. | |
| Beispiel: | |
| - Nutzer kann sich anmelden. | |
| - Falsches Passwort wird abgelehnt. | |
| - Erfolgreiche Anmeldung führt zum Dashboard. | |
| Akzeptanzkriterien helfen bei Entwicklung und Testing. | |
| --- | |
| # Softwarearchitektur | |
| Softwarearchitektur beschreibt die grundlegende Struktur eines Systems. | |
| Sie definiert unter anderem: | |
| - Komponenten, | |
| - Verantwortlichkeiten, | |
| - Schnittstellen, | |
| - Datenflüsse, | |
| - Abhängigkeiten. | |
| Gute Architektur erleichtert: | |
| - Wartung, | |
| - Erweiterung, | |
| - Skalierung, | |
| - Testing, | |
| - Security. | |
| --- | |
| # Monolith | |
| Ein Monolith bündelt viele Funktionen in einer gemeinsamen Anwendung. | |
| Vorteile: | |
| - einfache Entwicklung, | |
| - einfacher Deployment-Prozess, | |
| - geringe verteilte Komplexität. | |
| Nachteile können bei sehr großen Systemen entstehen: | |
| - gekoppelte Releases, | |
| - schwierige Skalierung einzelner Teile, | |
| - größere Codebasis. | |
| Monolithen sind nicht automatisch schlecht. | |
| Ein gut strukturierter Monolith kann für viele Projekte die beste Lösung sein. | |
| --- | |
| # Modularer Monolith | |
| Ein modularer Monolith organisiert eine Anwendung intern in klar getrennte Module. | |
| Ziele: | |
| - geringe Kopplung, | |
| - klare Verantwortlichkeiten, | |
| - einfache Deployment-Struktur. | |
| Er kann ein guter Mittelweg zwischen klassischem Monolith und Microservices sein. | |
| --- | |
| # Microservices | |
| Microservices teilen ein System in kleinere unabhängige Services. | |
| Vorteile: | |
| - unabhängige Deployments, | |
| - gezielte Skalierung, | |
| - klare Verantwortlichkeiten. | |
| Nachteile: | |
| - verteilte Kommunikation, | |
| - komplexeres Monitoring, | |
| - Datenkonsistenz, | |
| - Netzwerkfehler, | |
| - höherer Betriebsaufwand. | |
| Microservices sollten nicht nur aus Modegründen eingesetzt werden. | |
| --- | |
| # Event-Driven Architecture | |
| Event-Driven Architecture nutzt Ereignisse zur Kommunikation. | |
| Beispiel: | |
| **OrderCreated** | |
| Andere Systeme können auf dieses Event reagieren. | |
| Vorteile: | |
| - lose Kopplung, | |
| - Skalierbarkeit, | |
| - asynchrone Verarbeitung. | |
| Herausforderungen: | |
| - Eventual Consistency, | |
| - Debugging, | |
| - Versionierung, | |
| - Fehlerbehandlung. | |
| --- | |
| # Client-Server-Architektur | |
| Viele Anwendungen bestehen aus: | |
| - Client, | |
| - Server. | |
| Der Client kann sein: | |
| - Webbrowser, | |
| - Mobile App, | |
| - Desktop App. | |
| Der Server verarbeitet: | |
| - Geschäftslogik, | |
| - Daten, | |
| - Authentifizierung, | |
| - APIs. | |
| --- | |
| # Frontend Development | |
| Frontend Development beschäftigt sich mit der Benutzeroberfläche. | |
| Typische Technologien: | |
| - HTML, | |
| - CSS, | |
| - JavaScript, | |
| - TypeScript. | |
| Frameworks und Libraries können sein: | |
| - React, | |
| - Vue, | |
| - Angular, | |
| - Svelte. | |
| Frontend-Entwicklung umfasst mehr als Design. | |
| Wichtige Themen: | |
| - Accessibility, | |
| - Performance, | |
| - State Management, | |
| - Security, | |
| - Testing. | |
| --- | |
| # Backend Development | |
| Backend Development verarbeitet die serverseitige Logik. | |
| Typische Aufgaben: | |
| - APIs, | |
| - Datenbanken, | |
| - Authentifizierung, | |
| - Geschäftslogik, | |
| - Integrationen, | |
| - Hintergrundjobs. | |
| Sprachen können sein: | |
| - Java, | |
| - Python, | |
| - C#, | |
| - Go, | |
| - JavaScript/TypeScript, | |
| - Rust. | |
| --- | |
| # Full-Stack Development | |
| Full-Stack Development verbindet Frontend und Backend. | |
| Ein Full-Stack-Entwickler arbeitet typischerweise an: | |
| - Benutzeroberfläche, | |
| - APIs, | |
| - Datenbank, | |
| - Deployment. | |
| Der Begriff bedeutet nicht, dass eine Person jede Technologie perfekt beherrschen muss. | |
| --- | |
| # Mobile Development | |
| Mobile Development entwickelt Anwendungen für Smartphones und Tablets. | |
| Ansätze: | |
| - native Apps, | |
| - Cross-Platform Apps, | |
| - Progressive Web Apps. | |
| Wichtige Themen: | |
| - Performance, | |
| - Offline-Fähigkeit, | |
| - Geräteberechtigungen, | |
| - Security, | |
| - App Stores. | |
| --- | |
| # Desktop Development | |
| Desktop-Anwendungen laufen lokal auf Betriebssystemen. | |
| Beispiele: | |
| - Windows, | |
| - macOS, | |
| - Linux. | |
| Technologien: | |
| - .NET, | |
| - Electron, | |
| - Qt, | |
| - native Frameworks. | |
| --- | |
| # Embedded Software | |
| Embedded Software läuft auf spezialisierten Geräten. | |
| Beispiele: | |
| - Maschinen, | |
| - Fahrzeuge, | |
| - Sensoren, | |
| - IoT-Geräte. | |
| Hier sind oft wichtig: | |
| - Echtzeit, | |
| - Speicherbegrenzung, | |
| - Energieverbrauch, | |
| - Hardwarezugriff, | |
| - Sicherheit. | |
| --- | |
| # Programmiersprachen | |
| Programmiersprachen sind Werkzeuge. | |
| Die Wahl hängt ab von: | |
| - Plattform, | |
| - Performance, | |
| - Teamwissen, | |
| - Bibliotheken, | |
| - Wartbarkeit, | |
| - Ökosystem. | |
| Es gibt keine universell beste Sprache. | |
| --- | |
| # Python | |
| Python ist besonders verbreitet in: | |
| - Data Science, | |
| - Machine Learning, | |
| - Automation, | |
| - Backend Development, | |
| - Scripting. | |
| Vorteile: | |
| - leicht lesbar, | |
| - großes Ökosystem. | |
| --- | |
| # JavaScript und TypeScript | |
| JavaScript ist zentral für Webentwicklung. | |
| TypeScript ergänzt statische Typisierung. | |
| Sie werden eingesetzt in: | |
| - Frontend, | |
| - Backend, | |
| - Full-Stack-Systemen. | |
| --- | |
| # Java | |
| Java ist stark in: | |
| - Enterprise Software, | |
| - Backend, | |
| - großen Plattformen. | |
| Vorteile: | |
| - stabiles Ökosystem, | |
| - gute Tooling-Unterstützung, | |
| - Plattformunabhängigkeit. | |
| --- | |
| # C# | |
| C# wird häufig genutzt für: | |
| - .NET-Anwendungen, | |
| - Backend, | |
| - Desktop, | |
| - Games. | |
| --- | |
| # Go | |
| Go eignet sich gut für: | |
| - Cloud Services, | |
| - Netzwerksoftware, | |
| - Infrastrukturtools. | |
| Vorteile: | |
| - einfache Sprache, | |
| - gute Nebenläufigkeit, | |
| - schnelle Builds. | |
| --- | |
| # Rust | |
| Rust fokussiert auf: | |
| - Performance, | |
| - Memory Safety, | |
| - Systems Programming. | |
| Es gewinnt Bedeutung für sicherheitskritische und performance-sensitive Software. | |
| --- | |
| # Datenstrukturen und Algorithmen | |
| Softwareentwicklung nutzt grundlegende Datenstrukturen: | |
| - Arrays, | |
| - Listen, | |
| - Maps, | |
| - Sets, | |
| - Queues, | |
| - Trees, | |
| - Graphs. | |
| Algorithmen bestimmen, wie Daten verarbeitet werden. | |
| Gute Softwareentwicklung kombiniert: | |
| - passende Datenstruktur, | |
| - geeigneten Algorithmus, | |
| - verständliche Implementierung. | |
| --- | |
| # Clean Code | |
| Clean Code beschreibt Code, der: | |
| - verständlich, | |
| - klar strukturiert, | |
| - gut benannt, | |
| - leicht testbar | |
| ist. | |
| Wichtige Prinzipien: | |
| - kurze Funktionen, | |
| - klare Verantwortlichkeiten, | |
| - gute Namen, | |
| - wenig versteckte Seiteneffekte. | |
| Clean Code ist kein starres Regelwerk. | |
| --- | |
| # Lesbarkeit | |
| Code wird häufiger gelesen als geschrieben. | |
| Deshalb ist Lesbarkeit ein Qualitätsmerkmal. | |
| Lesbarer Code: | |
| - reduziert Fehler, | |
| - erleichtert Reviews, | |
| - beschleunigt Wartung. | |
| --- | |
| # Naming | |
| Gute Namen erklären Zweck. | |
| Schlecht: | |
| ```text | |
| x | |
| tmp2 | |
| data1 | |
| ``` | |
| Besser: | |
| ```text | |
| activeUsers | |
| invoiceTotal | |
| retryCount | |
| ``` | |
| Namen ersetzen nicht jede Dokumentation, reduzieren aber unnötige Kommentare. | |
| --- | |
| # Funktionen | |
| Gute Funktionen sollten möglichst eine klare Aufgabe besitzen. | |
| Vorteile: | |
| - leichter testen, | |
| - leichter verstehen, | |
| - leichter wiederverwenden. | |
| --- | |
| # SOLID | |
| SOLID ist eine Sammlung von Prinzipien für objektorientiertes Design. | |
| Sie umfasst: | |
| - Single Responsibility, | |
| - Open/Closed, | |
| - Liskov Substitution, | |
| - Interface Segregation, | |
| - Dependency Inversion. | |
| SOLID sollte pragmatisch eingesetzt werden. | |
| --- | |
| # Design Patterns | |
| Design Patterns sind wiederkehrende Lösungsstrukturen. | |
| Beispiele: | |
| - Strategy, | |
| - Factory, | |
| - Observer, | |
| - Adapter, | |
| - Repository. | |
| Patterns helfen, bekannte Designprobleme zu lösen. | |
| Sie sollten nicht unnötig verwendet werden. | |
| --- | |
| # DRY | |
| DRY bedeutet: | |
| **Don't Repeat Yourself** | |
| Wiederholte Logik kann Wartung erschweren. | |
| Aber übertriebene Abstraktion kann genauso problematisch sein. | |
| --- | |
| # KISS | |
| KISS steht für: | |
| **Keep It Simple** | |
| Die einfachste Lösung, die Anforderungen erfüllt, ist häufig die beste. | |
| --- | |
| # YAGNI | |
| YAGNI bedeutet: | |
| **You Aren't Gonna Need It** | |
| Funktionen sollten nicht nur für hypothetische zukünftige Anforderungen gebaut werden. | |
| --- | |
| # Separation of Concerns | |
| Verschiedene Verantwortlichkeiten sollten getrennt werden. | |
| Beispiele: | |
| - UI, | |
| - Geschäftslogik, | |
| - Datenzugriff. | |
| Das verbessert Wartbarkeit und Testing. | |
| --- | |
| # Coupling und Cohesion | |
| ## Coupling | |
| Beschreibt Abhängigkeiten zwischen Komponenten. | |
| Geringe Kopplung ist oft wünschenswert. | |
| ## Cohesion | |
| Beschreibt, wie gut zusammengehörige Aufgaben in einer Komponente gebündelt sind. | |
| Hohe Kohäsion ist meist positiv. | |
| --- | |
| # Dependency Injection | |
| Dependency Injection stellt Abhängigkeiten von außen bereit. | |
| Vorteile: | |
| - besser testbar, | |
| - weniger harte Kopplung, | |
| - flexible Implementierungen. | |
| --- | |
| # APIs | |
| APIs ermöglichen Kommunikation zwischen Systemen. | |
| Typische API-Stile: | |
| - REST, | |
| - GraphQL, | |
| - gRPC, | |
| - Webhooks. | |
| APIs sind zentrale Bausteine moderner Softwarearchitektur. | |
| --- | |
| # REST | |
| REST nutzt häufig HTTP-Ressourcen. | |
| Beispiele: | |
| ```text | |
| GET /users | |
| POST /orders | |
| ``` | |
| Wichtige Themen: | |
| - Statuscodes, | |
| - Ressourcenmodell, | |
| - Idempotenz, | |
| - Versionierung. | |
| --- | |
| # GraphQL | |
| GraphQL erlaubt Clients, gezielt Datenfelder anzufordern. | |
| Vorteile: | |
| - flexible Queries, | |
| - weniger Overfetching. | |
| Herausforderungen: | |
| - Caching, | |
| - Query Complexity, | |
| - Security. | |
| --- | |
| # gRPC | |
| gRPC nutzt typisierte Schnittstellen und binäre Protokolle. | |
| Es eignet sich besonders für: | |
| - interne Services, | |
| - performante Kommunikation, | |
| - stark typisierte Systeme. | |
| --- | |
| # Webhooks | |
| Webhooks senden Events an externe Systeme. | |
| Beispiel: | |
| **PaymentCompleted** | |
| Wichtig: | |
| - Signaturen, | |
| - Retry, | |
| - Idempotenz, | |
| - Logging. | |
| --- | |
| # API Design | |
| Gutes API Design sollte: | |
| - konsistent, | |
| - dokumentiert, | |
| - versionierbar, | |
| - verständlich | |
| sein. | |
| APIs sind langfristige Verträge zwischen Systemen. | |
| --- | |
| # Idempotenz | |
| Eine Operation ist idempotent, wenn mehrfaches Ausführen dasselbe Ergebnis erzeugt wie einmaliges Ausführen. | |
| Das ist wichtig bei: | |
| - Retries, | |
| - Webhooks, | |
| - Distributed Systems. | |
| --- | |
| # Datenbanken | |
| Software nutzt unterschiedliche Datenbanksysteme. | |
| Typen: | |
| - relationale Datenbanken, | |
| - Dokumentdatenbanken, | |
| - Key-Value Stores, | |
| - Graphdatenbanken, | |
| - Zeitreihendatenbanken. | |
| --- | |
| # Relationale Datenbanken | |
| Relationale Datenbanken organisieren Daten in Tabellen. | |
| Beispiele: | |
| - PostgreSQL, | |
| - MySQL, | |
| - SQL Server. | |
| Sie eignen sich besonders gut für: | |
| - strukturierte Daten, | |
| - Transaktionen, | |
| - relationale Abfragen. | |
| --- | |
| # NoSQL | |
| NoSQL umfasst unterschiedliche Datenbankmodelle. | |
| Beispiele: | |
| - Document Store, | |
| - Key-Value, | |
| - Wide Column, | |
| - Graph. | |
| NoSQL ist nicht automatisch besser skalierbar. | |
| Die Wahl hängt vom Use Case ab. | |
| --- | |
| # Datenmodellierung | |
| Gute Datenmodelle: | |
| - verhindern Inkonsistenzen, | |
| - verbessern Abfragen, | |
| - vereinfachen Wartung. | |
| Wichtige Konzepte: | |
| - Schlüssel, | |
| - Beziehungen, | |
| - Normalisierung, | |
| - Constraints. | |
| --- | |
| # Transaktionen | |
| Transaktionen sorgen dafür, dass zusammengehörige Änderungen konsistent bleiben. | |
| Klassische ACID-Eigenschaften: | |
| - Atomicity, | |
| - Consistency, | |
| - Isolation, | |
| - Durability. | |
| --- | |
| # Caching | |
| Caching speichert häufig benötigte Ergebnisse. | |
| Vorteile: | |
| - geringere Latenz, | |
| - weniger Last. | |
| Herausforderung: | |
| **Cache Invalidation** | |
| Veraltete Daten müssen korrekt entfernt oder aktualisiert werden. | |
| --- | |
| # Concurrency | |
| Concurrency bedeutet, mehrere Aufgaben überlappend zu bearbeiten. | |
| Themen: | |
| - Threads, | |
| - Async, | |
| - Locks, | |
| - Race Conditions. | |
| Nebenläufigkeit kann Performance verbessern, erhöht aber Komplexität. | |
| --- | |
| # Race Conditions | |
| Race Conditions entstehen, wenn das Ergebnis von nicht kontrollierter Ausführungsreihenfolge abhängt. | |
| Schutz: | |
| - Locks, | |
| - atomare Operationen, | |
| - unveränderliche Daten, | |
| - gute Architektur. | |
| --- | |
| # Distributed Systems | |
| Verteilte Systeme bestehen aus mehreren Prozessen oder Servern. | |
| Herausforderungen: | |
| - Netzwerkfehler, | |
| - Teil-Ausfälle, | |
| - Konsistenz, | |
| - Zeit, | |
| - Retries. | |
| Eine wichtige Regel: | |
| > Das Netzwerk ist nicht zuverlässig. | |
| --- | |
| # Eventual Consistency | |
| Eventual Consistency bedeutet, dass verteilte Daten nicht sofort überall identisch sein müssen. | |
| Nach einer gewissen Zeit gleichen sich Zustände an. | |
| Das kann Skalierung erleichtern, erfordert aber klare Produktlogik. | |
| --- | |
| # Fehlerbehandlung | |
| Fehler sind normal. | |
| Robuste Software plant sie ein. | |
| Mechanismen: | |
| - Exceptions, | |
| - Result Types, | |
| - Retry, | |
| - Fallback, | |
| - Timeouts, | |
| - Circuit Breaker. | |
| --- | |
| # Retry | |
| Ein Retry wiederholt eine fehlgeschlagene Operation. | |
| Nicht jeder Fehler sollte erneut versucht werden. | |
| Wichtig: | |
| - begrenzte Versuche, | |
| - Backoff, | |
| - Idempotenz. | |
| --- | |
| # Exponential Backoff | |
| Exponential Backoff vergrößert den Abstand zwischen Wiederholungen. | |
| Das verhindert, dass ein überlasteter Dienst durch aggressive Retries zusätzlich belastet wird. | |
| --- | |
| # Circuit Breaker | |
| Ein Circuit Breaker stoppt vorübergehend Aufrufe an einen fehlerhaften Dienst. | |
| Ziel: | |
| - Cascading Failures vermeiden, | |
| - System stabilisieren. | |
| --- | |
| # Timeouts | |
| Jeder externe Aufruf sollte ein sinnvolles Timeout besitzen. | |
| Ohne Timeout können blockierte Requests Ressourcen dauerhaft binden. | |
| --- | |
| # Testing | |
| Softwaretests prüfen Verhalten systematisch. | |
| Typen: | |
| - Unit Tests, | |
| - Integration Tests, | |
| - End-to-End Tests, | |
| - Performance Tests, | |
| - Security Tests. | |
| --- | |
| # Unit Tests | |
| Unit Tests prüfen kleine Einheiten. | |
| Vorteile: | |
| - schnell, | |
| - präzise, | |
| - leicht automatisierbar. | |
| --- | |
| # Integration Tests | |
| Integration Tests prüfen das Zusammenspiel mehrerer Komponenten. | |
| Beispiele: | |
| - API + Datenbank, | |
| - Service + Queue. | |
| --- | |
| # End-to-End Tests | |
| E2E Tests prüfen vollständige Nutzerabläufe. | |
| Beispiele: | |
| **Login → Bestellung → Zahlung** | |
| Sie sind wertvoll, aber langsamer und aufwendiger. | |
| --- | |
| # Test Pyramid | |
| Die Test Pyramid empfiehlt typischerweise: | |
| - viele schnelle Unit Tests, | |
| - weniger Integration Tests, | |
| - wenige E2E Tests. | |
| Das genaue Verhältnis hängt vom System ab. | |
| --- | |
| # Test Driven Development | |
| TDD verwendet einen Zyklus: | |
| **Red → Green → Refactor** | |
| 1. fehlschlagenden Test schreiben, | |
| 2. minimale Implementierung, | |
| 3. Code verbessern. | |
| TDD ist ein Werkzeug, kein Zwang. | |
| --- | |
| # Code Review | |
| Code Review verbessert Qualität durch menschliche Prüfung. | |
| Ziele: | |
| - Fehler finden, | |
| - Wissen teilen, | |
| - Design prüfen, | |
| - Security verbessern. | |
| Gute Reviews fokussieren auf Code, nicht auf Personen. | |
| --- | |
| # Pull Requests | |
| Pull Requests bündeln Änderungen für Review. | |
| Eine gute Pull Request ist: | |
| - klein, | |
| - klar beschrieben, | |
| - testbar, | |
| - fokussiert. | |
| Sehr große Änderungen sind schwer zu prüfen. | |
| --- | |
| # Versionskontrolle | |
| Versionskontrolle dokumentiert Änderungen. | |
| Git ist heute weit verbreitet. | |
| Vorteile: | |
| - Historie, | |
| - Zusammenarbeit, | |
| - Branches, | |
| - Rollback. | |
| --- | |
| # Branching | |
| Branching trennt Entwicklungsstände. | |
| Strategien: | |
| - Trunk-Based Development, | |
| - Feature Branches, | |
| - Git Flow. | |
| Kein Modell ist immer optimal. | |
| --- | |
| # Trunk-Based Development | |
| Bei Trunk-Based Development werden kleine Änderungen häufig in den Hauptzweig integriert. | |
| Vorteile: | |
| - weniger Merge-Konflikte, | |
| - schnelle Integration, | |
| - unterstützt Continuous Delivery. | |
| --- | |
| # Continuous Integration | |
| CI bedeutet, Änderungen regelmäßig automatisiert zu integrieren. | |
| Typische Pipeline: | |
| - Build, | |
| - Tests, | |
| - Linting, | |
| - Security Checks. | |
| --- | |
| # Continuous Delivery | |
| Continuous Delivery sorgt dafür, dass Software jederzeit deploybar ist. | |
| Deployment kann weiterhin manuell freigegeben werden. | |
| --- | |
| # Continuous Deployment | |
| Continuous Deployment geht einen Schritt weiter. | |
| Erfolgreiche Änderungen werden automatisch produktiv ausgerollt. | |
| Das erfordert starke Tests, Monitoring und Rollback. | |
| --- | |
| # DevOps | |
| DevOps verbindet Entwicklung und Betrieb. | |
| Ziele: | |
| - schnellere Releases, | |
| - mehr Automatisierung, | |
| - gemeinsame Verantwortung, | |
| - bessere Zuverlässigkeit. | |
| DevOps ist keine einzelne Technologie. | |
| --- | |
| # DevSecOps | |
| DevSecOps integriert Security früh in Entwicklung und Betrieb. | |
| Beispiele: | |
| - Dependency Scanning, | |
| - Secret Scanning, | |
| - SAST, | |
| - IaC Checks. | |
| --- | |
| # Infrastructure as Code | |
| Infrastructure as Code beschreibt Infrastruktur in versioniertem Code. | |
| Vorteile: | |
| - reproduzierbar, | |
| - reviewbar, | |
| - automatisierbar. | |
| --- | |
| # Container | |
| Container bündeln Anwendung und Abhängigkeiten. | |
| Vorteile: | |
| - konsistente Umgebungen, | |
| - portables Deployment. | |
| Docker ist ein bekanntes Container-Ökosystem. | |
| --- | |
| # Kubernetes | |
| Kubernetes orchestriert Container. | |
| Funktionen: | |
| - Scheduling, | |
| - Scaling, | |
| - Service Discovery, | |
| - Rollouts. | |
| Kubernetes ist leistungsfähig, aber komplex. | |
| Nicht jedes Projekt benötigt Kubernetes. | |
| --- | |
| # Cloud-Native Development | |
| Cloud-Native Development nutzt Prinzipien wie: | |
| - APIs, | |
| - Automatisierung, | |
| - Container, | |
| - Observability, | |
| - elastische Skalierung. | |
| Cloud-native bedeutet nicht nur „läuft in der Cloud“. | |
| --- | |
| # Serverless | |
| Serverless abstrahiert Serverbetrieb stärker. | |
| Beispiele: | |
| - Functions, | |
| - Event-basierte Workloads. | |
| Vorteile: | |
| - schnelles Deployment, | |
| - automatische Skalierung. | |
| Nachteile: | |
| - Anbieterabhängigkeit, | |
| - Laufzeitgrenzen, | |
| - Cold Starts. | |
| --- | |
| # Observability | |
| Observability hilft zu verstehen, was in einem System passiert. | |
| Drei klassische Signale: | |
| - Logs, | |
| - Metrics, | |
| - Traces. | |
| Moderne Systeme ergänzen: | |
| - Events, | |
| - Profiling, | |
| - Business-Metriken. | |
| --- | |
| # Logging | |
| Logs dokumentieren Ereignisse. | |
| Gute Logs: | |
| - haben Kontext, | |
| - enthalten Zeitstempel, | |
| - vermeiden sensible Daten, | |
| - sind maschinenlesbar. | |
| --- | |
| # Metrics | |
| Metrics messen Systemzustände. | |
| Beispiele: | |
| - Request Rate, | |
| - Error Rate, | |
| - Latency, | |
| - CPU, | |
| - Memory. | |
| --- | |
| # Distributed Tracing | |
| Tracing verfolgt Requests über mehrere Services. | |
| Besonders wichtig bei Microservices. | |
| --- | |
| # SLI, SLO und SLA | |
| ## SLI | |
| Messwert. | |
| ## SLO | |
| Zielwert. | |
| ## SLA | |
| vertragliche Zusage. | |
| Beispiel: | |
| - SLI: Verfügbarkeit, | |
| - SLO: 99,9 %. | |
| --- | |
| # Reliability Engineering | |
| Reliability Engineering fokussiert auf zuverlässigen Betrieb. | |
| Themen: | |
| - Redundanz, | |
| - Recovery, | |
| - Error Budgets, | |
| - Chaos Testing. | |
| --- | |
| # Scalability | |
| Scalability beschreibt, wie ein System mit wachsender Last umgeht. | |
| Möglichkeiten: | |
| - vertikal skalieren, | |
| - horizontal skalieren. | |
| Skalierbarkeit hängt nicht nur von Infrastruktur ab. | |
| Auch Architektur und Datenmodell sind entscheidend. | |
| --- | |
| # Performance | |
| Performance umfasst: | |
| - Latenz, | |
| - Durchsatz, | |
| - Ressourcenverbrauch. | |
| Optimierung sollte auf Messungen basieren. | |
| --- | |
| # Profiling | |
| Profiling zeigt reale Engpässe. | |
| Es verhindert, dass Teams an falschen Stellen optimieren. | |
| --- | |
| # Security in der Softwareentwicklung | |
| Sicherheit sollte Teil des gesamten Entwicklungsprozesses sein. | |
| Wichtige Prinzipien: | |
| - Secure by Design, | |
| - Least Privilege, | |
| - Input Validation, | |
| - Secrets Management, | |
| - sichere Dependencies. | |
| --- | |
| # Input Validation | |
| Externe Eingaben sollten nie blind vertraut werden. | |
| Validierung prüft: | |
| - Typ, | |
| - Format, | |
| - Länge, | |
| - erlaubte Werte. | |
| --- | |
| # Output Encoding | |
| Bei Webanwendungen hilft korrektes Output Encoding, bestimmte Injection-Angriffe zu verhindern. | |
| --- | |
| # Authentication | |
| Authentication beantwortet: | |
| > Wer bist du? | |
| --- | |
| # Authorization | |
| Authorization beantwortet: | |
| > Was darfst du? | |
| Diese beiden Konzepte sollten klar getrennt werden. | |
| --- | |
| # Secrets Management | |
| Secrets wie API Keys gehören nicht in Quellcode. | |
| Sie sollten sicher gespeichert und regelmäßig rotiert werden. | |
| --- | |
| # Dependency Management | |
| Moderne Software verwendet viele externe Bibliotheken. | |
| Wichtige Aufgaben: | |
| - Versionen kontrollieren, | |
| - Updates prüfen, | |
| - Sicherheitslücken überwachen, | |
| - unnötige Dependencies entfernen. | |
| --- | |
| # Software Supply Chain | |
| Die Software Supply Chain umfasst: | |
| - Source Code, | |
| - Dependencies, | |
| - Build-System, | |
| - CI/CD, | |
| - Artefakte, | |
| - Deployment. | |
| Jede Stufe kann Sicherheitsrisiken enthalten. | |
| --- | |
| # Dokumentation | |
| Dokumentation unterstützt: | |
| - Onboarding, | |
| - Wartung, | |
| - Betrieb, | |
| - Architekturverständnis. | |
| Wichtige Dokumente: | |
| - README, | |
| - API-Dokumentation, | |
| - Architekturentscheidungen, | |
| - Runbooks. | |
| --- | |
| # Architecture Decision Records | |
| ADRs dokumentieren wichtige Architekturentscheidungen. | |
| Typische Struktur: | |
| - Kontext, | |
| - Entscheidung, | |
| - Alternativen, | |
| - Konsequenzen. | |
| Sie helfen später zu verstehen, warum eine Lösung gewählt wurde. | |
| --- | |
| # Technical Debt | |
| Technical Debt beschreibt technische Kompromisse, die spätere Kosten erzeugen. | |
| Beispiele: | |
| - fehlende Tests, | |
| - veraltete Architektur, | |
| - Workarounds, | |
| - schlechte Dokumentation. | |
| Technische Schulden sind nicht immer schlecht. | |
| Sie sollten aber bewusst verwaltet werden. | |
| --- | |
| # Refactoring | |
| Refactoring verbessert internen Code, ohne Verhalten zu ändern. | |
| Ziele: | |
| - bessere Struktur, | |
| - weniger Duplikation, | |
| - bessere Lesbarkeit, | |
| - leichteres Testing. | |
| --- | |
| # Legacy Software | |
| Legacy Software ist ältere Software, die weiterhin wichtig ist. | |
| Herausforderungen: | |
| - wenig Tests, | |
| - alte Technologie, | |
| - fehlende Dokumentation, | |
| - schweres Deployment. | |
| Modernisierung sollte schrittweise erfolgen. | |
| --- | |
| # Strangler Pattern | |
| Das Strangler Pattern ersetzt Legacy-Systeme schrittweise. | |
| Neue Funktionen werden außerhalb des alten Systems aufgebaut. | |
| Nach und nach werden alte Komponenten ersetzt. | |
| --- | |
| # Softwarequalität | |
| Softwarequalität umfasst mehrere Dimensionen: | |
| - Korrektheit, | |
| - Wartbarkeit, | |
| - Zuverlässigkeit, | |
| - Performance, | |
| - Security, | |
| - Usability. | |
| Qualität ist nicht nur „keine Bugs“. | |
| --- | |
| # Maintainability | |
| Maintainability beschreibt, wie leicht Software geändert werden kann. | |
| Gute Wartbarkeit reduziert langfristige Kosten. | |
| --- | |
| # Portability | |
| Portability beschreibt, wie leicht Software in unterschiedliche Umgebungen übertragen werden kann. | |
| --- | |
| # Usability | |
| Usability beschreibt, wie gut Menschen eine Anwendung nutzen können. | |
| Technische Qualität allein reicht nicht aus. | |
| --- | |
| # Accessibility | |
| Accessibility sorgt dafür, dass Software auch für Menschen mit Einschränkungen nutzbar ist. | |
| Sie ist Teil professioneller Produktentwicklung. | |
| --- | |
| # Agile Softwareentwicklung | |
| Agile Methoden arbeiten iterativ. | |
| Ziele: | |
| - frühes Feedback, | |
| - kleine Schritte, | |
| - Anpassbarkeit. | |
| Agil bedeutet nicht planlos. | |
| --- | |
| # Scrum | |
| Scrum ist ein Framework mit: | |
| - Product Backlog, | |
| - Sprint, | |
| - Review, | |
| - Retrospektive. | |
| Es eignet sich nicht automatisch für jedes Team. | |
| --- | |
| # Kanban | |
| Kanban visualisiert Arbeit und begrenzt parallele Aufgaben. | |
| Wichtige Idee: | |
| **Work in Progress begrenzen** | |
| Das kann Durchfluss verbessern. | |
| --- | |
| # Extreme Programming | |
| XP fokussiert auf Engineering Practices. | |
| Beispiele: | |
| - Pair Programming, | |
| - TDD, | |
| - Continuous Integration, | |
| - kleine Releases. | |
| --- | |
| # Softwareentwicklung im Team | |
| Gute Software entsteht durch Zusammenarbeit. | |
| Wichtige Fähigkeiten: | |
| - Kommunikation, | |
| - Review, | |
| - Dokumentation, | |
| - Ownership. | |
| Technische Exzellenz ohne Teamfähigkeit skaliert schlecht. | |
| --- | |
| # Pair Programming | |
| Beim Pair Programming arbeiten zwei Entwickler gemeinsam an einer Aufgabe. | |
| Vorteile: | |
| - Wissensaustausch, | |
| - direkte Reviews, | |
| - schnellere Problemlösung. | |
| --- | |
| # Mob Programming | |
| Mehrere Teammitglieder arbeiten gemeinsam an einem Problem. | |
| Das kann bei komplexen Architektur- oder Debugging-Aufgaben hilfreich sein. | |
| --- | |
| # Developer Experience | |
| Developer Experience beschreibt, wie gut Entwickler mit Tools, Plattformen und Prozessen arbeiten können. | |
| Gute DX bedeutet: | |
| - schnelle lokale Einrichtung, | |
| - klare Dokumentation, | |
| - schnelle Builds, | |
| - verständliche Fehlermeldungen, | |
| - einfache Deployments. | |
| --- | |
| # Platform Engineering | |
| Platform Engineering baut interne Plattformen für Entwicklerteams. | |
| Ziele: | |
| - Self-Service, | |
| - Standardisierung, | |
| - weniger Infrastrukturkomplexität, | |
| - sichere Defaults. | |
| --- | |
| # Internal Developer Platform | |
| Eine interne Entwicklerplattform kann bereitstellen: | |
| - Templates, | |
| - CI/CD, | |
| - Observability, | |
| - Secrets, | |
| - Deployment, | |
| - Service Catalog. | |
| --- | |
| # API-First Development | |
| API-First bedeutet, Schnittstellen früh zu definieren. | |
| Vorteile: | |
| - Teams können parallel arbeiten, | |
| - klare Verträge, | |
| - bessere Integration. | |
| --- | |
| # Contract Testing | |
| Contract Tests prüfen, ob Services vereinbarte Schnittstellen einhalten. | |
| Sie sind besonders relevant bei Microservices. | |
| --- | |
| # Feature Flags | |
| Feature Flags ermöglichen, Funktionen unabhängig vom Deployment zu aktivieren. | |
| Vorteile: | |
| - kontrollierte Rollouts, | |
| - Experimente, | |
| - schnelles Abschalten. | |
| Flags sollten später wieder entfernt werden. | |
| --- | |
| # Canary Releases | |
| Canary Releases rollen eine neue Version zunächst an eine kleine Nutzergruppe aus. | |
| Wenn Metriken gut bleiben, wird der Rollout erweitert. | |
| --- | |
| # Blue-Green Deployment | |
| Blue-Green Deployment hält zwei Produktionsumgebungen bereit. | |
| Eine neue Version wird in einer separaten Umgebung vorbereitet. | |
| Danach wird der Traffic umgeschaltet. | |
| --- | |
| # Rollback | |
| Rollback stellt eine vorherige stabile Version wieder her. | |
| Ein Deployment ist erst dann wirklich sicher, wenn ein Rückweg existiert. | |
| --- | |
| # Database Migrations | |
| Datenbankschemata verändern sich mit Software. | |
| Migrations sollten: | |
| - versioniert, | |
| - getestet, | |
| - rückrollbar oder vorwärtskompatibel | |
| sein. | |
| --- | |
| # Backward Compatibility | |
| Backward Compatibility bedeutet, dass neue Versionen weiterhin mit älteren Clients oder Datenformaten funktionieren. | |
| Das ist besonders wichtig bei APIs. | |
| --- | |
| # Semantic Versioning | |
| Semantic Versioning verwendet typischerweise: | |
| **MAJOR.MINOR.PATCH** | |
| - Major: inkompatible Änderungen, | |
| - Minor: neue kompatible Funktionen, | |
| - Patch: kompatible Fehlerkorrekturen. | |
| --- | |
| # Open Source Softwareentwicklung | |
| Open Source ermöglicht gemeinschaftliche Entwicklung. | |
| Wichtige Bestandteile: | |
| - Repository, | |
| - Lizenz, | |
| - Contribution Guidelines, | |
| - Issues, | |
| - Releases. | |
| --- | |
| # Lizenzen | |
| Softwarelizenzen bestimmen, wie Code genutzt werden darf. | |
| Beispiele: | |
| - MIT, | |
| - Apache-2.0, | |
| - GPL. | |
| Lizenzwahl sollte bewusst erfolgen. | |
| --- | |
| # Softwareentwicklung und Künstliche Intelligenz | |
| KI verändert den Entwicklungsprozess stark. | |
| KI kann unterstützen bei: | |
| - Codegenerierung, | |
| - Debugging, | |
| - Tests, | |
| - Dokumentation, | |
| - Refactoring, | |
| - Code Review. | |
| --- | |
| # AI Coding | |
| AI Coding bezeichnet den Einsatz von KI beim Programmieren. | |
| Ein Entwickler kann beispielsweise: | |
| - Funktionen generieren, | |
| - Code erklären lassen, | |
| - Tests erzeugen, | |
| - Fehler analysieren. | |
| KI sollte dabei als Werkzeug genutzt werden, nicht als Ersatz für Verständnis. | |
| --- | |
| # Coding Assistants | |
| Coding Assistants arbeiten meist interaktiv mit Entwicklern. | |
| Sie unterstützen: | |
| - Autocomplete, | |
| - Chat, | |
| - Codegeneration, | |
| - Refactoring. | |
| --- | |
| # Coding Agents | |
| Coding Agents gehen weiter. | |
| Sie können mehrstufige Aufgaben bearbeiten: | |
| 1. Repository analysieren. | |
| 2. Dateien auswählen. | |
| 3. Änderungen durchführen. | |
| 4. Tests ausführen. | |
| 5. Fehler beheben. | |
| 6. Pull Request vorbereiten. | |
| --- | |
| # Agentic Software Engineering | |
| Agentic Software Engineering beschreibt Entwicklungsprozesse, bei denen KI-Agenten aktiv an Softwareprojekten arbeiten. | |
| Mögliche Rollen: | |
| - Coding Agent, | |
| - Testing Agent, | |
| - Review Agent, | |
| - Documentation Agent, | |
| - Security Agent. | |
| --- | |
| # Risiken von Coding Agents | |
| Coding Agents können: | |
| - falsche Änderungen machen, | |
| - Tests umgehen, | |
| - Secrets lesen, | |
| - unsichere Dependencies hinzufügen. | |
| Deshalb benötigen sie: | |
| - Sandbox, | |
| - minimale Rechte, | |
| - Tests, | |
| - Code Review, | |
| - Audit Logs. | |
| --- | |
| # Repository Context | |
| KI-Systeme brauchen Kontext über ein Repository. | |
| Mögliche Quellen: | |
| - Source Code, | |
| - Tests, | |
| - README, | |
| - Architecture Docs, | |
| - Issues, | |
| - Git History. | |
| Zu viel Kontext kann jedoch teuer oder unübersichtlich werden. | |
| --- | |
| # AI Code Review | |
| KI kann Code Reviews unterstützen. | |
| Mögliche Aufgaben: | |
| - Bugs finden, | |
| - Security-Probleme markieren, | |
| - Tests vorschlagen, | |
| - Stilprobleme erkennen. | |
| Menschen sollten kritische Änderungen weiterhin prüfen. | |
| --- | |
| # AI-generierte Tests | |
| KI kann Testfälle erzeugen. | |
| Besonders nützlich für: | |
| - Edge Cases, | |
| - Regression Tests, | |
| - Property-Based Tests. | |
| Qualität hängt jedoch vom Verständnis der Anforderungen ab. | |
| --- | |
| # AI Debugging | |
| KI kann Logs, Stack Traces und Code gemeinsam analysieren. | |
| Sie kann Hypothesen erzeugen. | |
| Trotzdem sollte ein Entwickler prüfen, ob die vorgeschlagene Ursache tatsächlich zutrifft. | |
| --- | |
| # AI Refactoring | |
| KI kann helfen bei: | |
| - Methoden extrahieren, | |
| - Typen verbessern, | |
| - Duplikate reduzieren, | |
| - Legacy-Code erklären. | |
| Automatische Refactorings sollten durch Tests abgesichert sein. | |
| --- | |
| # Prompt Engineering für Coding | |
| Gute Coding-Prompts enthalten: | |
| - Ziel, | |
| - Kontext, | |
| - Einschränkungen, | |
| - gewünschte Ausgabe, | |
| - Tests. | |
| Beispiel: | |
| > Implementiere diese Funktion, ändere keine öffentliche API und füge Unit Tests für drei Randfälle hinzu. | |
| --- | |
| # Context Engineering | |
| Bei Coding Agents wird Context Engineering wichtiger als einzelne Prompts. | |
| Relevanter Kontext: | |
| - Architektur, | |
| - Coding Standards, | |
| - Build-Befehle, | |
| - Tests, | |
| - Deployment-Regeln. | |
| --- | |
| # Tool Use in Softwareentwicklung | |
| Coding Agents können Tools verwenden: | |
| - Git, | |
| - Shell, | |
| - Tests, | |
| - Linter, | |
| - Compiler, | |
| - Package Manager. | |
| Tool-Zugriff erhöht Fähigkeiten, aber auch Risiken. | |
| --- | |
| # Softwareentwicklung mit mehreren Agenten | |
| Multi-Agent-Ansätze können Rollen trennen. | |
| Beispiel: | |
| - Planner Agent, | |
| - Coding Agent, | |
| - Testing Agent, | |
| - Review Agent. | |
| Mehr Agenten sind jedoch nicht automatisch besser. | |
| Koordination kann zusätzlichen Aufwand erzeugen. | |
| --- | |
| # Softwareentwicklung und MCP | |
| Das Model Context Protocol kann KI-Systeme mit externen Tools und Datenquellen verbinden. | |
| In der Softwareentwicklung können MCP-basierte Integrationen Zugriff ermöglichen auf: | |
| - Repositories, | |
| - Dokumentation, | |
| - Issue Tracker, | |
| - Build-Systeme, | |
| - Datenbanken. | |
| Berechtigungen sollten minimal bleiben. | |
| --- | |
| # Softwareentwicklung und RAG | |
| RAG kann Entwicklerassistenten mit projektspezifischem Wissen versorgen. | |
| Quellen: | |
| - interne Dokumentation, | |
| - API-Dokumentation, | |
| - Architekturentscheidungen, | |
| - Runbooks. | |
| --- | |
| # AI Software Development Lifecycle | |
| Ein zukünftiger Entwicklungsprozess könnte so aussehen: | |
| **Requirement** | |
| ↓ | |
| **AI-assisted Design** | |
| ↓ | |
| **Code Generation** | |
| ↓ | |
| **Automated Tests** | |
| ↓ | |
| **AI Review** | |
| ↓ | |
| **Human Approval** | |
| ↓ | |
| **Deployment** | |
| ↓ | |
| **Observability** | |
| ↓ | |
| **Continuous Improvement** | |
| --- | |
| # Human-in-the-Loop | |
| Menschen bleiben besonders wichtig bei: | |
| - Architekturentscheidungen, | |
| - Security, | |
| - kritischen Codeänderungen, | |
| - Produktentscheidungen. | |
| Automatisierung sollte mit Risiko steigen oder sinken. | |
| --- | |
| # Software Development Readiness | |
| Readiness bewertet, ob ein Softwareprojekt produktionsreif ist. | |
| Dimensionen: | |
| - Requirements, | |
| - Architecture, | |
| - Testing, | |
| - Security, | |
| - Deployment, | |
| - Observability, | |
| - Ownership. | |
| --- | |
| # Production Readiness | |
| Ein System sollte vor Produktion Fragen beantworten können: | |
| - Sind Tests vorhanden? | |
| - Ist Monitoring aktiv? | |
| - Gibt es Rollback? | |
| - Sind Secrets geschützt? | |
| - Sind Fehlerpfade getestet? | |
| - Gibt es Ownership? | |
| --- | |
| # Code Quality Metrics | |
| Mögliche Metriken: | |
| - Test Coverage, | |
| - Cyclomatic Complexity, | |
| - Duplication, | |
| - Defect Rate. | |
| Metriken sollten helfen, nicht zum Selbstzweck werden. | |
| --- | |
| # Cyclomatic Complexity | |
| Cyclomatic Complexity misst vereinfacht die Anzahl unabhängiger Pfade durch Code. | |
| Hohe Werte können auf schwer verständliche Logik hinweisen. | |
| --- | |
| # Test Coverage | |
| Test Coverage misst, welcher Anteil des Codes durch Tests ausgeführt wird. | |
| 100 % Coverage bedeutet nicht automatisch gute Tests. | |
| --- | |
| # Static Analysis | |
| Static Analysis untersucht Code ohne Ausführung. | |
| Sie kann finden: | |
| - Bugs, | |
| - Style-Probleme, | |
| - Security-Risiken. | |
| --- | |
| # Linting | |
| Linting prüft Code gegen Regeln. | |
| Vorteile: | |
| - konsistenter Stil, | |
| - frühe Fehlererkennung. | |
| --- | |
| # Formatting | |
| Automatische Formatter reduzieren Diskussionen über Stil. | |
| Beispiele: | |
| - Black, | |
| - Prettier, | |
| - gofmt. | |
| --- | |
| # Build Systems | |
| Build-Systeme automatisieren: | |
| - Kompilierung, | |
| - Packaging, | |
| - Tests, | |
| - Artefakte. | |
| Gute Builds sollten reproduzierbar sein. | |
| --- | |
| # Reproducible Builds | |
| Reproduzierbare Builds erzeugen aus identischem Quellcode identische Artefakte. | |
| Das verbessert: | |
| - Vertrauen, | |
| - Debugging, | |
| - Supply Chain Security. | |
| --- | |
| # Package Management | |
| Package Manager verwalten Abhängigkeiten. | |
| Beispiele: | |
| - npm, | |
| - pip, | |
| - Maven, | |
| - NuGet, | |
| - Cargo. | |
| Versionierung sollte kontrolliert erfolgen. | |
| --- | |
| # Dependency Locking | |
| Lockfiles speichern exakte Dependency-Versionen. | |
| Sie helfen, Builds reproduzierbar zu machen. | |
| --- | |
| # Monorepo | |
| Ein Monorepo speichert mehrere Projekte in einem Repository. | |
| Vorteile: | |
| - gemeinsame Tools, | |
| - atomare Änderungen, | |
| - zentrale Standards. | |
| Nachteile: | |
| - Build-Komplexität, | |
| - Zugriffssteuerung. | |
| --- | |
| # Polyrepo | |
| Polyrepo trennt Projekte in mehrere Repositories. | |
| Vorteile: | |
| - klare Grenzen, | |
| - unabhängige Zugriffe. | |
| Nachteile: | |
| - komplexere koordinierte Änderungen. | |
| --- | |
| # Softwareentwicklung in Unternehmen | |
| Unternehmenssoftware benötigt zusätzlich: | |
| - Governance, | |
| - Compliance, | |
| - Integration, | |
| - langfristige Wartbarkeit. | |
| Technologieentscheidungen sollten über Jahre tragfähig sein. | |
| --- | |
| # Build vs. Buy | |
| Nicht jede Software muss selbst entwickelt werden. | |
| Eine Entscheidung kann berücksichtigen: | |
| - strategische Bedeutung, | |
| - Kosten, | |
| - Geschwindigkeit, | |
| - Anpassbarkeit, | |
| - Vendor Lock-in. | |
| --- | |
| # Make-or-Buy bei KI | |
| Bei KI-Systemen stellt sich zusätzlich die Frage: | |
| - eigenes Modell, | |
| - API-Modell, | |
| - Open Source, | |
| - Managed Service. | |
| Die richtige Wahl hängt von Daten, Kosten, Kontrolle und Betrieb ab. | |
| --- | |
| # Technische Schulden und Geschwindigkeit | |
| Schnelle Entwicklung kann sinnvoll sein. | |
| Problematisch wird sie, wenn kurzfristige Kompromisse nie zurückgebaut werden. | |
| Gute Teams machen technische Schulden sichtbar. | |
| --- | |
| # Softwareentwicklung als kontinuierlicher Prozess | |
| Software ist selten „fertig“. | |
| Nach dem Release folgen: | |
| - Bugfixes, | |
| - Updates, | |
| - neue Anforderungen, | |
| - Security Updates, | |
| - Skalierung. | |
| Deshalb ist Wartbarkeit so wichtig. | |
| --- | |
| # Requirements Engineering | |
| Requirements Engineering geht über das bloße Sammeln von Anforderungen hinaus. | |
| Es umfasst: | |
| - Anforderungen ermitteln, | |
| - Widersprüche erkennen, | |
| - Prioritäten setzen, | |
| - Akzeptanzkriterien definieren, | |
| - Änderungen nachvollziehen. | |
| Besonders wichtig ist die Trennung zwischen: | |
| - Nutzerwunsch, | |
| - Geschäftsanforderung, | |
| - technischer Lösung. | |
| Ein Team sollte nicht vorschnell eine technische Implementierung als eigentliche Anforderung behandeln. | |
| --- | |
| # Domain-Driven Design | |
| Domain-Driven Design, kurz DDD, richtet Softwarearchitektur stark an der fachlichen Domäne aus. | |
| Zentrale Ideen: | |
| - gemeinsame Sprache zwischen Fachbereich und Entwicklung, | |
| - klar abgegrenzte fachliche Bereiche, | |
| - Modelle, die reale Geschäftslogik ausdrücken. | |
| Besonders bei komplexen Unternehmenssystemen kann DDD helfen, Software näher an tatsächlichen Geschäftsprozessen zu strukturieren. | |
| --- | |
| # Bounded Context | |
| Ein Bounded Context definiert einen klaren fachlichen Bereich. | |
| Beispiel: | |
| In einem E-Commerce-System können: | |
| - Bestellung, | |
| - Zahlung, | |
| - Versand | |
| jeweils eigene fachliche Modelle besitzen. | |
| Dasselbe Wort kann in verschiedenen Kontexten eine andere Bedeutung haben. | |
| Klare Grenzen reduzieren versteckte Kopplung. | |
| --- | |
| # Hexagonale Architektur | |
| Hexagonal Architecture trennt Kernlogik von technischen Schnittstellen. | |
| Der Kern kennt beispielsweise nicht direkt: | |
| - Datenbank, | |
| - Webframework, | |
| - Messaging-System. | |
| Stattdessen kommuniziert er über definierte Ports und Adapter. | |
| Vorteile: | |
| - bessere Testbarkeit, | |
| - geringere technische Kopplung, | |
| - leichterer Austausch von Infrastruktur. | |
| --- | |
| # Clean Architecture | |
| Clean Architecture verfolgt ein ähnliches Ziel. | |
| Geschäftslogik soll möglichst unabhängig bleiben von: | |
| - Frameworks, | |
| - Datenbanken, | |
| - UI, | |
| - externen Services. | |
| Abhängigkeiten sollten nach innen zeigen. | |
| --- | |
| # CQRS | |
| CQRS trennt Lesen und Schreiben. | |
| **Command** | |
| ändert Zustand. | |
| **Query** | |
| liest Zustand. | |
| Diese Trennung kann bei komplexen Systemen Vorteile bringen, erhöht aber auch Architekturaufwand. | |
| Für einfache Anwendungen ist CQRS oft unnötig. | |
| --- | |
| # Event Sourcing | |
| Event Sourcing speichert Änderungen als Ereignisse. | |
| Statt nur den aktuellen Zustand zu speichern, wird die Historie erhalten. | |
| Beispiel: | |
| - OrderCreated | |
| - ItemAdded | |
| - PaymentReceived | |
| - OrderShipped | |
| Vorteile: | |
| - Auditierbarkeit, | |
| - Historie, | |
| - Replay. | |
| Herausforderungen: | |
| - höhere Komplexität, | |
| - Event-Versionierung, | |
| - Projektionen. | |
| --- | |
| # Messaging und Queues | |
| Asynchrone Kommunikation verwendet häufig: | |
| - Queues, | |
| - Topics, | |
| - Event Streams. | |
| Typische Vorteile: | |
| - Entkopplung, | |
| - Lastverteilung, | |
| - Fehlertoleranz. | |
| Wichtige Themen: | |
| - Reihenfolge, | |
| - doppelte Nachrichten, | |
| - Retry, | |
| - Dead-Letter Queue, | |
| - Idempotenz. | |
| --- | |
| # Dead-Letter Queue | |
| Eine Dead-Letter Queue sammelt Nachrichten, die nach mehreren Versuchen nicht verarbeitet werden konnten. | |
| Sie hilft bei: | |
| - Fehleranalyse, | |
| - manueller Nachbearbeitung, | |
| - kontrollierter Wiederholung. | |
| --- | |
| # Schema Evolution | |
| Datenformate und Events verändern sich. | |
| Schema Evolution beschreibt, wie neue Versionen eingeführt werden, ohne bestehende Systeme sofort zu brechen. | |
| Strategien: | |
| - optionale Felder, | |
| - kompatible Erweiterungen, | |
| - Versionierung, | |
| - Migrationspfade. | |
| --- | |
| # Feature Ownership | |
| Produktive Software benötigt klare Ownership. | |
| Für jedes wichtige System sollte bekannt sein: | |
| - wer fachlich verantwortlich ist, | |
| - wer technisch verantwortlich ist, | |
| - wer im Incident reagiert, | |
| - wer Änderungen freigibt. | |
| Fehlende Ownership führt oft zu technischen Schulden und langsamer Fehlerbehebung. | |
| --- | |
| # Runbooks | |
| Runbooks beschreiben operative Abläufe. | |
| Beispiele: | |
| - Service neu starten, | |
| - Datenbank-Failover, | |
| - Zertifikat erneuern, | |
| - Incident eindämmen. | |
| Gute Runbooks sind: | |
| - aktuell, | |
| - testbar, | |
| - konkret, | |
| - leicht auffindbar. | |
| --- | |
| # Incident Management | |
| Auch gute Software kann ausfallen. | |
| Incident Management strukturiert den Umgang mit Störungen. | |
| Typischer Ablauf: | |
| 1. erkennen, | |
| 2. priorisieren, | |
| 3. verantwortliche Person bestimmen, | |
| 4. Auswirkungen begrenzen, | |
| 5. System wiederherstellen, | |
| 6. Ursache analysieren, | |
| 7. Verbesserungen umsetzen. | |
| --- | |
| # Postmortems | |
| Nach größeren Incidents sollte ein Postmortem dokumentieren: | |
| - was passiert ist, | |
| - welche Auswirkungen entstanden, | |
| - warum vorhandene Schutzmechanismen nicht ausreichten, | |
| - welche Maßnahmen folgen. | |
| Gute Postmortems fokussieren auf Systemverbesserung statt Schuldzuweisung. | |
| --- | |
| # Error Budgets | |
| Error Budgets verbinden Zuverlässigkeit und Entwicklungsgeschwindigkeit. | |
| Wenn ein Service sein Zuverlässigkeitsziel deutlich unterschreitet, sollte Stabilisierung Vorrang erhalten. | |
| Liegt er innerhalb des Budgets, kann mehr Veränderung toleriert werden. | |
| Dieses Prinzip hilft, Zuverlässigkeit messbar in Produktentscheidungen einzubeziehen. | |
| --- | |
| # Chaos Engineering | |
| Chaos Engineering testet, wie Systeme auf kontrollierte Fehler reagieren. | |
| Beispiele: | |
| - Service nicht erreichbar, | |
| - Netzwerk verzögert, | |
| - Instanz fällt aus. | |
| Ziel ist nicht, Systeme absichtlich zu beschädigen, sondern Schwächen vor realen Störungen sichtbar zu machen. | |
| --- | |
| # Softwareentwicklung als sozio-technisches System | |
| Software entsteht nicht nur durch Technologie. | |
| Sie entsteht durch das Zusammenspiel von: | |
| - Menschen, | |
| - Teams, | |
| - Prozessen, | |
| - Architektur, | |
| - Tools, | |
| - Organisation. | |
| Deshalb können technische Probleme organisatorische Ursachen haben. | |
| Beispiel: | |
| Eine stark gekoppelte Architektur kann die Struktur einer Organisation widerspiegeln. | |
| Gute Softwareentwicklung betrachtet deshalb nicht nur Code, sondern auch Zusammenarbeit und Verantwortlichkeiten. | |
| --- | |
| # Architektur und Teamstruktur | |
| Systemarchitektur und Teamstruktur beeinflussen sich gegenseitig. | |
| Wenn viele Teams ständig dieselben Komponenten ändern müssen, entstehen: | |
| - Abstimmungsaufwand, | |
| - Merge-Konflikte, | |
| - langsame Releases. | |
| Klare technische und organisatorische Grenzen können diesen Aufwand reduzieren. | |
| --- | |
| # Zukunftsfähige Softwareentwicklung | |
| Langfristig erfolgreiche Softwareentwicklung verbindet mehrere Eigenschaften: | |
| - klare Anforderungen, | |
| - einfache Architektur, | |
| - automatisierte Qualitätssicherung, | |
| - sichere Defaults, | |
| - reproduzierbare Deployments, | |
| - starke Observability, | |
| - kontrollierten KI-Einsatz. | |
| Je stärker Coding Agents und autonome Entwicklungssysteme werden, desto wichtiger wird die maschinenlesbare Beschreibung von: | |
| - Architekturregeln, | |
| - Tests, | |
| - Berechtigungen, | |
| - Deployment-Policies, | |
| - Qualitätsgrenzen. | |
| Damit wird Software Engineering zunehmend zur Disziplin, die nicht nur Menschen, sondern auch KI-Systeme zuverlässig durch komplexe Entwicklungsprozesse führt. | |
| # Häufige Fehler in der Softwareentwicklung | |
| ## Zu frühe Komplexität | |
| Ein System wird komplizierter als nötig. | |
| ## Fehlende Tests | |
| Änderungen werden riskant. | |
| ## Keine klare Architektur | |
| Verantwortlichkeiten verschwimmen. | |
| ## Zu viele Dependencies | |
| Wartung und Security werden schwieriger. | |
| ## Fehlende Observability | |
| Fehler sind schwer zu verstehen. | |
| ## Deployment ohne Rollback | |
| Fehlerhafte Releases werden riskanter. | |
| ## Security erst am Ende | |
| Schutz wird teuer und lückenhaft. | |
| --- | |
| # Softwareentwicklung-Checkliste | |
| Vor einem produktiven Release: | |
| 1. Sind Anforderungen klar? | |
| 2. Ist Architektur dokumentiert? | |
| 3. Sind kritische Pfade getestet? | |
| 4. Sind Security Checks vorhanden? | |
| 5. Sind Secrets geschützt? | |
| 6. Gibt es Monitoring? | |
| 7. Sind Logs sinnvoll? | |
| 8. Gibt es Rollback? | |
| 9. Sind Dependencies kontrolliert? | |
| 10. Ist Ownership definiert? | |
| 11. Ist Dokumentation vorhanden? | |
| 12. Ist das Deployment reproduzierbar? | |
| 13. Sind Datenmigrationen getestet? | |
| 14. Gibt es einen Incident-Prozess? | |
| 15. Ist die Anwendung skalierbar genug? | |
| --- | |
| # Zukunft der Softwareentwicklung | |
| Softwareentwicklung wird zunehmend durch Automatisierung und KI unterstützt. | |
| Wichtige Entwicklungen: | |
| - AI Coding, | |
| - Coding Agents, | |
| - automatisiertes Testing, | |
| - generative Dokumentation, | |
| - agentische DevOps-Prozesse, | |
| - Self-Healing Systems. | |
| Die Rolle von Entwicklern verschiebt sich dadurch stärker in Richtung: | |
| - Architektur, | |
| - Systemverständnis, | |
| - Review, | |
| - Qualität, | |
| - Produktdenken. | |
| --- | |
| # Softwareentwicklung in einer AGI-/ASI-Zukunft | |
| Auch bei sehr leistungsfähiger KI bleibt Software Engineering relevant. | |
| Die Tätigkeit könnte sich verändern. | |
| KI-Systeme könnten: | |
| - Code autonom erzeugen, | |
| - Systeme refaktorieren, | |
| - Tests schreiben, | |
| - Deployments planen. | |
| Trotzdem bleiben zentrale Fragen: | |
| - Welche Anforderungen gelten? | |
| - Welche Risiken sind akzeptabel? | |
| - Wie wird Verhalten validiert? | |
| - Wer trägt Verantwortung? | |
| - Wie wird ein System kontrolliert? | |
| Softwareentwicklung könnte sich dadurch von manueller Codierung hin zu **Systemsteuerung, Architektur und Verifikation** verschieben. | |
| --- | |
| # Häufige Fragen zur Softwareentwicklung | |
| ## Was ist Softwareentwicklung? | |
| Softwareentwicklung ist der strukturierte Prozess, Anforderungen in funktionierende, getestete und wartbare Software umzusetzen. | |
| ## Was ist Software Engineering? | |
| Software Engineering ist die ingenieurmäßige Disziplin hinter Planung, Architektur, Entwicklung, Test, Betrieb und Wartung von Software. | |
| ## Was ist der Unterschied zwischen Programmierung und Softwareentwicklung? | |
| Programmierung ist das Schreiben von Code. Softwareentwicklung umfasst zusätzlich Planung, Architektur, Testing, Deployment und Betrieb. | |
| ## Was ist Softwarearchitektur? | |
| Softwarearchitektur beschreibt die grundlegende Struktur eines Softwaresystems, seine Komponenten und deren Beziehungen. | |
| ## Was ist Clean Code? | |
| Clean Code ist verständlicher, klar strukturierter und wartbarer Code. | |
| ## Was ist DevOps? | |
| DevOps verbindet Entwicklung und Betrieb durch Automatisierung, gemeinsame Verantwortung und schnelle Feedbackzyklen. | |
| ## Was ist CI/CD? | |
| CI/CD automatisiert Integration, Tests, Build und Deployment von Software. | |
| ## Was ist eine API? | |
| Eine API ist eine definierte Schnittstelle zur Kommunikation zwischen Softwaresystemen. | |
| ## Was ist REST? | |
| REST ist ein Architekturstil für webbasierte APIs. | |
| ## Was ist ein Microservice? | |
| Ein Microservice ist ein kleinerer, unabhängig deploybarer Dienst innerhalb eines verteilten Systems. | |
| ## Was ist ein Monolith? | |
| Ein Monolith bündelt mehrere Funktionen in einer gemeinsamen Anwendung. | |
| ## Was ist Cloud-Native Development? | |
| Cloud-Native Development nutzt Architektur- und Betriebsprinzipien für automatisierte, skalierbare Cloud-Systeme. | |
| ## Was ist Testing? | |
| Testing prüft, ob Software erwartetes Verhalten zeigt und Fehler zuverlässig erkannt werden. | |
| ## Was ist Unit Testing? | |
| Unit Tests prüfen kleine isolierte Codeeinheiten. | |
| ## Was ist Code Review? | |
| Code Review ist die strukturierte Prüfung von Codeänderungen durch andere Entwickler oder ergänzende Tools. | |
| ## Was ist Technical Debt? | |
| Technical Debt beschreibt technische Kompromisse, die langfristige Wartungskosten erzeugen. | |
| ## Was ist Refactoring? | |
| Refactoring verbessert internen Code, ohne das externe Verhalten zu verändern. | |
| ## Was ist AI Coding? | |
| AI Coding nutzt KI-Systeme zur Unterstützung bei Codegenerierung, Debugging, Testing oder Dokumentation. | |
| ## Was ist ein Coding Agent? | |
| Ein Coding Agent ist ein KI-Agent, der mehrstufige Entwicklungsaufgaben in einem Repository bearbeiten kann. | |
| ## Was ist Agentic Software Engineering? | |
| Agentic Software Engineering beschreibt Entwicklungsprozesse, bei denen KI-Agenten aktiv planen, programmieren, testen und reviewen. | |
| ## Ersetzt KI Softwareentwickler? | |
| KI automatisiert Teile der Entwicklung. Architektur, Produktverständnis, Qualität, Security und Verantwortung bleiben zentrale Aufgaben. | |
| ## Welche Programmiersprache ist die beste? | |
| Es gibt keine universell beste Sprache. Die Wahl hängt von Plattform, Team, Performance und Ökosystem ab. | |
| --- | |
| # Glossar | |
| **API** | |
| Programmierschnittstelle zwischen Softwaresystemen. | |
| **CI/CD** | |
| Automatisierte Integration, Tests und Bereitstellung. | |
| **Clean Code** | |
| Verständlicher und wartbarer Code. | |
| **Cloud Native** | |
| Architektur- und Betriebsansatz für moderne Cloud-Systeme. | |
| **Coding Agent** | |
| KI-Agent für mehrstufige Softwareentwicklungsaufgaben. | |
| **DevOps** | |
| Verbindung von Entwicklung und Betrieb. | |
| **DevSecOps** | |
| Integration von Security in Entwicklung und Betrieb. | |
| **Full Stack** | |
| Entwicklung über Frontend und Backend hinweg. | |
| **Microservice** | |
| Kleiner, unabhängig deploybarer Service. | |
| **Monolith** | |
| Gemeinsam deployte Anwendung mit mehreren Funktionen. | |
| **Observability** | |
| Fähigkeit, Systemverhalten über Telemetrie zu verstehen. | |
| **Refactoring** | |
| Verbesserung interner Code-Struktur ohne Verhaltensänderung. | |
| **Softwarearchitektur** | |
| Grundstruktur eines Softwaresystems. | |
| **Technical Debt** | |
| Langfristige technische Kosten aus kurzfristigen Kompromissen. | |
| **Unit Test** | |
| Test einer kleinen isolierten Codeeinheit. | |
| --- | |
| # Geplante Hugging-Face-Spaces | |
| Die Organisation **Softwareentwicklung** kann eine kleine Anzahl praxisnaher deutschsprachiger Entwicklerressourcen bereitstellen. | |
| ## Softwareentwicklung Explorer | |
| **Geplant:** `softwareentwicklung/softwareentwicklung-explorer` | |
| Interaktive Übersicht über Architektur, APIs, Testing, DevOps, Security und AI Coding. | |
| ## Softwarearchitektur | |
| **Geplant:** `softwareentwicklung/software-architektur` | |
| Visuelle Referenz zu Monolithen, modularen Systemen, Microservices, Events und Cloud-Native Architecture. | |
| ## Softwareentwicklungs-Check | |
| **Geplant:** `softwareentwicklung/softwareentwicklungs-check` | |
| Interaktive Entscheidungshilfe für Architektur, Testing, Deployment, Observability und Security. | |
| ## Software Readiness | |
| **Geplant:** `softwareentwicklung/software-readiness` | |
| Reifegradanalyse für Codequalität, Architektur, Testing, CI/CD, Security und Betrieb. | |
| --- | |
| # Forschung und Kooperationen | |
| Wir sind offen für technische Kooperationen, Open-Source-Projekte, Benchmarks, Datasets und gemeinsame Ressourcen rund um Softwareentwicklung. | |
| Besonders interessant sind: | |
| - Software Engineering | |
| - Softwarearchitektur | |
| - APIs | |
| - Cloud-Native Development | |
| - DevOps | |
| - CI/CD | |
| - Testing | |
| - Secure Coding | |
| - Platform Engineering | |
| - Developer Experience | |
| - AI Coding | |
| - Coding Agents | |
| - Agentic Software Engineering | |
| - Software Reliability | |
| Willkommen sind: | |
| - Entwicklerteams, | |
| - Open-Source-Projekte, | |
| - Hochschulen, | |
| - Forschungseinrichtungen, | |
| - Softwareunternehmen, | |
| - Cloud- und DevOps-Plattformen, | |
| - Unternehmen mit Software- und KI-Anwendungsfällen. | |
| **Kooperationen & Kontakt:** [ki-agenten@magenta.de](mailto:ki-agenten@magenta.de) | |
| --- | |
| # Projektprinzipien | |
| **Verständlichkeit vor unnötiger Komplexität.** | |
| Gute Software ist nachvollziehbar und wartbar. | |
| **Architektur folgt Anforderungen.** | |
| Kein Architekturpattern ist automatisch richtig. | |
| **Tests sind Teil der Entwicklung.** | |
| Qualität sollte kontinuierlich geprüft werden. | |
| **Automatisierung reduziert manuelle Fehler.** | |
| Build, Test und Deployment sollten reproduzierbar sein. | |
| **Observability gehört zur Produktionsreife.** | |
| Ein System muss im Betrieb verstanden werden können. | |
| **Security beginnt beim Design.** | |
| Secure by Design ist wirksamer als spätes Nachbessern. | |
| **KI unterstützt Softwareentwicklung.** | |
| Coding Assistants und Agents können Produktivität erhöhen, ersetzen aber nicht Engineering-Verständnis. | |
| **Wartbarkeit ist langfristiger Wert.** | |
| Software wird über Jahre häufiger verändert als neu geschrieben. | |
| --- | |
| *Softwareentwicklung ist eine unabhängige deutschsprachige technische Hugging-Face-Ressource zu Software Engineering, Architektur, Programmierung, APIs, Testing, DevOps, Cloud-Native Development und AI Coding.* | |
| **Stand: September 2026** | |