|
|
|
@ -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: |
|
|
|
|
|
|
|
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. |
|
|
|
@ -34,13 +37,13 @@ STUPID |
|
|
|
- Indescriptive Naming |
|
|
|
- Duplication |
|
|
|
|
|
|
|
Kritik |
|
|
|
### Kritik |
|
|
|
|
|
|
|
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 |
|
|
|
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: |
|
|
|
1. erprobte Lösungen für Wiederkehrende Aufgaben. |
|
|
|
2. Vor- und Nachteile sind bekannt. |
|
|
|
3. Vor- und Nachteile sind bekannt. |
|
|
|
3. die Kommunikation vereinfachen. |
|
|
|
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. |
|
|
|
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 |
|
|
|
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 |
|
|
|
### 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. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fakhrullah
2 years ago