From 214075dd4c18e045a42a1d236e45064098b3f465 Mon Sep 17 00:00:00 2001 From: fakhrullah <58163394+jok3rzs@users.noreply.github.com> Date: Tue, 29 Nov 2022 22:04:36 +0100 Subject: [PATCH] Added Vorlesung 23.11 --- lerntagebuch.md | 441 +++++++++++++++++++++++++++++------------------- 1 file changed, 268 insertions(+), 173 deletions(-) diff --git a/lerntagebuch.md b/lerntagebuch.md index ecfbbe3..847df8b 100644 --- a/lerntagebuch.md +++ b/lerntagebuch.md @@ -1,176 +1,271 @@ -# Mein Lerntagebuch für Programmiermethoden und -werkzeuge - -## Vorlesung (2.11.2022) - -### Lernziele - -Es gibt viele Arten von programmierParadigmen: - -1. Imperative programmierung erklärt, dass ein Programm aus einer Folge von Anweisungen besteht, die vorgeben, -in welcher Reihenfolge was vom Computer getan werden soll. -2. Bei Deklarative Programmierung steht die Beschreibung des Problems im Vordergrund. Danach wird der Lösungsweg automatisch ermittelt. -3. Die prozedurale Programmierung ergänzt das imperative Konzept aufeinander folgender Befehle um den Ansatz, -einen Algorithmus in überschaubare Teile zu zerlegen. -4. Objektorientierte Programmierung, wie der Name beschreibt, bezieht sich auf eine Prorammiersprache(Java :D), -welche Objekte, Kalssen und Vererbung unterstützt. -5. Funktionalen Programmierung ist eine Verfeinerung der deklarative Progammierung, -bei dem die grundlegenden Ausdrücke die Erzeugung von Funktionen (die Abstraktion) und -die Anwendung von Funktionen (die Applikation) sind. Aber nur für Berechnungen. -6. Bei typisierten Progammiersprachen wird für Variablen sowie Parameter und Rückgabewerte von Prozeduren festgelegt, -von welchem Datentypen sie sind(int oder void und so weiter). -7. Typenlose Programmiersprachen ist das Gegenteil von typisierte Programmiersprache. -den Typ von Variablen, Parametern und Rückgabewerten wird nicht festgelegt. -8. SOLID vs STUPID - -SOLID -- Seperation of Concern -- Open/closed Principle -- Liskov Substitution Principle -- Interface Segregation Principle -- Dependency Inversion Principle - -STUPID -- Singleton -- Tight Coupling -- Untestability -- Premature Optimization -- Indescriptive Naming -- Duplication +# Mein Lerntagebuch für Programmiermethoden und -werkzeuge + +## Vorlesung (2.11.2022) + +### Lernziele + +Es gibt viele Arten von programmierParadigmen: + +1. Imperative programmierung erklärt, dass ein Programm aus einer Folge von Anweisungen besteht, die vorgeben, +in welcher Reihenfolge was vom Computer getan werden soll. +2. Bei Deklarative Programmierung steht die Beschreibung des Problems im Vordergrund. Danach wird der Lösungsweg automatisch ermittelt. +3. Die prozedurale Programmierung ergänzt das imperative Konzept aufeinander folgender Befehle um den Ansatz, +einen Algorithmus in überschaubare Teile zu zerlegen. +4. Objektorientierte Programmierung, wie der Name beschreibt, bezieht sich auf eine Prorammiersprache(Java :D), +welche Objekte, Kalssen und Vererbung unterstützt. +5. Funktionalen Programmierung ist eine Verfeinerung der deklarative Progammierung, +bei dem die grundlegenden Ausdrücke die Erzeugung von Funktionen (die Abstraktion) und +die Anwendung von Funktionen (die Applikation) sind. Aber nur für Berechnungen. +6. Bei typisierten Progammiersprachen wird für Variablen sowie Parameter und Rückgabewerte von Prozeduren festgelegt, +von welchem Datentypen sie sind(int oder void und so weiter). +7. Typenlose Programmiersprachen ist das Gegenteil von typisierte Programmiersprache. +den Typ von Variablen, Parametern und Rückgabewerten wird nicht festgelegt. +8. SOLID vs STUPID + +SOLID +- Seperation of Concern +- Open/closed Principle +- Liskov Substitution Principle +- Interface Segregation Principle +- Dependency Inversion Principle + +STUPID +- Singleton +- Tight Coupling +- Untestability +- Premature Optimization +- Indescriptive Naming +- Duplication + +### Kritik + +Keep It Simple and Stupid(Komplezität soll vermieden werden). + +## Vorlesung (9.11) + +### Lernziele + +Entwurfmuster (design patterns) sind bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme +sowohl in der Architektur als auch in der Softwarearchitektur und -entwicklung. Sie stellen damit +eine wiederverwendbare Vorlage zur Problemlösung dar, die in einem bestimmten Zusammenhang einsetzbar ist. +Sie stammt aus der Architektur mit der Verbreitung von Programmiersprachen adaptiert. + +Die Vorteile davon ist: +1. erprobte Lösungen für Wiederkehrende Aufgaben. +3. Vor- und Nachteile sind bekannt. +3. die Kommunikation vereinfachen. +4. eignen sich zur Dokumentation. + +Die Nachteile davon ist: +1. hohe Einstiegshürde. +2. Im Code schwer identifizierbar. + +Typen des Erzeugungsmusters: +1. Erbauer. +2. Fabrikmethode. +3. Abstrakte Fabrik. +4. Einzelstück (singleton). +5. Multiton. + +Typen des Strukturmusters: +1. Adapter. +2. Nachrüstungsschnittstellenmuster (retrofit interface pattern) +3. Die Brücke. +4. Dekorierer. +5. Fassade. +6. Fliegengewicht. + +Typen des Verhaltensmusters: +1. Accumulator. +2. Beobachter. +3. Iterator. +4. Kommando. +5. Nullobjekt. +6. Strategie. + +IDE - Integrated Development Environment ist eine Zielplattform für fast alle Programmierer, +wo sie da coden kann zB. Eclipse, VS Code, Notepad(lmao). Eine der Automatisierung der IDE ist Code Insight, +welche seinen Job den Code automatisch komplett zu typen ist zB sysout wird automatisch zu System.out.println() getauscht. +Andere Automatiesierungen sind safe actions, Code Formatierung für lesbarkeit und natürlich Compilieren. +Der Unterschied zwischen einfache und komplexe Refactorings ist, eine auf aktuelle Datei beschränkt, andere über mehrere Dateien. +Andere automatisierte Refactorings sind Umbenennungen, Signaturen von Methoden, Verschieben con Codeteilen und Zusammenfassen +von Codeteilen. Debugging wird erklärt durch die Beobachtung des Programms während der Laufzeit, um Fehler zu identifizieren +und zu löschen. + +### Kritik + +Keine für diese Woche :D. + +## Vorlesung (16.11) + +### Lernziele + +*git* als Source Code Management. + +Konzepte von *git*: + +1. basiert auf _change sets_, nicht Datei. +2. *commits* wird von SHA gesichert. +3. *branches* sind Aufkleber auf commits. +4. Staging area(siehe Kritik). + +Safety creates confidence: + +1. permanenter Zugriff auf den letzten Arbeitszustand. +2. Zugang zu verschiedenen Status (production, develop, feature in progress). +3. Änderungen im Laufe der Zeit/zwischen Funktionen oder *branches* vergleichen. + +Simple methods vs SCM: + +|Simple methods | Source Code Management | +|---------------------------- |------------------------------- | +|exsessive disk usage |optimised for minimal disk usage| +|chunky granularity |fine granularity | +|no ”commit message” |annotated change | +|hard to navigate / search |easy navigation/search | +|manual merges |automated merge | +|copies/archives on net shares|change history as tree | +|simple local copies | +|zip archives | +|no tooling required | +|easy diff | +| no technical relationships | + +Centralized SCM: + +|Pro|Contra| +|---|---| +|Jeder *commit* für verfügbar| zentrale Instanz erforderlich| +|aktueller Editor allen bekannt|*locking* verhindert paralleles Arbeiten| +|easy backup/restore|*branching* und *merging* sofort sichtbar für alle| +|unbegrenzte Ressourcen für das Repository|keine Offline-Arbeit| + +Distributed SCM: +|Pro|Contra| +|---|---| +|kein zentraler Server nötig|local history out of sync| +|mehrere *remotes* möglich|kein Schutz gegen gleichzeitige Änderungen| +|arbeiten ohne (ständigen) Netzzugang| +|implizite backups| +|Offline-Arbeit - lokale "Experimente"privat bleiben| + +Branching: + +1. master/main +2. develop +3. release +4. hotfix +5. feature + +Rebase vs Merge: + +|`rebase` wenn|`merge` wenn| +|---|---| +|an einem unfertigen *feature* arbeiten, das noch nicht in andere *branches* eingebunden wurde|aktuell _branch develop_ oder *master*| +|eine saubere Historie ist erwünscht|Die Historie sollte mit der Zeitachse synchron bleiben| +|dein *branch* hat viele Commits (mit funktionierenden UnitTests)|dein *branch* wurde bereits gemerged| +|einen "Squash-Commit" vorzubereiten| + +### Kritik + +Keep commits small and clean for easier problem solving and back tracking. + +## Vorlesung (23.11) + +### Lernziele + +Vorteile von Continuous Delivery (CI): + +1. automatisierte Prozesse verrigern Aufwand +2. formale Prozesse verringern Konfliktpotential +3. Vorstufe zu _Continuous Delivery_ + +Bestandteile von Softwareentwicklungsprozess: + +1. Code schreiben +2. Abhängigkeitenverwaltung +3. Code veröffentlichen +4. Integration +5. build-Prozess: compile und test +6. Bereitstellung + +Abhängigkeitenverwaltung: + +1. nicht selbst im Build-Lauf erzeugt +2. nicht im SCM eingecheckt +3. zentrale Bereitstellung (innerhalb der Organisation) +4. Zugriff auf einzelne Versionen + +Semantische Versionierung: + +__1.2.3-beta1__ + +1- MAJOR - inkompatible Änderungen +2- MINOR - zusätzliche Features, Programmteil bleibt abwärtskompatibel +3- PATCH - Fehlerbehebungen, Programmteil bleibt abwärtskompatibel +beta1- LABEL - spezifische Build-Kennzeichung + +Source Code Management (SCM): + +1. Sicherung der Arbeit einzelner Entwickler +2. zentrale Verfügbarmachung +3. Zusammenführung parallel geänderter Dateien +4. parallele Entwicklung verschiedener Features ermöglichen +5. Zugriff auf dedizierte Stände (*releases*) +6. Wechsel zwischen Entwicklungsständen (`branches`) + +build - Prozess: + +1. Übersetzen +2. ängigkeiten organisieren +3. automatisierte Tests ausführen +4. Liefer-Artefakte erzeugen +5. Deployment + +build-Prozess starten: + +- Abhängigkeiten auflösen +- compilieren +- automatisierte Tests ausführen +- Lieferartefakt erstellen +- Lieferartefakt ausliefern + +Integration: + +1. SCM überwachen +2. build-Prozess starten +3. Ergebnisse berichteten + +Problem des Continuous Ingegrations: + +1. kein menschlicher Eingriff +2. compilierbar nicht bedeutet ausführbar +3. CI soll immer lieferbaren Stand bereit halten +4. Programm muss im CI Prozess ausgeführt werden + +Vorteile automatisierter Tests: + +1. automatisierte Tests führen Programm aus +2. dokumentieren gewünschtes Verhalten +3. sind wiederholbar +4. erkennen Laufzeitfehler (außer UnitTests) +5. Ausführungszeit von Arbeitszeit entkoppelt + +gemeinsames _remote repository_ + +1. alle Entwickler arbeiten ausschließlich gegen ein gemeinsames _remote repository_ +2. jeder Entwickler hat (Schreib-)Zugriff +3. einfache Synchonisation +4. (gepushte) Zwischenstände für alle direkt sichtbar + +privater *fork*: + +1. es gibt ein zentrales remote repository (= _master_) +2. jeder Entwickler hat ein separates remote repository (= _fork_) +3. jedes locale repository hat 2 _remote repositories_: + - `origin` - *master*, nur lesend + - `upstream` - privater *fork*, Schreibrechte ### Kritik -Keep It Simple and Stupid(Komplezität soll vermieden werden). - -## Vorlesung (9.11) - -### Lernziele - -Entwurfmuster (design patterns) sind bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme -sowohl in der Architektur als auch in der Softwarearchitektur und -entwicklung. Sie stellen damit -eine wiederverwendbare Vorlage zur Problemlösung dar, die in einem bestimmten Zusammenhang einsetzbar ist. -Sie stammt aus der Architektur mit der Verbreitung von Programmiersprachen adaptiert. - -Die Vorteile davon ist: -1. erprobte Lösungen für Wiederkehrende Aufgaben. -3. Vor- und Nachteile sind bekannt. -3. die Kommunikation vereinfachen. -4. eignen sich zur Dokumentation. - -Die Nachteile davon ist: -1. hohe Einstiegshürde. -2. Im Code schwer identifizierbar. - -Typen des Erzeugungsmusters: -1. Erbauer. -2. Fabrikmethode. -3. Abstrakte Fabrik. -4. Einzelstück (singleton). -5. Multiton. - -Typen des Strukturmusters: -1. Adapter. -2. Nachrüstungsschnittstellenmuster (retrofit interface pattern) -3. Die Brücke. -4. Dekorierer. -5. Fassade. -6. Fliegengewicht. - -Typen des Verhaltensmusters: -1. Accumulator. -2. Beobachter. -3. Iterator. -4. Kommando. -5. Nullobjekt. -6. Strategie. - -IDE - Integrated Development Environment ist eine Zielplattform für fast alle Programmierer, -wo sie da coden kann zB. Eclipse, VS Code, Notepad(lmao). Eine der Automatisierung der IDE ist Code Insight, -welche seinen Job den Code automatisch komplett zu typen ist zB sysout wird automatisch zu System.out.println() getauscht. -Andere Automatiesierungen sind safe actions, Code Formatierung für lesbarkeit und natürlich Compilieren. -Der Unterschied zwischen einfache und komplexe Refactorings ist, eine auf aktuelle Datei beschränkt, andere über mehrere Dateien. -Andere automatisierte Refactorings sind Umbenennungen, Signaturen von Methoden, Verschieben con Codeteilen und Zusammenfassen -von Codeteilen. Debugging wird erklärt durch die Beobachtung des Programms während der Laufzeit, um Fehler zu identifizieren -und zu löschen. - -### Kritik - -Keine für diese Woche :D. - -## Vorlesung (16.11) - -### Lernziele - -*git* als Source Code Management. - -Konzepte von *git*: - -1. basiert auf _change sets_, nicht Datei. -2. *commits* wird von SHA gesichert. -3. *branches* sind Aufkleber auf commits. -4. Staging area(siehe Kritik). - -Safety creates confidence: - -1. permanenter Zugriff auf den letzten Arbeitszustand. -2. Zugang zu verschiedenen Status (production, develop, feature in progress). -3. Änderungen im Laufe der Zeit/zwischen Funktionen oder *branches* vergleichen. - -Simple methods vs SCM: - -|Simple methods | Source Code Management | -|---------------------------- |------------------------------- | -|exsessive disk usage |optimised for minimal disk usage| -|chunky granularity |fine granularity | -|no ”commit message” |annotated change | -|hard to navigate / search |easy navigation/search | -|manual merges |automated merge | -|copies/archives on net shares|change history as tree | -|simple local copies | -|zip archives | -|no tooling required | -|easy diff | -| no technical relationships | - -Centralized SCM: - -|Pro|Contra| -|---|---| -|Jeder *commit* für verfügbar| zentrale Instanz erforderlich| -|aktueller Editor allen bekannt|*locking* verhindert paralleles Arbeiten| -|easy backup/restore|*branching* und *merging* sofort sichtbar für alle| -|unbegrenzte Ressourcen für das Repository|keine Offline-Arbeit| - -Distributed SCM: -|Pro|Contra| -|---|---| -|kein zentraler Server nötig|local history out of sync| -|mehrere *remotes* möglich|kein Schutz gegen gleichzeitige Änderungen| -|arbeiten ohne (ständigen) Netzzugang| -|implizite backups| -|Offline-Arbeit - lokale "Experimente"privat bleiben| - -Branching: - -1. master/main -2. develop -3. release -4. hotfix -5. feature - -Rebase vs Merge: - -|`rebase` wenn|`merge` wenn| -|---|---| -|an einem unfertigen *feature* arbeiten, das noch nicht in andere *branches* eingebunden wurde|aktuell _branch develop_ oder *master*| -|eine saubere Historie ist erwünscht|Die Historie sollte mit der Zeitachse synchron bleiben| -|dein *branch* hat viele Commits (mit funktionierenden UnitTests)|dein *branch* wurde bereits gemerged| -|einen "Squash-Commit" vorzubereiten| - -### Kritik - -Keep commits small and clean for easier problem solving and back tracking. - - - - - +*forking* is a good practice for a large scale project, where a lot of people working on the same repository at the same time.