Lerntagebuch-erstetag/Lerntagebuch.md

## Lerntagebuch

Das ist ein Beispiel wie ein Lerntagebuch aussehen könnte.

## SU 01(21.10.2021)

### Lernziel

- Organisatorisches
- Versionskontrollsysteme allgemein
- git
- Vorteile
- wie lege ich ein Repository an
- vim (ein paar alltägliche Befehle)

### Erkenntnis

Versionskontrolle werden wir im Projekt einsetzen, um
zu jeder Zeit den Entwicklungsstand einzusehen und paralleles Arbeiten an Dateien zu ermöglichen. Sollten Probleme an der Software auftreten, können wir zu einem funktionierenden Stand wechseln und durch das Commit-Log die Ursache ausfindig machen.
Außerdem kann ich als Developer mit den gelernten vim-Befehlen vor den anderen flexen.

### Kritik

`git status` zeigt mir einen groben Zustand meines Git-Repositorys an. Manchmal werden Dateien oder Verzeichnisse dort rot oder grün angezeigt. Die grünen
Dateien verschwinden von der Ausgabe, wenn ich `git commit`
ausführe. Rote Dateien werden mit `git add` grün.

### Mitteilung

an die Dozierenden Da dieser Punkt optional ist, lasse ich ihn
weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es
hier anmerken.

---

## Uebung 01 (27.10.2022)

### Lernziel

- SSH-Zugriff-zum-git-server-konfigurieren
  - SSH key pair generieren
  - oeffentlichen SSH key im Repository eintragen
  - Lokale Kopie auf SSh-Zugriff umstellen
  - Neue lokale Repositories

### Erkenntnis

- einen ssh-key erstellt
- öffentlichen Schlüssel zu gogs hinzugefügt
- Master Branch erstellt

### kritik

man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs SSH-Remote-Repository-Link ändern.

### Mitteilung

---

## Übung 02 (2.11.2022)

### Lernziel

- legen Sie in Ihrem Repository die Datei Programmierparadigmen.md an.
- Analysieren Sie die Programmiersprachen Java,C,Python,go,JavaScript und TypeScript hinsichtlich der in der Vorlesung genannten Kriterien und Schreiben sie ihre Analyse in Stichpunkten in die neu erstellte datei.
- Suchen Sie im Internet nach weiteren Programmierprinzipien und dokumentieren sie diese (Acronym, Langbezeichnung, Beschreibung) in der Obigen Datei.

### Erkenntnis

Ein neu Datei als Programmierparadigmen.md an Gitea hochgeladet.

### Kritik

Programmierprinzipien

- SOLID
- STUPID
- KISS (Keep It Simple & Stupid)
- FCoH (Favor Composition over Inheritance)
- YAGNI (You Ain't Gonna Need It)
- IOC (Inversion Of Control)
- DI (Dependency Injection)
- DRY (Don't Repeat Yourself)
- DYC (Document Your Code)
- Clean Code at All Cost

### Mitteilung

---

## Übung 3 (16.11.2022)

clone link <https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeuge-public/UebungDebugging.git>

### Lernziel

- Führen Sie die Übung entsprechend den Anweisungen in der README.md-Datei aus.
- Debugging

### Erkenntnis

**Task 1 Uebung 1**

- Nachdem Aktivieren Sie die Zeilen 36 bis 38 durch entfernen der beiden _slashes_.
  **Ausgaben sind:**
  enter an integer number: 5
- input: 5, Schleifenvariable: 2, Ergebnis 1
- input: 5, Schleifenvariable: 3, Ergebnis 2
- input: 5, Schleifenvariable: 4, Ergebnis 1
- number 5 passed check: true%

enter an integer number: 34

- input: 34, Schleifenvariable: 2, Ergebnis 0
- number 34 passed check: false%

enter an integer number: 89

- nachdem schleifen es gibt
- number 89 passed check: true%

Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt

- die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1

Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47

- die Inhalte der Variablen sind nextInt: 47, i:2, ergebnis:1 dann nextInt: 47, i:3, ergebnis:2
- am ende nextInt: 47, i:46 Ergebnis:1 check: true

**Task 2 Uebung 2**

Öffnen Sie das programm `Uebung2.java` im Editor

- Starten Sie das Programm mehrfach (_"run as Java Application"_) und geben Sie verschiedenen natürliche Zahlen ein.
  
  - **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt**

- setzen Sie einen BreakPoint in Zeile 40

- Starten Sie das Programm wie bisher

- Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein

- Notieren Sie die Inhalte der Variablen (this) nextInt: 23
  
  - this: **Uebung2@8**
  - count: **3**

- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this): **this, count, in, out in total 4 mit Zwischenüberschritt**

- in welcher Zeile steht der Debugger? 34->36

- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this)
  
  - nextInt: **45**, count: **2**

- in welcher Zeile steht der Debugger? **40**

- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) false
  
  - nextInt: **16**, count: **4** ergebnis: **false**

**Beenden Sie den Debugger (_"Terminate"_)**

### Kritik

### Mitteilung

---

## Uebung 4 (23.11.2022)

### Lernziel

Lokale Respository

- Stage und Historic
- Merge
- rebase

### Erkenntnis

### kritik

### Mitteilung

---

## SU 07 (07.12.2022)

### Lernziel

- Relvante Literatur
- Motivation
- Grundlagen
- Testmethodologie
- TestProzess
- Psychologische Aspekte

### Erkenntnis

**Testmethodoligie - Bestandteile eine Tests**

- Stichprobe
  - Testfälle
  - Testdaten
- Testobekt
- Testumgebung
- Testziel
- Soll-/Ist- Wertvergliech

**Testziele**

- Fehler aufzeigen
- Qualität erfassen
- Vertrauen erhöhen
- Grenzen ermitteln

**Testebenen**

- Anwendung/System
- Teilsystem/Modul
- Codeebene/Unit

**Testpyramide**

- GUI Tests (end to end tests)
  business logik überprufen, functions und kommiunikation mit anderen components überprufen.

- Integration tests

- Component / Contract Tests

- Unit Tests

**Testnamen**

Test werden benannt nach:

- Ziel (Integration Test, Lasttest)
- Methode (Regressionstest)
- Testgegenstand (UI-test, Module-test, Unit-test)
- Level (Systemtest)
- Personen (Entwicklertest, Anwendertest)
- Testabdeckung (Komplettest, partieller Test)

**Qualitätskosten**

- High Cost -> Poor Quality -> Failure Costs
- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost)
- Low Cost -> Exceptional Quality -> prevention & Appraisal Cost

**Testprozess**

**Testprozess - Ablauf**

**Testprozess - Plannung**

**Testprozess - Analyse & design**

- basiert auf Anforderungsdokumentation
- Testspezifikation
  - Testfaelle
    - Kritikalitaet
    - Testdaten
    - Testumgebung
  - Ausfuehrungsreihenfolge
  - Infrastruktur
  - Testkriterium

**Testprozess - Testausfuerung**

Testlog

- aufgetretenes Fehlverhalten
- Fehlerkategorie (high/medium/low)

**Testprozess - Testnachbereitung**

- Testreport
- Zusammenfassung Testausfuehrungen
- Vergleich mit frueheren Testlaeufen
- Entscheidung ueber Lieferfaehigkeit

### kritik

### Mitteilung

---

## SU (14.12.2022)

### Lernziel

- Automatisiertes Testen von Software
  - Motivation
  - Grundlegen
  - UnitTests
  - Anforderungen an zu testenden Code

### Erkenntnis

**Motivation** - _warum automatiestert Testen?_
Probleme manuellen Testens

- Testfähigkeit der Software
- Wiederholbarkeit
  - nachlassende Aufmerksamkeit
  - unterschiedlicher Kontetn verschiedener Tester:Innen
  - Überlappungen / Lücken bei der Testausführung
- Fehlerzustände Testen
- Wissen der Tester:Innen
  - unvollständige Testdokumentation, setzt implizites Wissen voraus
  - Bedienung der Anwendung
  - Bedienung der Testwerkzeuge
- Aufwand
  - langsam
  - Arbeitszeit

**Motivation** - _Qualitätskosten_

**Motivation** - _Gründe gegen Automatisiert Tests_

Wie kann ich das testen?

- nur User interface
- prettier Code
- Keine Tests
  Persönliche, technische und Soziale Voraussetzungen
- UnitTests schreiben ist eine Fertigkeit und muss ständig geübt werden.
- Technische Voraussetzungen müssen sichergestellt sein.
- Team und Vorgesetzte müssen automatisiertes Testen unterstützen.

Für jedes Verhalten, das wir bei einer Person beobachten ist deren Umfeld perfekt daraus ausgereichtet, dieses Verhalten zu fördern.

---

**Grundlagen** - _Wleche Tests automatisierien?_

- häufige Wiederholung
- hohe Anzahl
- hohe Kritikatiltät
- hohe Stabilität
- Unittests
- Modultests
  - Integrationstest
  - Regressionstest
- ApplicationTests
  - Integrationstest
  - Regressionstest
  - Lasttests
  - Acceptance-Tests

**Unterschied Application / Module-Tests zu UnitTests**
_Appplication und Module_

- werden spät im entwicklungsprozess ausgeführt
- Testwerkzeuge sind Komplex
- sind aufwendig zu warten
- zeigen, das ein Fehler existiert

_UnitTest_

- laufen früh im Entwikclungsprozess (idealer Weise nach jedem Spiechern)
- Werkzeuge haben einfache API
- sind stabil gegen Änderungen(anderer Units)
- zeigen welche Anforderung nicht erfüllt wird, wo der Fahler existiert und unter welchen Bedigungen er auftritt.

---

**_UnitTests_**

Was macht ein Unittest?

- Unittests sind ausführbare Dokumentation.
- Unittest testen keinen Code.
- Unittest verifizieren von außen beobachtbares gewünschtes Verhalten von Code.
  Sie prüfne Rüchgabewerte und kommuikation mit anderen Units des zu testenden Codes als Reacktion auf die übergebenen Parameter und/oder den Reaktionen der anderen Units.
- Ein einzelner Test prüft genau eine Erwartung an die Unit.
- Unittests verhindern ungewollte Änderungen.

**_Wie schreibt man einen guten Unittest?_**

**F**ast - schnell
Kann nach jedem speichern ausgeführt werden ohne den Arbeitsablauf zu verzögern.

- primitive Vorbereitung (setup)
- Abhängigkeiten durch Test-Doubles ersetzen

**I**ndependent - unabhängig
Jeder Test kann einzeln ausgeführt werden.

- kein Test schafft Voraussetzungen für nachfolgende
- Test können in beliebiger Reihenfolge laufen

**R**epeatable - wiederholbar
Jede Ausführung (ohne Änderung des getesteten Codes) führt zum selben
Ergebnis.

- nicht von zufälligen Größen abhängig
- kein Einfluß durch Änderungen an anderen Units
- kein Einfluß durch Testumgebung (Netzwerk, Festplatte, Position in der Verzeichnisstruktur)

**S**elfevaluating - selbstauswertend
Das Testergebnis ist eindeutig und binär.

- Erfolg oder Mißerfolg sind eindeutig erkennbar
- Ergebnis muss nicht in Logdateien o.ä. gesucht werden
- Ergebnis kann automatisiert weiter verarbeitet werden

**T**imely - zeitnah
Unittests entstehen zeitnah zum getesteten Code.

- Code first
  Tests werden nach dem zu testenden Code geschrieben.
- Test first
  Tests werden vor dem zu testenden Code geschrieben.
- Test Driven Developement
  Test und verifizierter Code entstehen gleichzeitig

**R**eadable - was bedeutet _lesbar_?

- was wird getestet
  Name des Test drückt Vorbedingungen und erwartetes Ergebnis aus.
- Kurz
  wiederkehrende Vorbereitungen im Methoden auslagern
- Welche Eigenschaften der Parameter sind wichtig?
  Explizit Variablen für Parameterwerte anlegen
  Variablennamen sorgsam wählen
- Welche Eigenschaften der Ergebnisse sind wichtig?
  Explizit Variablen für Ergebnisse anlegen
  Variablennamen sorgsam wählen
  verifizierungsmethoden mit sprechenden Namen.

**T**rustworthy - Was bedeutet vertrauenswürdig?

- Geschäftsanforderungen erfüllt
  Wurde tatsächlich implementiert, was der Kunde wollte?
- technisch
  Wird der Produktivcode tatsächlich ausgefühtrt?
  - "test first"
    Schlägt der Test aus dem richtigen Grund fehl?
  - Ersetzten von Abhängigkeiten(Mocking)
  - (weitestgehend) keine Logik in Tests

**F**ast
(schone erklärt)

**M**aintainable - Was bedeutet wartbar?

- Stabilität gegenüber Anderungen in anderen Units
  Abhängigkeiten ersetzen
- stabil gegen Änderungen in der Unit selbst
  eine einzelne Anforderung (nicht Codestelle) testen.

---

**_Anforderungen an zu testenden Code_**

- Was verbessert die Testbarkeit?
- Isolieren einer Unit
- Isolation Ermöglichen

---

_Testbarkeit von production Code_

Qualität des producktivem code (im Sinne von "Clean Code" und dem "S.O.L.I.D" prinzip) beeinflußt die Qualität der Tests (im Sinne der RTFM - Anforderungen)

die wichtigsten "Clean Code" Regeln sind:

- Separation of Concerns / single responsibility
  Erzeugung von Objekten der Abhängigkeiten ist keine aufgabe der Geschäftslogik!
- Dependency Inversion
- Tell! Don´t ask.
- Law of Demeter (Don´t talk to strangers)
  vermeide "message chaining" (nicht mit "fluent API" verwechseln)

_Arten von Test-Doubles_

- Stub
  - leere Implementierung einen Schnittstelle, üblicher Weise generiert
- Fake
  - alternative Implementierung einer Schnittstelle oder Erweiterung einer existerenden Implementierung.
  - exterm vereinfachtes Verhalten(keine Logik)
- Mock
  - "aufgemotztes" Fake
  - konfigurierbares Verhalten
  - Verifizierung vom Methodenaufrufen und der übergebenen Parameter

_Was Ermöglicht die Ersetzung von Abhängigkeiten?_

- trenne Instanyiierung der Abhängigkeiten von der Geschäftslogik
- vermeide den Aufruf des **_new_** Operators
- Bereitstellen von "seams" (Nahtstellen)
  - dependencz injection
  - Getter mit geringer Sichtbarkeit
- keine **static** (public) Methoden
- keine **final** (public) Methoden
- vermeide _Singelton Pattern_ (nicht Singelton als Konzept)

_Schreibe "Clean Code"_

- programmiere gegen Schnittstellen
- SoC/ SRP (Feature envy)
- Law of Demeter
- DRY
- same level of abstraction

### kritik

### Mitteilung

---

## SU (21.12.2022)

### Lernziel

Test Driven Development

- Relevante Litratur - Growing Object-Oriented Software, Guided by Tests von Steve Freeman, art of unit Testing von Michael Feathers
- Motivation
- Grundlagen

### Erkenntnis

**Motivation** - _Qualitaetskosten_

**Motivation** - _Welche Tests automatisieren?_

- Haeufige Wiederholdung
- hohe Anzahl
- hohe Kritikatiltaet
- hohe Stabilitaet
  Unittests sind die vorherrschende Testart

_Wie schreibt man einen guten UnitTest?_

- Fast
- Independent
- Repeatable
- Selfevaluating
- **Timely**
- Readable
- **Trustworthy**
- Fast
- Maintainable

Timely - zeitnah

**Unittests entstehen zeitnah zum getesteten Code.**

- Code First
  Test werden nach dem zu testenden Code geschreiben.
- Test first
  Test werden vor dem zu testenden Code geschreiben.
- Test Driven Development
  Test und verifizierter Code entstehen gleichzeitig.

**Motivation** - _Fazit_

Unittests sind die am häfigsten zu erstellenden automatisierten Tests und Test Driven Development ist die geeignetste Vorgehensweise zu deren Erstellung.

**Grundlagen** - _Testabdeckung_

- oft als KPI (key performance indicator) missbraucht
- wichtig für ddie Beurteilung der Vertrauenswürdigkeit des Testhareness
- TDD führt zu hoher testabdeckung, aber nicht zu 100% ( realistisch 70% bis 90%)
- **TDD führt zu 100% Anforderungsabdeckung**

**Grundlagen** - _Vorgehen_

- Formalisierung des Entwicklungsprozesses
- inkrementelle Entwickliung des Code in "Baby-steps"
- verhindert _Flow_

**Grundlagen** - _TDD micro cycle_

- Schreiben einen neuen Test, gerade so viel dass er fehl schlägt ( nicht kompilieren ist Fehlschlagen).
- Schreiben gerade so viel Produktivcode, dass der Test erfüllt wird.
  Zukünftige Anforderungen nicht beachten! (so simpel wie möglich, alles ist erlaubt, Transformations-Prämissen beachten).
- Verbessere den Code (Produktion und Test), ohne einen Test zu brechen und ohne neue Funktionalität (Geschäftslogik) hinzuzufügen.

### kritik

Schreibe Code im TDD cycle.

### Mitteilung

--------------------------------------------------------------------------------

## SU (19.01.2023)

### Lernziel

#### Continous Integration

- Relavante Literatur
- Bedeutung von CI im Softwareentwicklungsprozess
- Aufbau eines CI/CD-Systems
- Ablauf des CI-Prozesses
- Rolle von automatisierten Tests

### Erkenntnise

#### Bedeutung von CI im Softwareentwicklungsprozess

**Größe von Software-Projekten**
- steigende Komplexität
- mehrere Entwickler
- Zusammenführen der Einzelleistungen

Z**usammenführen der Einzelleistungen**
- Widerspruch Kreativität vs. Konformität
- technische Konflikte
- persönliche Konflikte
- Aufwand

**Vorteile von CI Systemen**
- formale Prozesse verringern
- automatisierte Prozesse verringern Aufwand
- Vorstufe zu Continous Delivery

**Aufbau eines CI/CD-Systems**

- Entwicklungsumgebung des Programmierers
- Source Code Management System (SCM)
- Abhängigkeitenverwaltung
- build – Werkzeug
- Continous Integration Server
- Erweiterungen für Continous Delivery

**Entwicklungsumgebung des Programmierers**

**Integrated Developement Environment (IDE**)
- Syntax highlighting
- Syntax-Vervollständigung
- automatisierte Refactorings
- Navigation
- Compile–Parameter
- Code automatische Formatierung
- Fehler-Lokalisierung

**Source Code Management System (SCM)**
- Sicherung der Arbeit einzelner Entwickler
- zentrale Verfügbarmachung
- Zusammenführung parallel geänderter Dateien
- parallele Entwicklung verschiedener Features ermöglichen
- Zugriff auf dedizierte Stände (releases)
- wechsel zwischen Entwicklungsständen

**Abhängigkeitenverwaltung**
- nicht selbst im Build-Lauf erzeugt
- zentrale Bereitstellung (innerhalb der Organisation)
- Zugriff auf einzelne Versionen

**build – Werkzeug**
- Übersetzen
- Liefer-Artefakte erzeugen
- Abhängigkeiten organisieren
- automatisierte Tests ausführen
- Deploymen

**Continous Integration Server**
- SCM überwachen
- build-Prozess starten
- Ergebnisse berichteten

**Erweiterungen für Continous Delivery**
- Staging System
- Produktions System

**Ablauf des CI-Prozesses**
- Checkin Change
- Fetch Change
- Build
- Test
- Ergebnisauswertung
- Benachrichtigung

**Checkin Change**
- veröffentlichen der Änderung
- eigener branch
- alle aktuell veröffentlichten Änderungen integriert.
- vollständige Änderung
  - compiliert lokal
  - automatisierte (Unit–)Tests sind ”grün”
  - Lieferobjekt kann lokal gebaut werden

**Fetch Change**
- Änderungen feststellen
- zeitgesteuert
- ereignisgesteuert

**Build**
- Änderung mit aktuellem Stand integrieren (merge)
- compile (Produktivcode und Testcode)

**Test**
- nur nach erfolgreichem compile
- Testframework starten
- Ergebnisse sammeln

**Ergebnisauswertung**
- Ermittelt Status von merge, compile und Test
- Erfolgsfall: Änderung als neuen aktuellen Stand übernehmen undveröffentlichen
- Ergebnisdarstellung als Webseite


**Benachrichtigung**
- zeitnah
- Fehlerfall: Committer
- Erfolgsfall: alle
- mögliche Wege:
  - Mail
  - RSS-Feed
  - SMS
  - Twitter
  - WhatsApp


**Rolle von automatisierten Tests**
- Problem des Continous Integration
- Vorteile automatisierter Tests
- Grenzen automatisierter Tests 

**Problem des Continous Integration**
- compilierbar ! = ausführbar
- CI soll immer lieferbaren Stand bereit halten
- Programm muss im CI Prozess ausgeführt werden

**Vorteile automatisierter Tests**
- automatisierte Tests führen Programm aus
- dokumentieren gewünschtes Verhalten
- sind wiederholbar
- erkennen Laufzeitfehler (außer UnitTests)
- Ausführungszeit von Arbeitszeit entkoppelt


**Grenzen automatisierter Tests**
- finden nur Abweichungen von gewünschten/bekanntem Verhalten
- finden keine neuen fachlichen Fehler

### Kritik

### Mitteilung



----------------------------------------------------------------------------------
## SU (26.01.2023)

### Lernziel
**Inhalte**
- Motivation
- Klassen
- Vererbung
- OOP Algorithmen

### Erkenntnise

**Motivation**
- Wiederverwendung von Code im Fokus
- OOP oft auf Vererbung reduziert
- Anwendung prozeduraler Algorithmen
- Vererbung als Selbstzweck → Unnötige Vererbung

**OOP ist ein eigenständiger Ansatz der Problem-lösung der eine andere Denkweise erfordert.**

**Klassen **-
- Eigenschaften / Zustand
- private Methoden
  - Strukturierung der Implementierung
  - erleichtern Verständnis
- öffentliche Methoden
  - Manipulation des Zustandes (Änderung von Eigenschaften)
  - spezifisches Verhalten, mit dem sie sich von anderen Klassen unterscheidet unabhängig vom Zustand

**Vererbung** -
- abgeleitete Klasse erweitert Basisklasse
- modelliert eine ”ist ein” Beziehung
- geändertes Verhalten

**OOP Algorithmen** -
- Primitive Type Obsession (PTO)
- falsche Verantwortlichkeiten
- Arrays vs. Collections

**Vorteile des OO Ansatzes:**
- leichter erweiterbar
- Range-Checks nur während Initialisierung → Zeiteinsparung zur Laufzeit.
- nur wenige Zellen werden betrachtet
  → Geschwindigkeit hängt nur von Anzahl lebender Zellen ab.
Nachteile des OO Ansatzes:
- 5 Klassen statt einer, 3 mal mehr Code
- nutzt zahlreiche fortgeschrittene Sprachfeatures

### Kritik

### Mitteilung