public/uni
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6e41b8c3ebdfe30d43422fc11ef18bb851cff49f
uni/slides/dhbw/08_best_practices.md

6.7 KiB
Raw Blame History

marp, theme, paginate, backgroundColor, header, footer, title
marp theme paginate backgroundColor header footer title
true gaia true Web Engineering – DHBW Stuttgart Michael Czechowski – SoSe 2026 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>

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

{
  "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

// schlecht
const db = "postgres://user:secret@prod-db:5432/app";

// gut
const db = process.env.DATABASE_URL;

# .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:
    • Single Responsibility
    • Open/Closed
    • Liskov Substitution
    • Interface Segregation
    • Dependency 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

Viel Erfolg mit den Projekten!

Fragen? Probleme? → Telegram, Mail, Sprechstunde.