INF-WebSE - Webentwicklung und Software Engineering

Erstelle ein Login-Formular mit E-Mail- und Passwortfeld; validiere clientseitig.

1. 01HTML

   ```html <form id="login" novalidate> <label>E-Mail <input type="email" name="mail" required></label> <label>Passwort <input type="password" name="pw" minlength="8" required></label> <button>Anmelden</button> </form> ```

2. 02JavaScript

   ```js const f = document.getElementById("login"); f.addEventListener("submit", e => { if(!f.checkValidity()) { e.preventDefault(); alert("Bitte korrekt ausfüllen"); } }); ```

3. 03Sicherheitshinweis

   Clientseitige Validierung NUR für UX; serverseitig muss IMMER erneut validiert werden (Angreifer können Client-Code umgehen).

Ergebnis: Funktionierendes Formular mit zwei Validierungsstufen; HTTPS und CSRF-Schutz sind separate Themen.

Wie entwickelst du ein Feature und mergest es zurück in main?

1. 01Branch erstellen

   `git checkout -b feature/login-redesign`

2. 02Commits machen

   `git add .` und `git commit -m "feat(login): neue Form-Validierung"` (Conventional Commits).

3. 03Push & PR

   `git push origin feature/login-redesign`; danach Pull Request auf GitHub/GitLab eröffnen.

4. 04Review

   Kollegen reviewen Code, fordern ggf. Änderungen, danach Approve.

5. 05Merge

   `git checkout main; git pull; git merge --no-ff feature/login-redesign; git push`. Tag für Release: `git tag v1.2.0`.

Ergebnis: Code-History bleibt linear nachvollziehbar; Conflicts werden früh im Feature-Branch gelöst, nicht in main.

Ein Team baut einen Online-Shop, dessen Anforderungen sich während der Entwicklung noch ändern werden. Begründe die Methodenwahl und skizziere den ersten Scrum-Sprint.

1. 01Anforderungslage einschätzen

   Die Anforderungen sind unklar und veränderlich → ein sequenzielles Wasserfallmodell wäre riskant (späte Änderungen sind teuer); Scrum passt besser.

2. 02Backlog priorisieren

   Der Product Owner ordnet das Product Backlog: zuerst Produktkatalog und Warenkorb, später Bezahlung, zuletzt Wunschliste.

3. 03Sprint Planning

   Das Team wählt für einen 2-Wochen-Sprint die obersten Items, die es realistisch schafft (z. B. Produktliste und Detailseite).

4. 04Sprint + Daily

   Während des Sprints synchronisiert sich das Team täglich im Daily (15 min); Aufgaben wandern auf dem Board von „To Do" über „Doing" zu „Done".

5. 05Review & Retrospektive

   Am Sprintende zeigt das Team das lauffähige Increment (Review, Feedback vom PO bzw. Kunden) und verbessert in der Retrospektive die Zusammenarbeit.

Ergebnis: Bei veränderlichen Anforderungen ist Scrum überlegen, weil jeder Sprint ein nutzbares Increment liefert und Feedback früh einfließt. Wasserfall bliebe nur bei stabilen, vorab vollständig bekannten Anforderungen sinnvoll (z. B. sicherheitskritische Steuerungssoftware).

Teste die Funktion `is_palindrome(s)`.

1. 01Implementierung

   ```python def is_palindrome(s): s = s.lower() return s == s[::-1] ```

2. 02Tests

   ```python import pytest from solution import is_palindrome def test_empty(): assert is_palindrome("") def test_single(): assert is_palindrome("a") def test_pal_lower(): assert is_palindrome("anna") def test_case_insensitive(): assert is_palindrome("Anna") def test_non_pal(): assert not is_palindrome("python") ```

3. 03Ausführung

   `pytest -q` -> alle 5 Tests grün.

Ergebnis: Tests dokumentieren Erwartungen und schützen vor Regressionen; jeder neue Bug bekommt erst einen failing test.