Lerntagebuch erstellt und bearbeitet

Lerntagebuch_23.11.2022_Su5.md

@@ -0,0 +1,97 @@
+Lerntagebuch für Programmiermethoden und -werkzeuge von Philipp Hartmann
+
+# SU5 23.11.2022
+
+## Lernziele (Was waren die wesentlichen Inhaltlichen Punkte der letzten Vorlesung - Stichpunktartig)
+# Kooperation im Softwareentwicklungsprozess
+- Größe von Software-Projekten
+- Zusammenführen der Einzelleistungen
+- Vorteile von CI Systemen
+
+# Softwareentwicklungsprozess
+
+# Bestandteile
+- Code schreiben
+- Abhängigkeitenverwaltung
+- Code veröffentlichen
+- Integration
+- build-Prozess
+-- compile (Programm erstellen) 
+-- test (das Programm testen)
+- Bereitstellung
+# Abhängigkeitenverwaltung
+- nicht selbst im Build-Lauf erzeugt
+- nicht im SCM eingecheckt
+- zentrale Bereitstellung
+- Zugriff auf einzelne Versionen
+# Semantische Versionierung
+- MAJOR ist nicht rückwärtskompatibel
+- MINOR ist rückwärtskompatibel
+- PATCH Fehlerbehebungen & rückwärtskompatibel
+- LABEL spezifische Kennzeichnung
+# Source Code Management System (SCM)
+- Sicherung der eigenen Arbeit
+- zentrale Verfügbarkeit
+- Zusammenführung parallel geändeter Dateien (merge)
+- parallele Entwicklung der featueres möglich
+- Zugriff auf dedizierte Stände ( releases)
+- Wechsel zwischen Entwicklungsständen (branches)
+# build - Prozess
+- Übersetzen
+- Abhängigkeiten organisieren 
+- Tests ausführen (können auch automatisiert sein)
+- Liefer-Artefakte erzeugen
+- Deployment (Zentral bereitstellen)
+# beliebte build-tools:
+- make vorwiegend C/C++ keine Abhängigkeitsverwaltung
+- maven / gradle vorwiegend Java
+- npm vorwiegend Javascript / TypeScript
+# Integration
+- SCM überwachen
+- build- Prozess starten
+-- Abhängigkeiten auflösen
+-- compilieren
+-- automatisierte Tests ausführen
+-- Lieferartefakt erstellen
+- Ergebnisse berichten
+# Rolle von automatisierten Tests
+
+# Problem des Continous Integration
+- kein menschlicher Eingriff 
+- 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 welche teifgründiger sind(außer UnitTests)
+- Ausführungszeit von Arbeitszeit entkoppeln
+- automatisierte Tests sind erheblich schneller als "menschliche" Tests
+# Grenzen automatisierte Tests
+- finden nur Abweichungen von gewünschten/bekannten Verhalten (findet nur das wonach der Entwicker sucht)
+- finden keine neuen fachlichen Fehler
+# Vorgehensmodelle
+
+# gemeinsames remote repository
+- alle Entwickler arbeiten ausschließlich gegen ein gemeinsames remote repository
+- jeder Entwickler hat (Schreib-) Zugriff
+- einfache Synchronisation
+- (gepushte) Zwischenstände für alle direkt sichtbar
+# privater fork
+- es gibt ein zentrales remote repository (=master)
+- jeder Entwickler hat ein seperates remote repository (= fork)
+- jedes locale repository hat 2 remote repositories
+-- origin --> master, nur lesend (dies nutzt man um syncrhon zu bleiben)
+-- upstream --> privater fork, Schreibrechte (dort kann ich meine Änderungen pushen)
+
+ 
+
+## Erkenntnis (Was kann ich für das Gruppenprojekt anwenden -2-3 Sätze)
+build tools nutzen und automatisierte Tests einfügen
+
+## Wiederholung (Einen Begriff/Ein Thema erklären -2-3 Sätze)
+
+
+## Kritik (Kritik oder Lob für den Dozenten - Optimal 2-3 Sätze
+