Programmiermethoden_und_-werkzeuge
/
2022-2-WS_fdai7186
5
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Browse Source

Added Vorlesung 23.11

rated-lesson-2022-11-23__33
fakhrullah 2 years ago
parent
b98f358277
commit
214075dd4c
1 changed files with 268 additions and 173 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 441
      lerntagebuch.md

441
lerntagebuch.md
View File

@ -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 ### 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.
Write Preview
Loading…
Cancel
Save