Vorbereitung VL 04.04.2022

711966ce · Jordine Tobias Dr. · e0ae9e21 · 711966ce · 711966ce · 711966ce
Commit 711966ce authored 2 years ago by Jordine Tobias Dr.
--- a/website/assignments/git-Doku-CleanCode.md
+++ b/website/assignments/git-Doku-CleanCode.md
+# Übungen Software-Entwicklung 3: `git`, Dokumentation, Clean Code
+
+## Ausgangslage
+In der Vorlesung haben Sie weitergehende Konzepte zu `git`, Dokumentation und Clean Code kennengelernt. Diese sollen nun auf Ihr Projekt angewandt werden.
+
+## Aufgabe
+* Überlegen Sie sich im Team, wie Sie mit `git` umgehen möchten. 
+  * Wie sieht Ihr Workflow aus?
+  * Wie möchten Sie mit Branches umgehen?
+  * Wann werden Tags erstellt? Wie ist Ihre Versionsschematik?
+* Erstellen Sie in Ihrem Repository ein Changelog, in dem Ihre Änderungen festhalten und pflegen.
+* Erstellen Sie eine Readme, die beschreibt, wie Ihr Projekt gestartet wird.
+* Legen Sie Ihre Projektdokumentation in einem Wiki ab.
+* Prüfen Sie Ihren vorhandenen Code auf die `SOLID`-Prinzipien und passen diesen ggf. entsprechend an.
+  * Sind Benennungen so gewählt, dass diese keine weitere Erklärung benötigen?
+  * Sind Ihre Klassen immer gleichartig strukturiert?
+
+## Tipps
+* Nutzen Sie `git` auf der Commandline. Das hilft, die Konzepte zu verinnerlichen.
+* Scheuen Sie sich nicht vor `merge`-Konflikten! Nach ein paar Mal, ist es nicht mehr so schlimm 😊
+* Nutzen Sie `merge`-Requests, um sich gegenseitig zu reviewen.
+* Schauen Sie in das [Vorlesungsprojekt](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt). Hier finden Sie eine Möglichkeit wie Sie Beispiele wie die `SOLID`-Prinzipien umgesetzt werden können.
+
+## Ziele
+* Sie können mit `git` umgehen und haben eine Vorgehensweise für branches definiert.
+* Changelogs dokumentieren wesentliche Änderungen Ihres Projekts.
+* Eine Readme beschreibt wie Ihr Projekt gestartet werden kann.
+* Ihre Dokumentation liegt in einem Wiki ab.
+* Die `SOLID`-Prinzipen werden in Ihrem Projekt angewandt.
\ No newline at end of file
--- a/website/clean-code_doku_git.html
+++ b/website/clean-code_doku_git.html
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Softwarearchitektur</title>
+    <meta charset="utf-8">
+    <link href="css/hdm.css" rel="stylesheet"></link>
+    <style>
+      @import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz);
+      @import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700,400italic);
+      @import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic);
+
+      body { font-family: 'Droid Serif'; }
+      h1, h2, h3 {
+        font-family: 'Yanone Kaffeesatz';
+        font-weight: normal;
+      }
+      .remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; }
+    </style>
+  </head>
+  <body>
+    <textarea id="source">
+
+class: center, middle, first
+
+# Software-Entwicklung 3
+
+## git, Dokumentation, Clean Code
+
+---
+
+# Agenda
+
+1. Recap
+2. Arbeit mit git
+3. Dokumentation
+4. Clean Code
+
+
+---
+
+# Recap: Was haben wir letzte Woche besprochen?
+
+* Softwarearchitektur
+* Basisprinzipien der Softwarearchitektur
+* Praktisches Beispiel
+
+> Blick ins [Repository](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt)
+
+---
+
+# Arbeit mit VCS
+
+VCS = **V**ersion **C**ontrol **S**ystem
+
+Ablage von Dateien/Ordnern, die nicht aus anderen versionierten Dateien abgeleitet werden können. Beispielsweise sollten `.class`-Dateien nicht in einem VCS verwaltet werden.
+
+Heute Fokus auf Teamarbeit mit `git`
+
+---
+
+# `git` Basisbefehle
+
+* `git pull REMOTE TARGET-BRANCH`: Updates aus Remote-Repo laden und in TARGET-BRANCH mergen
+* `git status`: Status des Repo. Zeigt z.B., ob Dateien noch nicht commited wurden
+* `git log`: Zeigt die History des aktuellen Branches an
+
+Erklärungen zu sämtlichen Befehlen: [git Cheat Sheet](https://training.github.com/downloads/de/github-git-cheat-sheet/)
+
+---
+# `git graph`
+
+Anzeige der commits und branches als Graph.
+
+**git CLI**
+```bash
+git log --all --decorate --oneline --graph
+
+# Beenden mit ":q"
+```
+
+**GitLab**
+
+_Repo-Seite_ ➡️ **Repository** ➡️ **Graph**
+
+Beispiel: https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt/-/network/main
+
+---
+# Erstellen eines Branches und Merge
+
+```bash
+git branch my-new-branch
+
+git checkout my-new-branch # Abkürzung: git checkout -b my-new-branch
+
+# Änderungen machen
+
+git add --all
+
+git commit -m "update README.md"
+
+git checkout main
+
+git merge my-new-branch
+
+```
+---
+# Merge conflicts beheben
+
+Entstehen, wenn in beiden Branches (source und target) in der gleichen Zeile Änderungen vorgenommen wurden.
+
+```bash
+git checkout <TARGET BRANCH>
+
+git merge <SOURCE BRANCH>
+
+# Konflikt mit Editor beheben. Entscheiden, welche Änderung "korrekt" ist.
+
+git add <AFFECTED FILES>
+
+git commit -m "merged TARGET BRANCH"
+
+# Ergänzung: Merge abbrechen
+git merge --abort
+```
+
+---
+# git flow
+* Besteht aus
+  * mehreren Feature Branches, d.h. parallele Entwicklungsstränge
+  * langlebige Branches
+    * Integrationstests auf `develop`
+    * Releases auf `main`, inkl. Tags
+* Merge auf `main` wird oft nur von bestimmten Personen durchgeführt
+* Geeignet z.B. für feste Releasezyklen
+* git flow Cheatsheet: http://danielkummer.github.io/git-flow-cheatsheet/
+
+<img src="img/git-doku-cleancode/git-flow.png" alt="git flow" width="60%"/>
+
+---
+# Trunk-basierte Entwicklung mit git
+
+* Geeignet, **häufige** und **kleine Änderungen** in einem Hauptbranch (_Trunk_, oft `main`) einfließen sollen.
+* Alle haben Zugriff auf alle Branches, auch `main`
+* Grundannahme: Trunk-Branch ist immer stabil und bereit für Deployment.
+* Kleine Branches. Dadurch weniger Konflikte beim merge.
+
+<img src="img/git-doku-cleancode/git-tdd.png" alt="Trunk based development" width="90%"/>
+
+---
+# `merge` requests in GitLab
+
+* Kann Bestandteil eines Reviewprozesses sein
+
+> [Demo im Repo](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt)
+
+---
+# `cherry pick`
+
+* Kopieren einzelner Änderungen/Commits von einem Branch in einen anderen.
+* Sinnvoll, wenn an zwei Branches gearbeitet wird und eine Änderung vor dem `merge` benötigt wird. Beispiel: Hotfix.
+
+## Schritte
+1. Commit ID herausfinden, die kopiert werden soll: `git log`
+2. Wechseln in den Branch, in dem der Commit kopiert werden soll: `git checkout BRANCHNAME`
+3. Kopieren des Commits in den aktuellen Branch (mit neuem Commit): `git cherry-pick COMMIT-ID [COMMIT-ID COMMIT-ID]`
+4. _Kopieren des Commits in den aktuellen Branch (ohne neuem Commit): `git cherry-pick COMMIT-ID [COMMIT-ID COMMIT-ID] -n`_
+
+---
+# git Tricks
+
+* `.gitignore`: Datei, in der angegeben werden kann, welche Dateien/Ordner nicht versioniert werden sollen
+
+> [Sammlung mit `.gitignore`-Konfigurationen](https://github.com/github/gitignore)
+
+---
+# Tagging und Semantic Versioning
+
+* [Semantic Versioning](https://semver.org): Dreiteilige Versionsnummern. Z.B. `v2.3.1`.
+* Muster `v{Major}.{Minor}.{Patch}`
+  * `Major`: (API-)Änderungen, die nicht mehr kompatibel zu Vorgängerversionen sind.
+  * `Minor`: (API-)Änderungen, die kompatibel zu Vorgängerversionen sind.
+  * `Patch`: Bug-Behebungen, keine API-Änderungen.
+
+## Tagging mit git
+
+* Tag = Versionsnummer, die auf einen commit zeigt
+
+```bash
+git tag -a TAGNAME COMMIT-ID
+```
+
+* Alternativ mit GitLab
+
+---
+# Changelogs
+
+* Dokumentieren, was eine spezifische Version auszeichnet.
+  * Was ist neu?
+  * Was wurde geändert?
+  * Welche Funktionen werden in Zukunft entfernt?
+  * Welche Funktionen wurden entfernt?
+  * Welche Bugs wurden behoben?
+  * Welche Security-Probleme wurden behoben?
+* Weitere Infos: [Keep a changelog](https://keepachangelog.com/de/1.0.0/)
+
+---
+
+# Tricks in GitLab
+ 
+ `git commit -m "Arbeit an Issue #2"`
+
+Verknüpft Commits mit Issues. Sinnvoll für Nachvollziehbarkeit.
+
+---
+class: center, middle
+# Dokumentation & Issue Management
+
+
+---
+# Dokumentationsformen
+
+* Doku am Code (`javadoc`), sofern notwendig
+* Doku im Repository
+  * Readme, z.B. mit Anleitung wie das Programm gestartet werden kann
+  * Changelog
+* Technische Dokumentation
+* Enduser Doku
+
+> Schulungen mitdenken!
+
+---
+# Nutzen eines Wikis
+
+> [Demo im Repo](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt)
+
+# Nutzen von Milestones
+
+> [Demo im Repo](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt)
+---
+class: center, middle
+# Clean code
+
+---
+# Warum ist clean code wichtig?
+
+* Ursprung: Buch "Clean Code", Robert C. Martin, Sammlung von Prinzipien um clean code zu erreichen
+* Ziele: 
+  * Code leichter verständlich machen
+  * Wartbarkeit des Codes erhöhen
+  * Einheitlichkeit schaffen
+  * Projektorganisation
+  * (Selbst-)Organisation
+
+---
+# SOLID Prinzipien
+
+_Teilweise Wiederholung_
+
+* **S**ingle Responsibilty Principle: 
+  * Jede Klasse sollte nur eine Aufgabe bearbeiten, Speichern in Model-Klasse auslagern
+* **O**pen Closed Princple: 
+  * Offen für Erweiterung, geschlossen für Veränderung
+  * Info-Methode für Audio/Videos auslagern
+* **L**iskov'sches Substiotions Prinzip: 
+  * Unterklassen erweitern Oberklassen
+  * Unterklassen dürfen Verhalten der Oberklassen nicht einschränken
+* **I**nterface Segregation Principle: 
+  * Große Schnittstellen in kleinere, modularere Schnittstellen aufteilen
+* **D**ependency Inversion Principle: 
+  * Interfaces statt konkreter Implementierung
+  * Gruppierende Methoden
+
+> Demo
+
+---
+# Umgang mit Benennungen
+* Es soll kein Kommentar für Variablenbenennungen notwendig sein
+* Variablendefinition an dem Ort, wo sie definiert werden
+* Nicht zu viele Kommentare, Code sollte ohne verständlich sein
+
+
+---
+# Eindeutigkeit
+
+* Gleichartige Struktur: Z.B. Wie sind Klassen strutkturiert
+  * Wo befinden sich `imports`, Konstruktoren, Methoden etc.?
+  * Unterstützung durch IDE, i.S.v. Templates
+  * Kann automatisiert über statische Codeanalyse/Lint (z.B. [SonarCube](https://docs.sonarqube.org/latest/)) geprüft werden
+* Jede Methode sollte nur eine Sache tun, ggf. aufteilen in mehrere Methoden
+
+---
+# Zusammenfassung der Clean Code Regeln
+
+> [Tutorials zu Clean Code, TU Dortmund](https://sopra.cs.tu-dortmund.de/wiki/_media/infos/tutorials/cleancode/cleancode_paper.pdf)
+
+
+> [Clean Code Tugenden, clean-code-developer.de](https://clean-code-developer.de/die-tugenden/)
+
+**Nicht immer sind alle Clean Code praktikabel!**
+
+---
+# Refactoring des Demoprojekts
+
+    </textarea>
+    <script src="https://remarkjs.com/downloads/remark-latest.min.js">
+    </script>
+    <script>
+      var slideshow = remark.create();
+    </script>
+  </body>
+</html>
\ No newline at end of file
--- a/website/img/.DS_Store
+++ b/website/img/.DS_Store
--- a/website/img/git-doku-cleancode/git-flow.png
+++ b/website/img/git-doku-cleancode/git-flow.png
--- a/website/img/git-doku-cleancode/git-tdd.png
+++ b/website/img/git-doku-cleancode/git-tdd.png
--- a/website/index.html
+++ b/website/index.html
@@ -13,12 +13,14 @@
        <li><a href="einfuehrung.html" target="_blank">Einführung</a></li>
        <li><a href="anforderungsanalyse.html" target="_blank">Anforderungsanalyse</a></li>
        <li><a href="softwarearchitektur.html" target="_blank">Softwarearchitektur</a></li>
+        <li><a href="clean-code_doku_git.html" target="_blank">git, Dokumentation, Clean Code</a></li>
    </ul>

    <h3>Vorlesungnotizen</h3>
    <ul>
        <li><a href="https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022vorlesung/-/blob/main/website/lecturenotes/20220321.md" target="_blank">Vorlesungsnotizen - 21.03.2022</a></li>
        <li><a href="https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022vorlesung/-/blob/main/website/lecturenotes/20220328.md" target="_blank">Vorlesungsnotizen - 28.03.2022</a></li>
+        <li><a href="https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022vorlesung/-/blob/main/website/lecturenotes/20220404.md" target="_blank">Vorlesungsnotizen - 04.04.2022</a></li>
    </ul>

    <h3>Projekt</h3>
@@ -34,6 +36,7 @@
    <ul>
        <li><a href="https://e-learning.hdm-stuttgart.de/moodle/course/view.php?id=3828" target="_blank">Moodle-Kurs</a> </li>
        <li><a href="https://konferenz1.hdm-stuttgart.de/b/jor-hzf-odu-rxi" target="_blank">BBB zur Vorlesung</a> </li>
+        <li><a href="https://konferenz1.hdm-stuttgart.de/b/jor-r4x-ias-ytk" target="_blank">BBB zu den Übungen</a> </li>
        <li><a href="https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022vorlesung" target="_blank">GitLab: Vorlesungsdemos</a> </li>
        <li><a href="https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt" target="_blank">GitLab: Vorlesungsprojekt</a> </li>
    </ul>

--- a/website/lecturenotes/20220328.md
+++ b/website/lecturenotes/20220328.md
@@ -2,6 +2,6 @@

 ## Anpassungen
 * AudioTrack verallgemeinern und austauschbar machen
-* MusicManagere abstrahieren, damit die Persistenz gekaüselt ist
+* MusicManager abstrahieren, damit die Persistenz gekapselt ist
 * Aufteilung in Packages
 * Factory mit unterschiedlichen Parametern
--- a/website/lecturenotes/20220404.md
+++ b/website/lecturenotes/20220404.md
+# Vorlesungsnotizen - 04.04.2022
\ No newline at end of file