diff --git a/Lerntagebuch.md b/Lerntagebuch.md index 5b49405..85b7427 100644 --- a/Lerntagebuch.md +++ b/Lerntagebuch.md @@ -1,253 +1,506 @@ ## Lerntagebuch - # Mein Lerntagebuch für Programmiermethoden und -werkzeuge - 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. +Das ist ein Beispiel wie ein Lerntagebuch aussehen könnte. - ### Mitteilung - +## SU 01(21.10.2021) +### Lernziel - ## Ü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 +- 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 - **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% +### Erkenntnis - enter an integer number: 34 - - input: 34, Schleifenvariable: 2, Ergebnis 0 - - number 34 passed check: false% +- einen ssh-key erstellt +- öffentlichen Schlüssel zu gogs hinzugefügt +- Master Branch erstellt - enter an integer number: 89 - - nachdem schleifen es gibt - - number 89 passed check: true% +### kritik - Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt - - die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1 +man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs SSH-Remote-Repository-Link ändern. - 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 +### Mitteilung - **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. +## Übung 02 (2.11.2022) - - **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt** +### 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. - - 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** +### Erkenntnis - - 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** +Ein neu Datei als Programmierparadigmen.md an Gitea hochgeladet. - **Beenden Sie den Debugger (*"Terminate"*)** +### Kritik - ### Kritik +Programmierprinzipien - ### Mitteilung +- 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 +### Lernziel +- Führen Sie die Übung entsprechend den Anweisungen in der README.md-Datei aus. +- Debugging - ## Uebung 4 (23.11.2022) - ### Lernziel - Lokale Respository - - Stage und Historic - - Merge - - rebase +### 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% - ### Erkenntnis +enter an integer number: 34 - ### kritik +- input: 34, Schleifenvariable: 2, Ergebnis 0 +- number 34 passed check: false% - ### Mitteilung +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 - ## SU 07 (07.12.2022) +- die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1 - ### Lernziel - - Relvante Literatur - - Motivation - - Grundlagen - - Testmethodologie - - TestProzess - - Psychologische Aspekte - - ### Erkenntnis - **Testmethodoligie - Bestandteile eine Tests** +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** - - Stichprobe - - Testfälle +- 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 - - Testobekt - - Testumgebung - - Testziel - - Soll-/Ist- Wertvergliech + - 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?* - **Testziele** +- häufige Wiederholung +- hohe Anzahl +- hohe Kritikatiltät +- hohe Stabilität +- Unittests +- Modultests + - Integrationstest + - Regressionstest +- ApplicationTests + - Integrationstest + - Regressionstest + - Lasttests + - Acceptance-Tests - - Fehler aufzeigen - - Qualität erfassen - - Vertrauen erhöhen - - Grenzen ermitteln +**Unterschied Application / Module-Tests zu UnitTests** +*Appplication und Module* - **Testebenen** +- werden spät im entwicklungsprozess ausgeführt +- Testwerkzeuge sind Komplex +- sind aufwendig zu warten +- zeigen, das ein Fehler existiert - - Anwendung/System - - Teilsystem/Modul - - Codeebene/Unit +*UnitTest* - **Testpyramide** +- 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. - - GUI Tests (end to end tests) - business logik überprufen, functions und kommiunikation mit anderen components überprufen. - - Integration tests +-------------------------- - - Component / Contract Tests - - Unit Tests +***UnitTests*** - **Testnamen** +Was macht ein Unittest? - 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) +- 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*? - **Qualitätskosten** +- 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. - - High Cost -> Poor Quality -> Failure Costs - - High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) - - Low Cost -> Exceptional Quality -> prevention & Appraisal Cost +**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 - **Testprozess** +**F**ast +(schone erklärt) - **Testprozess - Ablauf** +**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. - **Testprozess - Plannung** +---------------------------- - **Testprozess - Analyse & design** +***Anforderungen an zu testenden Code*** - - basiert auf Anforderungsdokumentation - - Testspezifikation - - Testfaelle - - Kritikalitaet - - Testdaten - - Testumgebung - - Ausfuehrungsreihenfolge - - Infrastruktur - - Testkriterium +- Was verbessert die Testbarkeit? +- Isolieren einer Unit +- Isolation Ermöglichen - **Testprozess - Testausfuerung** +---------- + +*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 - Testlog - - aufgetretenes Fehlverhalten - - Fehlerkategorie (high/medium/low) - - **Testprozess - Testnachbereitung** - - - Testreport - - Zusammenfassung Testausfuehrungen - - Vergleich mit frueheren Testlaeufen - - Entscheidung ueber Lieferfaehigkeit - - ### kritik - - ### Mitteilung \ No newline at end of file +*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