dhbw: import original web-eng inhalte (testing, typescript, docker, best practices) + framework-übersicht, native html, prüfungsleistung-detail, sose 2026

This commit is contained in:
2026-05-06 18:28:20 +02:00
parent 73be35ccb8
commit 96362e2959
9 changed files with 1889 additions and 9 deletions

View File

@@ -0,0 +1,346 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Web Engineering DHBW Stuttgart"
footer: "Michael Czechowski SoSe 2026"
title: Best Practices
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #005f8a;
--color-dimmed: #4a6a7a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #005f8a;
}
section.invert h1 {
color: #fff;
}
pre {
background: #0f1e2e;
color: #00b4d8;
border-radius: 8px;
border-left: 3px solid #005f8a;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a3a4a;
color: #00b4d8;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
</style>
<!-- _class: invert -->
<!-- _header: '' -->
<!-- _backgroundColor: #001520 -->
# Best Practices
## Wrap-up & Projektsupport
---
# Inhalt
1. Semantic Versioning
2. Git Commit Messages (Udacity Style)
3. 12 Factor App
4. Make it Work · Make it Right · Make it Fast
5. Präsentations-Tipps
6. Feedback (Sandwich-Methode)
7. Prüfungsleistung Recap
---
# Semantic Versioning (SemVer 2.0.0)
```
MAJOR.MINOR.PATCH
│ │ └─ Bugfix, abwärtskompatibel
│ └────── Neue Funktion, abwärtskompatibel
└──────────── Breaking Change
```
**Beispiele:**
- `1.4.2``1.4.3` Bugfix
- `1.4.3``1.5.0` neues Feature
- `1.5.0``2.0.0` Breaking Change
Pre-Release: `1.0.0-alpha.1`, `1.0.0-rc.2`
→ https://semver.org/
---
# package.json: Versionsranges
```json
{
"dependencies": {
"express": "^4.19.2", // ≥4.19.2 < 5.0.0 (gleiche MAJOR)
"lodash": "~4.17.21", // ≥4.17.21 < 4.18.0 (gleiche MINOR)
"react": "19.0.0" // exakt
}
}
```
`package-lock.json` pinnt die **tatsächlich installierten** Versionen.
---
# Git Commit Messages Udacity Style
```
<type>: <Subject>
<blank>
<Body>
<blank>
<Footer>
```
**Type:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`
**Subject:** Imperativ, ≤50 Zeichen, klein, kein Punkt
**Body:** **Was** und **Warum** nicht **Wie**
**Footer:** Issue-Refs, Breaking Changes
---
# Commit-Beispiele
**Gut:**
```
feat: add user logout endpoint
Allows authenticated clients to invalidate their session token
on the server side instead of only deleting the cookie.
Closes #142
```
**Schlecht:**
```
fixed stuff
WIP
update
asdf
```
→ https://udacity.github.io/git-styleguide/
---
# Conventional Commits
```
feat(auth): add OAuth2 login
fix(api): return 404 instead of 500 on missing user
docs: update README install steps
chore(deps): bump express from 4.18 to 4.19
BREAKING CHANGE: drop Node 16 support
```
Vorteile: automatische Changelogs, automatische Version-Bumps (`semantic-release`).
---
# 12 Factor App
Methodik für moderne, skalierbare SaaS-Apps https://12factor.net/
| # | Faktor |
|---|--------|
| 1 | Codebase ein Repo, viele Deploys |
| 2 | Dependencies explizit deklariert (`package.json`) |
| 3 | Config via Environment-Variablen |
| 4 | Backing Services als Attached Resources |
| 5 | Build, Release, Run getrennt |
| 6 | Processes stateless |
---
# 12 Factor (2/2)
| # | Faktor |
|---|--------|
| 7 | Port Binding self-contained, exportiert HTTP |
| 8 | Concurrency horizontal skalieren via Prozesse |
| 9 | Disposability schneller Start, Graceful Shutdown |
| 10 | Dev/Prod Parity möglichst gleiche Umgebung |
| 11 | Logs als Event-Streams (`stdout`) |
| 12 | Admin Processes als One-Off |
---
# Config via ENV
```javascript
// schlecht
const db = "postgres://user:secret@prod-db:5432/app";
// gut
const db = process.env.DATABASE_URL;
```
```bash
# .env (NICHT committen!)
DATABASE_URL=postgres://user:secret@db:5432/app
NODE_ENV=production
PORT=8080
```
`.env.example` mit Dummy-Werten committen.
---
# Make It Work · Right · Fast
```
1. Make It Work → MVP, hässlich aber funktional
2. Make It Right → Refactor, Tests, Clean Code
3. Make It Fast → Profiling, Optimierung
```
Don't optimize what doesn't work.
Don't refactor what isn't working yet.
→ https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
---
# KISS · DRY · YAGNI · SOLID
- **KISS** Keep It Simple, Stupid
- **DRY** Don't Repeat Yourself
- **YAGNI** You Aren't Gonna Need It
- **SOLID**:
- **S**ingle Responsibility
- **O**pen/Closed
- **L**iskov Substitution
- **I**nterface Segregation
- **D**ependency Inversion
→ Faustregeln, keine Dogmen.
---
# Präsentation Aufbau
- **Einstieg** mit aktuellem Bezug (optional)
- **Problemdefinition**: welches Bedürfnis / welches Problem?
- Was hat **blockiert**, wie gelöst?
- **Geschichte mit Spannungsbogen**
- Vorher klären: Fragen während oder nach der Präsentation?
---
# Präsentation Pitfalls
- Am Thema vorbeireden
- Folien vorlesen
- Live-Demo ohne Backup-Video
- "Sieht man hier nicht so gut, aber..."
- Zu viel Text pro Folie
- Keine klare Botschaft pro Slide
**1 Folie = 1 Aussage.**
---
# Feedback Sandwich-Methode
```
🍞 Lob / Positives
🥬 Kritik + konkreter Verbesserungsvorschlag
🍞 Lob / Abschluss
```
**Pitfalls:**
- Am Thema vorbeireden
- Bei Unklarheiten keine Fragen stellen
- Subjektives Feedback ("Farbe gefällt mir nicht")
**Konkret, sachlich, umsetzbar.**
---
# Prüfungsleistung Recap
**Grundanforderungen (75 Punkte):**
| Punkte | Kriterium |
|--------|-----------|
| 20 | Idee, Konzeption, Planung |
| 5 | Plattformunabhängigkeit |
| 25 | Clean Code (KISS, SOLID, DI, Testing, Error Handling) |
| 15 | Präsentation |
| 10 | Dokumentation (README, etc.) |
**Zusatzpunkte (max. 10):** TypeScript, Docker, Dev/Prod-Parity, `.env`, npm-Publish, Domain, HTTPS, Responsive Design.
→ https://git.dailysh.it/DHBW/pruefungsleistung
---
# Abgabe + Termine
- **Code-Upload:** bis 27.07.
- **Präsentation:** 17.07. (in Gruppen, ~10 Min)
- Pitch (~1 Min)
- Agenda
- Idee / Problem
- Learnings & Pitfalls
- "It is what it is" Doku
---
# 70 Things I Regret as a Developer (Auswahl)
- Nicht früher Tests geschrieben zu haben
- Zu viel Zeit mit "perfektem" Setup statt Code
- Nicht öfter `git commit`
- Nicht früher in Pull Requests reviewt
- Keine Doku gepflegt
- Eigene Lösungen für Standard-Probleme
- Frameworks gehyped, Grundlagen vernachlässigt
- "Funktioniert bei mir" akzeptiert
→ Lehre: **Disziplin > Talent.**
---
# Weiterlesen
- https://12factor.net/
- https://semver.org/
- https://udacity.github.io/git-styleguide/
- https://www.conventionalcommits.org/
- https://refactoring.guru/
- https://martinfowler.com/
- MDN Web Docs · web.dev · web.dev/learn
---
<!-- _class: invert -->
<!-- _backgroundColor: #001520 -->
# Viel Erfolg mit den Projekten!
Fragen? Probleme? → Telegram, Mail, Sprechstunde.