Browse Source

Added Vorlesung 16.11

fakhrullah 2 years ago
parent
commit
d921fe7b5a
  1. 4
      LerntagebuchBeispiel.md
  2. 98
      lerntagebuch.md

4
LerntagebuchBeispiel.md

@ -1,4 +1,4 @@
<pre><div class="text_to_html">
# Mein Lerntagebuch für Programmiermethoden und -werkzeuge Das # Mein Lerntagebuch für Programmiermethoden und -werkzeuge Das
ist ein Beispiel wie ein Lerntagebuch aussehen könnte. ## SU 01 ist ein Beispiel wie ein Lerntagebuch aussehen könnte. ## SU 01
(21.10.2021) ### Lernziel - Organisatorisches - (21.10.2021) ### Lernziel - Organisatorisches -
@ -19,4 +19,4 @@
weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es
hier anmerken. --- ## SU 02 (28.10.2021) ...hier geht's bald hier anmerken. --- ## SU 02 (28.10.2021) ...hier geht's bald
weiter weiter
</div></pre>

98
lerntagebuch.md

@ -1,8 +1,11 @@
Vorlesung(2.11.2022)
# Mein Lerntagebuch für Programmiermethoden und -werkzeuge
Lernziele
## Vorlesung (2.11.2022)
### Lernziele
Es gibt viele Arten von programmierParadigmen: Es gibt viele Arten von programmierParadigmen:
1. Imperative programmierung erklärt, dass ein Programm aus einer Folge von Anweisungen besteht, die vorgeben, 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. 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. 2. Bei Deklarative Programmierung steht die Beschreibung des Problems im Vordergrund. Danach wird der Lösungsweg automatisch ermittelt.
@ -34,13 +37,13 @@ STUPID
- Indescriptive Naming - Indescriptive Naming
- Duplication - Duplication
Kritik
### Kritik
Keep It Simple and Stupid(Komplezität soll vermieden werden). Keep It Simple and Stupid(Komplezität soll vermieden werden).
Vorlesung(9.11)
## Vorlesung (9.11)
Lernziele
### Lernziele
Entwurfmuster (design patterns) sind bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme 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 sowohl in der Architektur als auch in der Softwarearchitektur und -entwicklung. Sie stellen damit
@ -49,7 +52,7 @@ Sie stammt aus der Architektur mit der Verbreitung von Programmiersprachen adapt
Die Vorteile davon ist: Die Vorteile davon ist:
1. erprobte Lösungen für Wiederkehrende Aufgaben. 1. erprobte Lösungen für Wiederkehrende Aufgaben.
2. Vor- und Nachteile sind bekannt.
3. Vor- und Nachteile sind bekannt.
3. die Kommunikation vereinfachen. 3. die Kommunikation vereinfachen.
4. eignen sich zur Dokumentation. 4. eignen sich zur Dokumentation.
@ -85,10 +88,89 @@ wo sie da coden kann zB. Eclipse, VS Code, Notepad(lmao). Eine der Automatisieru
welche seinen Job den Code automatisch komplett zu typen ist zB sysout wird automatisch zu System.out.println() getauscht. 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. 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. 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
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 von Codeteilen. Debugging wird erklärt durch die Beobachtung des Programms während der Laufzeit, um Fehler zu identifizieren
und zu löschen. und zu löschen.
Kritik
### Kritik
Keine für diese Woche :D. 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.
Loading…
Cancel
Save